Re: [wsrp-interfaces] interactionFieldPrefix and namespacing formparams

[Michael Freedman <michael.freedman@oracle.com>]

You are correct the JSR 168 semantics mirrors the WSRP 1.0 semantics 
regarding namespacing, each being largely broken for form field 
prefixing.  Yes, a smart developer might see they can encode the 
namespace prefix [or a key to it] in a hidden field -- but 999 out of 
1000 this would be missed/considered too clumsy if needed any more then 
in a blue moon.  This proposal is about adding semantics to make it 
convenient to prefix form fields.  It requires changes/additions in JSR 
168 2.0 to support.

I don't understand you second comment regarding the producer container 
needing to parse the porlet markup.  Producers/portlets/containers 
aren't required to prefix their form fields.  I would expect some 
producer containers to expose this capability in a meaningful way to its 
developers -- however if not then the developer can't prefix form fields 
in that environment except to specifically code to wsrp by writing/using 
the wsrp_rewrite- token -- somethign I wouldn't expect to be used in a 
container environment that isn't exclusively based on WSRP [like JSR 168].
        -Mike-

Stefan Hepper wrote:

> 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
>>
>>
>>
>
>