[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interfaces] tie method=get to getMarkup
Thanks for correcting. I missed that the content type is not valid for GET. I agree with your proposal, as long as the spec won't provide guidelines on whether to use GET or POST, since there are other efforts (e.g. W3C) to do that. Regards, Subbu Richard Jacob wrote: > 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]