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

[Stefan Hepper <sthepper@hursley.ibm.com>]

I think as soon as these frameworks will introduce a similar concept to 
navigational state they also need to look into supporting form GETs.

In addition to the advantages Richard pointed out below it also supports 
the browser back button and bookmarkability (both of these are 
problematic at least in the current JSF and .NET implementations). If 
you want to support the back button you would need to do a redirect 
between the action and render phase, which is very expensive.


Stefan

Michael Freedman wrote:
> 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
>>> >
>>> > >
>>>
>>>
>>
> 
> 
>