Re: [wsrp-interfaces] interactionFieldPrefix and namespacing formparams

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

You are right that currently the wording of the spec does not say 
anything when a portlet should use prefixing form fields. I miss-read 
the SHOULD in the current version and assumed that the portlet should 
prefix form fields, while it only states that the prefix should only be 
used for these purposes.

Why would it break the spec if we enhance the namespace semantic and 
make the namespace to be the same for the duration of the session?
This change could also be applied to the new JSR 168 spec version.

Stefan

Michael Freedman wrote:
> 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
>>>
>>>
>>>
>>
>>
> 
> 
> 
>