Re: [wsrp] namespacePrefix

[Richard Jacob <richard.jacob@de.ibm.com>]

Hi,

I'm catching up with the originating thread "Portlets and Forms".
I'm not quite confident that the proposed namespacing of form fields really
solves the nested forms problem discussed there.
I have the following concerns:
1. don't we change the programming model for portlet developers?
We now seem to [likely] encourage them to namespace form fields while we
didn't in v1.
Typically our customers want to develop portlets (or whatever component
technology they use) and ["simply"] provide these as WSRP remote portlets.
They don't really care about nuances of the WSRP protocol but want their
components simply work over WSRP without any change to their component
code. E.g. when we think of JSR168 portlets,
programmers don't use encodeNamespace() for their form fields in their code
because we and the JSR168 told them not to do so.
Now we are reverting it and tell them they have to use a different
programming model to make their portlets work over WSRP.
This seems broken to me. In this case portlets won't work out "of the box"
any more over WSRP.

2. Does the mandating of namespacing form fields really solve the problem?
It doesn't seem so to me. As Andre said, and I agree, the really feasible
way today for the Consumer to enable the UI technologies like ASP and JSF
is to rewrite the markup.
Or alternatively provide helps to accomodate such a transformation like you
suggested (but still might be difficult to tell whether portlet markup
contains forms or not unless the underlying component technologies provide
such information without the need of parsing the markup on the producer
side).
What do we gain if we enforce the namespacing of form fields? As far as I
understood the current proposal the Consumer would have to parse the markup
anyway (e.g. to remove the the form tag,)

3. I think the (in the case of namespacing of form fields, legitimate and
correct) questions below indicate that we now have a change of semantics
concerning namespacing.
While in V1 the namespacing purpose was to protect java script functions,
variable names etc. from name clashes and misfunction of these javascripts,
we now extend the model quite a bit.
In the v1 case the namespacing was just for the purpose of "collision
prevention" and effectivly was used when the complete page was rendered,
either via wsrp_namespace or the namespacePrefix in RuntimeContext. And
this was scoped by the aggregated page and was "always" valid, i.e. at the
generation time we assured that we don generate pages with colliding names
- that's it.
Now we add a nuance of lifetime to such prefixes as you correctly
identified.
This is because we now have to assume that the prefix used by the consumer
is kind of persistent, right?
I'm not sure if we want to enforce that.
Typical use case might be: Consumer has generated a page with 4 portlet
windows, Browser bookmarks page, Admin removes one portlet from the page.
Now the window ids might habe changed..., browser access the bookmarked
page.
If we decide to not to enforce persistence of the prefixes, it will be hard
for the consumer to strip them. I think in this case the consumer would
need to store them in its state in the URL.

Therefore I really would question if this namespacing really helps us.

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com


                                                                           
             Michael Freedman                                              
             <michael.freedman                                             
             @oracle.com>                                               To 
                                       wsrp <wsrp@lists.oasis-open.org>    
             07/08/2005 02:08                                           cc 
             AM                                                            
                                                                   Subject 
                                       [wsrp] namespacePrefix              
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Now that we no longer discourage portlets from namespacing form field
names [and likely will encourage it], do we need to clarify further how
namespacePrefix works across requests?  I believe we finessed this is v1
because we didn't believe things that would be resubmitted to the
consumer through to the producer would be namespaced -- now they
can/will be.  If the portlet uses the wsrp_rewrite_ namespace rewrite
token for a field name is the consumer responsible for stripping the
namespace on subsequent form submit?  If the portlet uses the
namespacePrefix in the RuntimeContext does the consumer likewise remove
it on form submit?  Or must is guarantee that the namespacePrefix passed
in the RuntimeContext of the submit request be identical to the one it
supplied before?  How long does it have to ensure this behavior?
     -Mike-


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php