OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interop] BEA Producer Updated (Resend)



We had talked about this use case when discussing whether or not Consumer should strip the namespacing from the names of submitted form items. The decision reached was that these names did not need namespacing and therefore the Consumer should never do such namespace stripping.

The scenario that makes one think the input fields should have their name attribute values namespaced is that this is one of the ways to locate those fields in JavaScript. We noted in the discussion that this was only one of the ways available though. Other options included using the id attribute (generally encouraged by the relevant W3C groups) or namespacing the form id attribute's value and then using it to locate the fields within the form.

The result of this discussion was not having the Consumer do such stripping. As Andre notes, the Consumer is free to use any unique token it wishes to create a unique namespace for the portlet instance and therefore the portlet should not rely on this having any particular value. If necessary, a portlet could infer what the token used was, but I think we primarily need to encourage portlets not to namespace the names of the input fields in forms AND encourage JavaScript developers to use the id attribute rather than the name attribute when seeking to locate fields.

Rich



Subbu Allamaraju <subbu@bea.com>

09/25/2003 09:17 AM

To
wsrp-interop@lists.oasis-open.org
cc
Subject
Re: [wsrp-interop] BEA Producer Updated (Resend)





Andre,

Here is a use case:

1. The portlet renders some JavaScript that does some client-side form
validation. The producer/portlet encodes this script with wsrp_rewrite_
tokens for the function name as well as the form input control names.

2. The consumer rewrites the input control names and the function names
with some arbitrary token (not known to the producer).

3. The user submits the form, the consumer extracts form fields and
sends these as formParameters to the producer.

4. The producer/portlet tries to look for expected parameters but does
not find them. It does not even know what to look for.

How would you suggest that WSRP handle this use case (with consumer
rewriting)?

Regards,

Subbu

Andre Kramer wrote:
> Subbu,
>
> Your analysis fits what our consumer does.
>
> portletInstanceKey is optional so I'm willing to null it (but not to
> make it equal namespacePrefix)... Nope, that did not appear to work.
>
> However, I would add that a consumer is free to replace the consumer
> re-write token with anything that it likes (as long as value is unique
> on a page) not just namespacePrefix.
>
> Therefore forms (or other markup) should not rely on consumer
> re-rewriting to add a particular input name prefix.
>
> regards,
> Andre
>
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 24 September 2003 16:18
> To: wsrp-interop@lists.oasis-open.org
> Subject: Re: [wsrp-interop] BEA Producer Updated (Resend)
>
>
> Andre,
>
> First of all, thanks for trying these.
>
> It is likely that all the failures are related (including the method GET
> portlet, login and upload) to consumer rewriting of form parameter names:
>
> 1. Our portlet runtime uses the portletInstanceKey (when supplied) to do
> form databinding and scope session data. Accordingly, the returned
> markup has form param names like "wsrp_rewrite_{actionForm.field1}".
>
> 2. For form databinding to work correctly, we expect the consumer to
> rewrite the markup with the instance key. So the above form parameter
> name becomes "[portletInstanceKey]{actionForm.field1}.
>
> 3. The portlet runtime then looks for form parameters scoped with the
> portletInstanceKey. The data binding fails if the consumer sends param
> names encoded with something else.
>
> Here is what I noticed from your consumer requests:
>
> - Consumer is sening a portletInstanceKey (looks like some arbitrary
> URL-encoded key)
>
> - namespacePrefix: The consumer is using "netlet0" for rewriting. So the
> form parameter name becomes "$netlet0_{actionForm.field1}"
>
> However, the producer does not understand such form parameter names in
> the context of the portlet being invoked. So the data binding fails.
>
> The rationale for this interpretation is that these are form parameter
> names, and the producer needs to be able to understand the names to
> process the action request - even when the consumer is rewriting the names.
>
> I'm not entirely sure if the spec does say something about rewriting
> form parameters, and how a producer/should behave.
>
> I'm leaving this to the SG to debate. In the meantime, could you please
> try using the same key for both rewriting and portletInstanceKey.
>
> Regards,
>
> Subbu
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.
>



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]