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 see the problem, but I don't think that the protocol should mandate 
HTTP request mapping to WSRP operations. We already have url-type to 
dictate that.

Just thinking aloud, would it help if the spec provides for the following:

a. Add a formParameter array to MarkupContext
b. Add a requirement that the consumer MUST/SHOULD collect request 
parameters when the content type matches 
"application/x-www-form-urlencoded".

This leaves out any requirement to map GET requests to 
getMarkup/getResource, and lets url-type to dictate the type of WSRP 
request that must be sent to the producer.

Regards,
Subbu


Richard Jacob wrote:

>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]