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 user agent (browser) to Web Site (consumer) and consumer to
producer conversations as separate, with the URL type controlling the
latter and method="GET/POST" the former. But I agree with Richard that
developer education would certainly help.

While we added form inputs to getResource, I think that adding them to
getMarkup would raise an expectation that inputs are re-sent to the
render phase from the action so I would not wish to add to getMarkup.
How about defining a new public parameter "form-method" with values
"GET/POST" to allow a consumer to remind the Web developer of her
intended Web semantics? Of course, if a consumer re-writes forms this
may not have the expected value!

Regards,
Andre

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com] 
Sent: 12 July 2005 11:01
To: Subbu Allamaraju
Cc: wsrp-interfaces@lists.oasis-open.org
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]