[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] interactionFieldPrefix and namespacing form params
comment in <rj></rj>
In essence for me this comes down to this:
1. do we need to namespace form fields at all? why?
a. do we want to force a change in current programming models here to be
able to support WSRP?
2. if we decide to support the namespacing here we need to
a. keep a symmetrical model, i.e. portlet gets back what it encoded into
the markup
b. keep namespacing "transparent" to the consumer, i.e. do not force the
Consumer to strip namespaces and make destinctions between Producers not
namespacing and such which choose to
c. provide a means to the portlet to rely on a stable namespace prefix it
could use. There will certainly be discussion needed what stable means:
persistent, per session, per what?
d. discuss the namespace wsrp_rewrite_ token usage, perhaps limit its use
3. keep things simple and clear, the 3 prefixes/keys seem now very
cumbersome to me.
a. discuss reasons why we need to keep things as they are and add new (kind
of redundant) fields with slightly different semantics
b. wouldn't a semantic change fit better e.g. of the namespacePrefix?
Discuss scenarios of Consumer&Producer supporting different spec versions.
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
Michael Freedman
<michael.freedman
@oracle.com> To
Richard Jacob/Germany/IBM@IBMDE
08/31/2005 08:11 cc
PM wsrp-interfaces@lists.oasis-open.or
g
Subject
Re: [wsrp-interfaces]
interactionFieldPrefix and
namespacing form params
Comments inline in blue.
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.
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.
<rj>yes, this is perhaps what is missing: a prefix that survives the
request/response.
And here it's arguable how long the life time is: session, persistent? With
session we seem to loose bookmarkability.</rj>
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?
<rj>I would consider stripping and cumbersome. A symmetric model requires
less processing on either side and is more understandable and cleaner.</rj>
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.
<rj>yes, kind of. This case doesn't occur because in 1.0 we don't have the
case where things come back.
Perhaps we need to limit also the usage of wsrp_rewrite_ then?
In this case the supplied prefix must not be optional then, as it is now.
The question in general then is, what is wsrp_rewrite_ for if we need to
provide the prefix with each request?</rj>
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.
<rj>I don't see the compatibility point here. If a Consumer talks to a 2.0
Producer it need to access it through the 2.0 portTypes. Then the semantics
should be implicitly clear.
I'm not sure if we really want 1.0 Consumers to talk to 2.0 Producers
without any change. I think there are to many conformance changes
meanwhile. So the Consumer would always have to make appropriate semantical
changes if it wants to support 2.0</rj>
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.
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.
<rj>right, and i think the definition of the portlet instance key comes
very close.
I still find it really cumbersome to have even 2 prefixes needed to be used
for different purposes. The cleaner message would be: here is a thing you
can use as a namespace, period.</rj>
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.
<rj>I fine with that definition and will immediatly forget the JSF&ASP.Net
use case.
But this certainly mandates to keep things symmetrical and not require to
differenciate between Producer decided to do the namespacing and those who
don't.
Therfore again: stripping by the Consumer is evil, and even worse with the
above definition.</rj>
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.
<rj>yep, I try to forget the initial use case :-) But then I don't see why
not namespacing form fiels is wrong.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]