[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] tie method=get to getMarkup
I agree that of course the URL-Type dictates which operation to invoke.
It's merely teaching best practices - and enablement of these best
practices.
If a portlet programmer decides to handle everything through pbia(), that's
fine but maybe not a good design.
But if a portlet programmer chooses to comply with some web best effort
techniques, we shouldn't prevent him to do so.
So to your suggestion:
a) would definitly help
b) b is not valid for method=get
I think the content type "application/x-www-form-urlencoded" is only set
for forms sent by an HTTP post.
In the case of forms using method=get the form params are sent as the query
string argument, that's it.
So the proposal should be that consumer would sent query string params
targetted for portlets as markupParams->formParams (or however we may call
them, but this seems to fit best)
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 06:17 wsrp-interfaces@lists.oasis-open.or
PM g
cc
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]