[no subject]

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