Re: [wsrp-interfaces] interactionFieldPrefix and namespacing formparams

[Stefan Hepper <sthepper@hursley.ibm.com>]

In addition to Richard's points, here the current JSR 168 behavior:

- if portlets namespace a form field they will get this prefix on the 
form submit
- there is no Java Portlet API that will provide the developer with a 
prefix usable for form parameter namespacing. The getNamespace method in 
the Java Portlet API is only guaranteed to stay the same within a 
request, not across requests.

This means that in the Java Portlet case the WSRP producer container 
needs to also parse the portlet markup and add the wsrp namespacing. 
This doesn't sound to efficient to me...

Stefan

Richard Jacob wrote:
> Hi all, (sorry, lengthy)
> 
> I think as the current proposal is in the spec, it is conceptually broken.
> I have the following concerns/questions/comments concerning the field and
> section 10.4 in the spec:
> 
> 1. namespacing of form parameters in general
>>From the current coding practices and specification conformance statements
> a portlet needs to receive back exactly the value it placed in the markup.
> Otherwise the portlet *never* will be able to find its encoded parameters
> in the received parameter map.
> E.g. if the portlet namespaces the field name "field1" with namespace "NS1"
> it puts "NS1field1" into the markup.
> This is exactly the value it need to search for in an incomming parameter
> map. i.e. it wouldn't search for just "field1".
> e.g. in JSR168 a portlet can call getNamespace() to get the namespace to
> know or call encodeNamespace("field1") to receive the namespaced result.
> Therfor from an architectural and symmetry point of view portlets *MUST*
> receive the same values back they send/encoded in the markup. And this
> should not only be true for form fields but also for any other params -
> what it is today.
> 
> 1a. namespacing using Producer Writing
> With the explanation above this means that if a portlet used such a prefix
> obtained from the Consumer to namespace its fields, it would expect the
> namespace passed back on an incomming request.
> E.g. the portlet above would search for "NS1field1" in the parameter map.
> Now the portlet container on the Producer side needs to prepend the
> incomming portlet parameters with the interactionFieldPrefix again.
> Why do we mandate at all that Consumers strip the prefix before passing the
> interaction request back to the Producer/portlet?
> This seems a very unnecessary step requirng a) the Consumer the parse and
> strip the incomming params and b) the Producer container to add the prefix
> to all params when it prepares the request for the portlet. And in this
> case how does the Producer container know, which field was intended to be
> namespaced initially???
> 
> 1b. namespacing using WSRP rewriting
> this is the same here: if portlets namespace a form field using rewriting
> they would put (or the container would return "wsrp_rewrite_" as the
> getNamespace() result) wsrp_rewrite_field1 into the markup.
> Notice: from the plain JSR168 portlet perspective, the portlet really
> doesn't know anything about WSRP rewriting. It just asks the container for
> a namespace.
> In that case the Consumer would need to rewrite the rewrite token to its
> prefix. When receiving back the request, it would need to replace the
> Consumer chosen prefix to "wsrp_rewrite_" again and send it to the
> Producer/portlet.
> 
> 1c. summary
> To not break the exisiting behavior of today's APIs and applications we
> really need to make sure, that portlet really get back what they encode and
> not an intemediary/changed resultset and make assumptions here.
> So conceptually we are broken by saying that Consumers must strip the
> prefix. We also need to make people aware, that the current proposal in the
> spec requires Consumers to put back the "wsrp_rewrite_" token again if
> rewriting was used. Otherwise things will brake. 1., 1a. & 1b. were part of
> the reasons why we did not mandate form fields to be prefixed at all,
> besides the fact that they didn't really need to be namespaced.
> 
> 2. the number of prefix fields in the spec
> We now have: namespace prefix, portletInstanceKey and
> interactionFieldprefix in the spec. This is *very* confusing and misleading
> and we surely will have a hard time to explain it to developers.
> 
> 2b. What is the difference between interactionFieldPrefix and
> portletInstanceKey?
> I would assume Consumer portals will always set both fields to have the
> exactly same value?
> 
> 2c. Can one of these fields be reused here and their semantics being
> refined?
> 
> 3. reasoning behind form field namespacing
> Besides that the current proposal seems broken to me I would still question
> the motivation for this in general.
> The initial use case brought up was Consumers using technologies based on
> forms and the arising troubles with nested form fields.
> While I see that this technologies will come up and we probably might want
> to deal with the nested forms problem (can we?) I think that the current
> proposal doesn't resolve the problem at all.
> 
> 3a. Consumers using form based technologies like JSF
> The plain namespacing of form parameters are not enough to support these.
> There are a couple of things to do like: removing nested forms, replacing
> form actions with appropriate scripts to identify the "original" submit,
> identify the form fields to be submitted, rewrite javascript functions in
> form submits, etc.
> All of this requires the markup to be parsed and rewritten and since this
> has to be done anyway I don't see a reasons why we need to deal with a
> small portion of the overall problem in the protocol and therefor modify
> the behavior for Consumers not using this technique AND for the portlet
> APIs. Remember: the current specs discourage portlet to namespace form
> fields.
> 
> 3b. Portlets using technologies like JSF
> Here we have the same problem: nested forms.
> But the existing technologies do not namespace their form fields.
> Especially the JSF reference implementation doesn't.
> What does that mean? Do we require Producer containers or portlets to
> rewrite the markup prior to sending it to the Consumer? In that case we
> will have rewriting on both sides.
> 
> 3d. Summary
> Yes, there is a problem with nested forms. Markup rewriting will be
> required on either side.
> No, the current proposal doesn't solve the problem and/but afair it didn't
> intend to.
> However, it probably could solve a single facette of the overall problem
> but in essence doesn't save big efforts here or makes life really easier
> for either side.
> In case of 3a. the consumer will need to rewrite/postprocess the markup.
> And since it will have to postprocess and will need to find inbedded forms
> it certainly can take appropriate actions to namespace the form fields in
> these forms if it requires to do so.
> 
> 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
> 
> 
>