wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp] Extra query args on a render url
- From: Rich Thompson <richt2@us.ibm.com>
- To: "wsrp" <wsrp@lists.oasis-open.org>
- Date: Mon, 11 Apr 2005 07:45:57 -0400
These cases can even be solved using
pbia(). It just is a loss of efficiency to require a pair of network roundtrips
rather than allowing the user agent to (logically) extend the link's navState.
Rich
"Andre Kramer"
<andre.kramer@eu.citrix.com>
04/11/05 04:21 AM
|
To
| "wsrp" <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp] Extra query args
on a render url |
|
Non-blocking actions covered
these use cases?
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 08 April 2005 18:15
To: wsrp
Subject: [wsrp] Extra query args on a render url
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]