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

[Michael Freedman <michael.freedman@oracle.com>]

I am not sure we can be confident that tomorrow's consumers will be more 
GET friendly.  To the degree JSF and/or ASP.NET get adopted as the MVC2 
platform of chocie by consumers we will continue to see a divergence as 
both of these platforms rely on POST pretty much exclusively.
    -Mike-

Subbu Allamaraju wrote:

> My take is that, HTTP has been very clear from the beginning that 
> method GET is most suited for idempotent requests, and that GET 
> requests can be replayed without side effects. Ideally, web developers 
> should be using GET forms for queries (e.g. a catalog search) and I 
> agree with Richard and Andre on that.
>
> Given this, I don't think the GET support is for legacy. Most HTTP and 
> REST advocates would definitely disagree with WSRP if we take the 
> opposite path (i.e. encourage POST always). You are right that some 
> consumers out there today do not support method GET in forms due to 
> more complex rewriting rules, but in time, I'm sure that will change.
>
> Subbu
>
> Michael Freedman wrote:
>
>> I am torn on this one.  Though I understand the technical logic of this
>> proposal, I am against anything that encourages less interoperability 
>> . From my perspective our support of form GETs were a bow to legacy
>> implementations with a recognized cost to the producer of a lack of
>> interoperability.  Yes, allowing producers with such legacy code to
>> represent their Form GETS as "renders" is most natural however I want to
>> encourage these developers to update their code to rely on POST anyway
>> so they run in all consumers.  Forcing the use of PBI [the POST style]
>> nudges them down this path.
>>     -Mike-
>>
>> 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
>> >
>> > >
>>
>>
>