[no subject]

Namespacing any items [e.g. form fields] that are resubmitted to the
producer are relatively broken in 1.0.  The problem is that  the consumer
is free to send a different namespace on each request including in a
subsequent [form] submission.  I.e. Namespacing is only required to be
unique within the given request/page.  To support form field namespacing
correctly the portlet is required to either store the namespace in a hidden
field or put it in a session variable and write the key to it in a hidden
field.  We decided this was relatively broken because its obscure, unlikely
to be used/done by the developer, and doesn't work for consumer rewritten
namespacing.  The later fails because the consumer isn't required to use
the same namespace id for consumer rewriting as its using for producer
writing -- though I suspect most do.

RT> I think Richard's point was that the new semantics are also broken, but
in a different manner. He asserts the semantics for what a portlet receives
back when a URL is activated is an exact match to what the portlet wrote
into the markup. Therefore, if the portlet wrote "wsrp_rewrite_field1",
that is the token it should receive back.

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

I don't remember the details of why we ended up the Consumer strip model vs
always leave.  I suspect it came from the discussion of whether to require
the formFieldPrefix be identical whether encoded by the consumer via
rewrite or consumer using the supplied field -- and rather then define this
ended up with what you see. Rich, can you remember other rationale?

RT> This came about while discussing how the portlet could decode its
parameters from what the Consumer forwards. I think it is one problematic
areas of the proposal as it currently stands.

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.

I disagree here. I don't think its the responsibility of the consumer to
replace the prefix with "wsrp_rewrite_".  In this case the producer's
container has this responsibility.  Its the container that has decided to
say the namespace is "wsrp_rewrite_" vs. using the actual one supplied and
hence the containers job to have this make sense to its developer in
subsequent requests.  Of course, because we don't require the consumer's
rewrite value be the same as the one it provided the producer nor require
it remain consistent across requests there really is no way for the
producer to do this in 1.0 -- one of the many reasons such containers use
the actual namespace id passed to it when supporting a getNamespace() style
of interaction.

RT> This may seem odd, but is a direct fall-out of a model where the
portlet receives back exactly what it wrote to the markup.

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.

I agree we need to decide whether portlet developers prefer to treat
namespace prefixing as something that changes the id of their field or
merely a way of encoding their field in a response.  Both models work and
neither break as long as the deevloper codes to the model.  As I said above
I disagree that wsrp_rewrite_ should be rewritten by the consumer and its
clearly counter to what the spec has said all along.  Its also the first I
have heard suggested [that we should do it].  Finally, you are correct that
we didn't mandate form fields be perfixed in 1.0, however nor are we in
2.0.  The difference is that in 1.0 because we believed that form fields
"never" needed prefixing we choose to leave many holes in our namespacing
proposal vs working through whether they could realistically be used for
such a use case.

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.

Yes, adding a new field adds confusion.  We made this decision because
"fixing" the namespace field required changing its semantics in a way
incompatible with 1.0.  So in the end though clarity suffers we preferred
it over the incorrectness -- i.e. our expectation that 1.0 consumers may
not understand our 2.0 semantic changes hence ultimately break by not
providing them.

RT> This is one of my big concerns in this area. I think we are currently
introducing more confusion than value. Of course that could just be my not
fully understanding and therefore not reflecting the proposal well into the
spec.

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?

You are correct that its likely many consumers will use the same value
here.  The difference is that portletInstanceKey isn't defined/described
for use in markup and hence some consumers may be using values that contain
characters that are inappropriate for the fieldPrefix.  That being said I
would expect most of such producers to derive the fieldPrefix from the
instanceKey.

RT> Note that there are use cases where the portletInstanceKey will be
shared, but the prefixes different (unique views onto a single instance).
<rj>which use cases? If the consumer wants to display 2 or more
windows/view to the same portlet entity (identified by the handle) it
assignes them different portletInstanceKeys<rj>

2c. Can one of these fields be reused here and their semantics being
refined?

Again the issue is backwards compatibility.  We preferred adding a new
field vs changing the semantics of any given field.  The only reuse
solution I can think of given this decision is to tell the producer to
derive its own formFieldPrefix based on the portletInstanceKey and use that
when namespacing form fields -- in this situation we would have
guidance/discussion in 10.4 concerning doing this but wouldn't add the new
field nor the new rewrite token.

RT> The other option that doesn't add an new prefix is to add semantics to
the namespacePrefix to cover cases for when it becomes part of a user
interaction (Could be requiring it have an identical value in the field for
the request, add a new field carrying the old value, provide guidance on
the portlet storing the old namespace, etc). I now suspect adding semantics
to namespacePrefix would be less problematic than adding an additional
prefix.

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.

You are correct about the initial use case.  This proposal however is not
intended to address this use case.  The committee basically decided that
the use case would not be addressed in 2.0.  Rather, in discussing the use
case and possible solutuions we identified a problem with 1.0 -- namely
that our namespace prefix support in 1.0 is relatively broken in the
situation that the producer decides to encode form fields.  Though not
addressing the use case we used it to recognize that there are now valid
reasons and interested producer parties in doing such namespacing and hence
have decided to fix this 1.0 problem.

RT> We should question whether this means we are introducing something that
is likely to then change again as we more fully address the use case.

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.

Again, this proposal isn't about addressing the JSF/ASP.Net use case.  It
is about recognizing that its no longer appropriate to discourage portlets
from namespacing their fields.  In 1.0 we made the observation /assumption
that portlet forms were discrete and hence could point out reasons why this
extra step wasn't needed.  However, we now know that this
observation/assumption is wrong.  Though you are correct there are other
things to deal with, from a mere form field perspective its now very
reasonable for a portlet [developer] to namespace its form fields as its
not detrimental in the case you run in a separate form while beneficial
when you don't.  Recognizing this has taken us down the path of fixing 1.0
support.

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.

Again, we aren't discussing/trying to solve this use case here -- merely
fixing a problem in 1.0 that we let slide back then because we didn't
expect developers to ever care.

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.

Agreed, this doesn't solve the use case. That is not its intent as the
committee decided we wouldn't/shouldn't address it in 2.0.  This merely
tries to fix the 1.0 problem where though we imply/allow form field
prefxing our semantics are poorly defined to make it obscure if not
impractical to support.  We have decided because an expanded universe has
an interest in doing such prefixing to fix 1.0.  And rather then change
existing semantics with an impact to backwards compatibility we choose to
add additional semantics.


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