[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Extra query args on a render url
agreed, but perhaps we have a missunderstanding here. In the case of method=get forms, I agree. And that's why we have our methodGetSupported flag. And this is what I proposed as a solution to use case 1. But the use case below talks about manipulation URLs in the markup directly. In essence even the ones finally rewritten by the Consumer. And this can become problematic for the reasons I mentioned below. 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 Rich Thompson <richt2@us.ibm.co m> To wsrp <wsrp@lists.oasis-open.org> 04/13/2005 02:40 cc PM Subject Re: [wsrp] Extra query args on a render url We do allow the Portlet to add additional query args onto action URLs. This is described in how the InteractionParameters.formParameters field is to be populated. One of the data sources is additional query arguments. Forms submitted using method=get is one example of how such additional query arguments can be appended onto the url, but dHTML pages often do such things in JavaScript as well. Since the server can't tell, should we care how those additional query args came to be appended onto the URL? I guess one point that does arise when rereading this description about treating additional query args as form parameters is that it broadens a bit the meaning of the RegistrationData.methodGetSupported flag (i.e. it really means that the Consumer can deal with additional query args on posts). Rich Richard Jacob <richard.jacob@de.ibm.com> To 04/13/05 05:54 AM Rich Thompson/Watson/IBM@IBM US cc wsrp <wsrp@lists.oasis-open. org> Subject Re: [wsrp] Extra query args on a render url Some comments and thoughts: 1. I don't think that we currently explicitly allow portlets to add query args to actionURLs. In general I think it can be quite dangerous for a portlet and WSRP to assume a certain way how the consumer genererates its page and especially its URL. Remember: All the portlet generates is a rewrite expression or a template which still might not be a real URL. For example a Consumer might choose to be completly form based, have a single page URL and use form submits with hidden fields as the params. Another example is the Consumer itself using javascript. We may get the nested javascript issues I asked about perhaps 6 months ago (no real resolution found at that time). Another issue is the name clashing of these parameters. We don't say anything about Consumer's page URLs namespacing. So while I agree that Consumers in general could support additional query args besides their own private ones, the portlet's assumption about the format itself can be quite dangerous and probably lock out some implementations. We may be underspecified here to be fully interoperable. 2. Use case 1 could be solved by the portlet itself if it used forms with method=get. I agree that we would then need to extend the markup params to carry the additional form params (which are kind of "public navState"? This could work as follows: - portlets encodes links as forms with method=get, could use javascript to dynamically add hidden form params - the consumer should map method=get form submissions to getMarkup() requests. Remember method=get simply fetches a resources and should not modify the server side state, therefor we can define these form params as part of the navState. I.e. currentPortletNavState(encoded in URL)+publicNavState(dynamically added)=resultingNavState for which the portlet renders its markup. One additional advantage here (in contrast to handling it via pbia()) is that the Consumer can compute the cache key for that resultingNavState and thus be able to cache this markup. - The form params of such a method=get request should be passed as additional MarkupParams. So with a tighter binding of method=post to pbia and method=get to getMarkup() + addtional MarkupParams, we could solve this issue. On the other hand this of course has the usesMethodGet problem we already cover in our protocol. 3. I think use case 2 is targets what public params try solve. If the Consumer allows page URLs to be expandible by its users (by adding params), then these would be passed by the consumer accordingly. However we add another dimension here. Consumers need to propagate the capability? Now it's the portlet which add these parameters and the Consumer is again just an intermediary. In the public params case the Consumer is really the actor. Again assuming the URL format of Consumer pages for a portlet might be quite dangerous and might impose interop problems. 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 Rich Thompson <richt2@us.ibm.co m> To wsrp <wsrp@lists.oasis-open.org> 04/08/2005 07:15 cc PM 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]