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' mandating that form submits with method=get should be considered as
getMarkup calls.
Yes, this is mainly teaching the portlet programmer. But to do this the
Consumer must be enabled to provide the data send with the method=get form
submit to be transfered back to the portlet.
Currently we don't have the possibility for it in the protocol.
The only way is to encode the form action as a pbia() which does not
naturally fit a from method=get.
One document that lines that out too, is the W3C architecture document.

The problem I see is that portlet programmers who want to have  a clean
design here, can't do it with the current protocol.
However I'm aware of the fact that not necessarirly all consumer support
method=get.

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


                                                                           
             Subbu Allamaraju                                              
             <subbu@bea.com>                                               
                                                                        To 
             07/11/2005 05:36          wsrp-interfaces@lists.oasis-open.or 
             PM                        g                                   
                                                                        cc 
                                                                           
                                                                   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]