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)
- From: Rich Thompson <richt2@us.ibm.com>
- To: Subbu Allamaraju <subbu@bea.com>
- Date: Thu, 25 Sep 2003 09:35:08 -0400
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]