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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interfaces] tie method=get to getMarkup


I'm unclear about the rationale you describe below.

Whether a client GET or POST request is translated to getMarkup, 
getResource, pbia, or handleEvents depends on how the markup was 
generated (including URL rewriting). So, the entities that needs to 
honor idempotency is the portlet (for generating the markup) and the 
Consumer (if Consumer-rewriting is in use). Why should the protocol 
dictate that a GET request from the client be translated to getMarkup or 
getResource?

Subbu

Richard Jacob wrote:

>It seems that we didn't discuss this issue seperatly and that the
>discussion got stuck concerning this.
>I was asking, as a side discussion, to tie forms with method=get more
>explictly to getMarkup().
>The reasoning for this is mainly that it would comply to the W3C
>architecture (http://www.w3.org/TR/webarch/) and would enable use cases
>where portlets use forms and add parameters to forms dynamically for their
>navigation (not for changing state).
>As one example I raised then, was how to solve the "URL manipulation"
>requirement Rich raised by using forms with method=get and dynamically add
>form params.
>
>This would basically mean that we would need to:
>- add form params to MarkuParams which would be passed with getMarkup.
>- 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 advantages I see:
>- natural representation of method=get as resource/markup fetching in
>contrast to state changes in pbia()
>- conformance to W3C arch
>- enables cachability of pages using method=get uncluding their invokations
>results, i.e. if zipcode is a form field, consumers can cache portlet
>markup with zipcode=10000 and zipcode=20000. (yes, invalidation caching
>would help :-) but we don't have it yet)
>- enables searchability and crawlability of portlets using such forms
>
>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
>
>  
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]