[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] namespacePrefix
I will look through this more completly and reply next week but one
quick note. We aren't mandating that portlet developers namespace their
form fields. We are however encouraging them to do so. The argument we
will present them is that by choosing to namespace their form fields
they can ensure running correctly/best in all consumers including those
emerging consumers that aggregate the portlet in a form. What we need
to account for in 2.0 that we didn't in 1.0 is that such consumers exist
and thus we need to allow portlets that want to to generate markup it
feels is a best fit for both environments.
-Mike-
Richard Jacob wrote:
>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
>
>
>
>
>---------------------------------------------------------------------
>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
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]