On why to disallow the portlet -- my comment was if PPs only apply to the
given portlet then the portlet can use Navigational State instead to perform
the same function when setting itself in an URL. I don't understand your
comment at the end saying this doesn't solve the use case of a portlet wanting
to affect the value of its subsequent render [ though I do understand how
it prevents the sharing use case]. I do however agree this is a little artificial/unnatural
but point it out as a way of further narrowing/simplifying PP semantics so
that they don't clash with transient properties when we add them in the future.
-Mike-
Rich Thompson wrote:
To your questions:
Simply because the user can drive the coordination
does not mean the user is editing a URL. If the user has chosen to activate
a URL which sets a PP, then the user is driving the coordination. The Consumer
can certainly generate such a URL for the user to interact with. Why disallow
the Portlet also being able to generate such a URL? Stefan's use cases certainly
make a case for allowing it.
Obfuscation does enter the picture, nor
does by reference questions. If the Consumer has particular encodings, including
using by reference, then such issues are taken care of when the Consumer
rewrites the URL.
WSRP involves the Consumer due to issues
with the network topology and access to resources which are behind firewalls.
This proposal impacts none of that reasoning nor alters choices already made.
If you are questioning whether PPs ought
to be supplied on getResource invocations, I would consider that an orthogonal
question. One we should definitely address, but orthogonal to the issue at
hand.
Again, look back at Stefan's use cases
to see that this is not overloading PPs, but rather allowing Portlets to have
an influence on PP values. Limiting the interaction to the Portlet which
generates the URL (e.g. using navState or some new facility like portlet_querystring)
doesn't solve the use case.
Rich
"Andre Kramer" <>
07/28/05 04:43 AM
To
Rich Thompson/Watson/IBM@IBMUS,
<>
cc
Subject
RE: [wsrp-interfaces]
Fw: [wsrp] Additional use cases for issue #44 (set new public params)
Do you expect end users to edit
URLs to override consumer (PP) settings? Then I would ask (to prime the call
today):
- Is such editing of URLs desirable? Allowed
for Web experts for simple URLs, I agree, but for Portlets?
- Are URLs not too obfuscated (encoded) to allow
manual editing? Because of size limitations, the URL may be by-reference.
- Why need the consumer be involved? Since user
explicitly submits she may not expect the consumer Portal to be in the loop.
- Are other types of URLs (to resources and out-of-Portlet
Web content) also not to be covered?
- Why overload PPs with this feature? Maybe a
separate user to portlet channel would be better? Something more like a query
string?
My suggestion for 3.0 would
be to look at having a trailing URL part (wsrp-portlet-query-string) that
can be added to consumer produced URLs that is forwarded unmodified (or as
a separate key/value list) by the consumer to explicitly model query strings
if we really require and can support such a feature.
Regards,
Andre
From: Rich Thompson [mailto:]
Sent: 27 July 2005 19:18
To:
Subject: Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue
#44 (set new public params)
To say this another way, PPs enable user/Consumer driven coordination. The
current question is whether to allow Portlets to generate URLs that enable
the user driven portion of this rather than requiring such URLs be generated
by the Consumer. I think the use cases Stefan posted say there is value to
allowing Portlets to generate such URLs.
Rich
