Client sides Script (e.g. JavaScript) can’t
get/set public parameters (only the consumer) so I don’t see this new
proposed feature helping here.
The proposed getResource operation can be
used by client side script to send back form like data and return markup to be
inserted into a DOM. However, this requires SOAP and a lot more sophistication
in the client.
Given this and the current ability to use
blocking actions (at the cost of an extra round trip) do we need to weigh down
getMarkup? I would argue primarily for keeping getMarkup pure and simple. However,
the ability to re-post data from an action into the following getMarkup would
be another benefit …
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 12 April 2005 17:08
To: wsrp
Subject: Re: [wsrp] Extra query
args on a render url
I hadn't thought of public parameters as a possible
solution, probably because the use cases don't really involve coordination.
The
downside of solving these use cases using public parameters is that it requires
the Portlet to enumerate all possible query args it might look to append to the
url. That isn't horrible, but it is a downside (edge cases might not work
because they didn't get enumerated).
The
other question I would raise is whether this would be stretching what had been
designed as a coordination mechanism as it would just be passing additional
parameters to a single Portlet.
Rich
Michael Freedman
<michael.freedman@oracle.com>
04/12/05 11:34 AM
|
To
|
wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
|
Re: [wsrp] Extra query args on a render url
|
|
Isn't
this covered using public parameters? Or are suggesting
extensions to it?
-Mike-
Rich Thompson wrote:
>
> We have heard back from portlet developers
that another thing WSRP v1
> is missing is a way for JavaScript to append
query args to a render
> url such that those additional name/value
pairs make it to getMarkup.
> Action urls are allowed to do this as the
additional query args then
> flow to the portlet in the formParameters
field of
> InteractionParameters. I don't remember us
explicitly deciding not to
> allow these and am wondering if there is a
reason not to add them for v2.
>
> Two cited use cases were:
>
> 1. The markup contains a long list of
hyperlinks, such as might be
> fetched via a database query, which vary only
via a single detail,
> such as a dbKey. For performance reasons it
is often preferable to
> generate a single portlet url and then have
scripting append the key
> before activating the url.
>
> 2. The url wants to depend on some
information the user has entered
> (e.g. zipcode), but is not being handled as a
form submit. In this
> case, scripting must be used to put together
the url so that it can
> contain the user entered material. While there
are many cases where
> such a url will cause a state change in the
Portlet (thereby needing
> to be an action url), there are also many
cases where the additional
> information is only used to impact how the
Portlet renders the next
> fragment (i.e. logically becomes an extension
of the navState) such
> that a render url would be preferable.
>
> Rich
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave
the OASIS TC that
generates this mail. You may a link to this
group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php