[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Extra query args on a render url
Not quite, here the portlet in effect becomes the actor, while in public params the consumer really is. The portlet would need to know the mechanism on how to pass public params to the consumer. URL params are one option, but as we state in the public params in general the params can come from somewhere else. 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 wsrp <wsrp@lists.oasis-open.org> 04/12/2005 05:34 cc PM 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]