comments in-line in this
color
Rich
Michael Freedman <>
09/06/05 02:38 PM
To
cc
Subject
Re: [wsrp-interfaces] interactionFieldPrefix
and namespacing form params
On your two suggestions:
1. Increase the lifetime of the namespacePrefix to the particular usage
of the Portlet by the Consumer.
The problem is we don't have a well defined lifetime all consumers
can support as the best solution here is for the consumer [in our current
proposal producer] to stash this value in the URL itself -- meaning that
the namespacePrefix has the lifetime of the markup -- which seems right
considering bookmarking.
RT> I suspect most Consumers today compute
what value they will pass based on something they already store as a unique
key to the usage of the Portlet (i.e. they encode this key to be valid
in markup, including script names). If I am right, Consumers already supply
the same value within the proposed lifetime and increasing how the spec
models this area to current practice makes it easier to solve the current
issue. If I am wrong (or other reasons surface), encouraging Consumers
(rather than Portlets) to encode the namespacePrefix in the URL could easily
be the better practice (though we would need to make sure we have understood
and dealt with the issues Richard raised).
2. Require that Consumer namespace rewriting use the same value as what
is supplied to the Producer in namespacePrefix --
This is okay -- but all we get if we can't define a lifetime as in (1)
is it removes the need to encode wsrp_rewrite_ in the URL token which still
might be seen as a benefit.
RT> Agreed for the current issue, though
we also get a freedom to mix dynamic and static content for Portlet developers
-Mike-
Rich Thompson wrote:
We could simply add a field to carry the value from the new portlet URL
parameter, my question is whether a little broader rethinking of this area
might not yield a cleaner solution.
I don't think either of the two changes I have proposed would be difficult
for Consumers to implement, but that could be a reason for not streamlining
in the manner I proposed. I also have not been able to think of edge use
cases where the proposed streamlining would fail. Either of these could
be reasons to expand the current model rather than making these changes.
Rich
Michael Freedman <>
09/06/05 01:59 PM
To
cc
Subject
Re: [wsrp-interfaces] interactionFieldPrefix
and namespacing form params
Why wouldn't the namespacePrefix be passed back to the producer as a field
[encodedNamespacePrefix?] of InteractionParams and/or ResourceParams? Isn't
all we are trying to do here is to formalize encoding this prefix in interaction
state so developers don't have to figure out they need to use interaction
state and we overcome the limitations that such opaque encoding in interaction
state may not work in all situations nore that we have a corresponding
facility in ResourceParams?
-Mike-
Rich Thompson wrote:
I had also had concerns as I contemplated the tentative solution over the
weekend.
If we add a portlet URL parameter to carry the namespacePrefix used during
markup generation, how does the portlet receive this back?
- one option would be to add another field to RuntimeContext carrying the
previousNamespacePrefix, but this raises both complexity and a question
about why this would be distinct from the current namespacePrefix.
- another option would be to increase the lifetime of the namespacePrefix
to this particular usage of the Portlet by the Consumer. This would remove
the need to store the prefix in the URL as the portlet would also receive
back the value used during the encoding. The downside is that the Consumer
would either need to persist this value or have a dependable means of constructing
its value.
In regards to mandating that wsrp_rewrite_ not be used when encoding items
that could flow back on interactions, this causes problems with using static
script that references html form fields by name. One could argue that such
script requires a rework already in order to have the wsrp_rewrite_ inserted
and that this rework could instead have the prefix supplied to the script
on each invocation. In the interest of reducing complexity for the portlet
(script) developer, I would instead argue for requiring that Consumer rewriting
use the same value as is supplied to the Portlet with namespacePrefix.
This also allows a broader use case of mixing dynamic (uses namespacePrefix)
and static (uses wsrp_rewrite_) content.
Are there edge use cases that wouldn't be solved by this pair of changes?
1. Increase the lifetime of the namespacePrefix to the particular usage
of the Portlet by the Consumer.
2. Require that Consumer namespace rewriting use the same value as what
is supplied to the Producer in namespacePrefix
I also think there is value to making namespacePrefix and portletInstanceKey
required fields (Producer can depend on them) and am unaware of any use
cases where the Consumer would have a difficult time supplying these values.
In general this would be a case of v2 raising the bar of what constitutes
a good Consumer implementation.
Rich
Richard Jacob <>
09/06/05 05:51 AM
To
cc
Subject
Re: [wsrp-interfaces] interactionFieldPrefix
and namespacing form params
Here goes the proposal I had, just wanted to clarify it so people can make
up their mind.
Rationales:
- do not require form params namespacing
- do not prevent portlets from doing it (but don't add an extra penalty
on
those who don't want to do it)
- do not change portlet programming models, allow them to use the means
they have today
- do not require a constant prefix accross requests (although we coud talk
about it, portletInstanceKey is already someting similar)
- have a symmetric model, i.e. portlet gets back what it encodes
- try to avoid unnecessary rewriting steps
The whole proposal simply bases on two facts:
- why not force consumers to always provide a namespace prefix? today it
is
optional
- using wsrp_rewrite_ for form param names is problematic and should not
be
used (we discussed it already)
1. Consumer always provide namespacePrefix
This way Producer can rely on it and always return the prefix to the
portlets if the request it, e.g. they call getNamepace() in the JSR168
case.
I'm pretty sure other APIs will have similar means.
There is no real penalty on the consumer, they can easily compute one per
page AND they already need some means for themselves anyway.
So here portltes can encode their form field names using that namespace.
The only thing they need is to remember the prefix they used.
This can easily be stored in the portltet's interactionState.
This is completly transparent to the consumer AND producer and doesn't
require any additional rewriting, parsing, stripping etc.
2. do not use wsrp_rewrite_ in form parameter names
a) there is no need for it if we have 1.
b) as said it is very problematic, and was not the initial intent of
wsrp_rewrite_. The intent was to namespace *one time* the markup without
a
flow back. It seems the stretch we want to do here is to large.
c) in fact portlets using getNamepace() and 1. will never see a
wsrp_rewrite_ anymore, so from a dynamic UI generation point of view there
is no need to use wsrp_rewrite_
d) portlets with static content can still use wsrp_rewrite_ as they use
for
1.0 we don't break anything
3. the resource discussion we had last thursday
The proposal on the table doesn't solve the problem anyway as I described
below.
Let's think through it:
- in 1.0 it never could work and indeed we discouraged people from
namespacing form field names.
- if a resource (e.g. servlet) uses wsrp_rewrite_ we really can consider
it
as being "WSRP aware", i.e. we can't claim that in this case
the resource
is completly WSRP agnostic.
- if the above is true why not pass the "WSRP context" to the
resource via
the resource URL. In this case why not pass the namespacePrefix to the
resource?
This is how it could work:
1. portlet gets called and obtains the namespacePrefix
2. portlet encodes a resource URL and as a parameter passes the
namespecePrefix to be used (indeed it needed to be a subSpace of the
initial namespace in the case the portlet AND the resouce generate forms
-
use case?)
3. resource received ns prefix can use it, can also encode the prefix used
by various means.
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/Germany/IBM
@IBMDE
To
09/06/2005 11:17
g
AM
cc
Subject
Re: [wsrp-interfaces]
interactionFieldPrefix
and
namespacing form
params
Hi all,
I just decided to stress you further on the topic what we discussed last
week :-)
I started to think through what we proposed and decided to give it a shot.
So here is what I understood as the general idea, please correct me if
I'm
wrong:
- introduce a new WSRP url parameter containing the namespace which was
used by the producer container and passed to the portlets, e.g. if they
call getNamespace()
- we assumed implicitly that the value of the new param is flowing back
(in
InteractionParams and MarkupParams?)
What does it bring/help or was the intent of it?
- do not require namespacePrefix to be mandatory
- allow usage of wsrp_rewrite_ as the namespace prefix, here we explicitly
refered to resources using rewriting
- do not require the namespacePrefix to be constant across requests
- anything I missed?
I've been playing a little bit with it, here are some thoughts
1. portlets do not use wrsp_rewrite_ for form params namespacing
- it seems we're introducing some kind of namespace persistance across
requests through the backdoor.
Once the producer container decides to pick up a namespacePrefix from the
runtime context it is "persisted" in the URLs.
The Consumer is forced to send it back -> Producer uses it again and
stores
it in the URLs.
While this seems an interesting means at the first glance, it introduces
some problems.
- How can consumers guarantee that they do not assign a new namespacePrefix
on a page which clashes with the existing ones?
- How does this new value relate with the existing namespacePrefix, seems
quite confusing here? Is the namespacePrefix assigned the new value from
the URL?
2. portlets using wsrp_rewrite_ in form names as the ns prefix
We saw that this is quite problematic. The intent of the proposal using
the
URL param was that the URL param itself gets rewritten by the consumer
to
the "real" namespace as well as the form fields in the markup.
Thus
portlets/the producer can obtain the consumer assigned namespace to
identify the form params.
- Do we expect that Producers in this case pick up the assigned namepace
and rewrite it back again to wsrp_rewrite_ so that rewriting is always
used? -> additional producer rewriting
- If not we have just one wsrp_rewrite_ usage and then fall back to a given
namespace prefix with the implication I described in 1. ?
- I think we change the rewriting algorithms here: What do consumers do
if
the wsrp rewrite token appears as a parameter value in the rewrite URL?
Aren't parameter values opaque here? Do your rewriting implementation touch
parameter values in a rewrite URL?
3. Resources using URL rewriting
I think the proposal doesn't really solve the problem. The main question
here is:
- How does the namespace prefix assigned by the consumer flow back to the
reasource?
- If it needed to flow back to the reasource it needs needs to be part
of
the resource URL not the rewrite URL. But as of today, resource URLs are
opaque to the Consumer and it shouldn't touch them.
So when thinking through it, things really seem to become clumsy here,
too
with not adding to much value here.
There are some implication in the proposal, which haven't been thought
through, yet.
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:
