OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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]