Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams

[Rich Thompson <richt2@us.ibm.com>]

The reason I am raising the questions
is that I understand the cost of adding such a field (Consumer has to serialize
another piece of information into each getMarkup message), but still don't
really understand the value. 

Presume there is a portlet that can
act as a proxy for a number of resources (urls). Lets consider the explicit
case where its current markup contains links of some form that allow the
user to navigate to one of these proxied resources. In order to write those
links into the markup, the portlet had to know enough about the resource
to collect any required parameters, etc and devise a scheme by which that
information will flow back to the portlet. This could be done either directly
(i.e. pushed onto the link, perhaps using a form if the user is to enter
some part of the data) or indirectly (i.e. a reference to info the portlet
is storing is pushed onto the link). It seems to me that the nature of
how the resource is fetched is only one piece of the info the portlet has
to have in order to proxy things properly. I also don't see that there
is necessarily a direct relationship between how the portlet get the info
it needs to communicate with the resource and how it must pass that info
to the resource. As a result, I am not understanding the value such a field
would bring.

Rich

Subbu Allamaraju <subbu@bea.com>

10/22/2004 09:52 AM

To	wsrp@lists.oasis-open.org
cc
Subject	Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams

Some primary considerations for adding this filed:

a. Although not common enough, this field would make it easy for web 
developers to write portlets without learning about the complexities.

b. Producer implementations don't necessarily parse the entire markup 
being generated (except for links and IDs). Without parsing the markup
Producers cannot embed the request type into links. Parsing the markup
just for the sake of embedding the request type may not be efficient.

Is there a strong reason against including such a field? This field 
seems very harmless to me.

Subbu

Rich Thompson wrote:
> 
> My primary question is whether it is a common enough use case to require
> the Consumer to provide the field on every getMarkup message to every
> portlet. My first thought is that it does not rise to that level and
> that it is easy enough for a portlet to provide such proxying when
it 
> wants to. It also is not difficult for a platform that wants to 
> automatically make such info available to the portlets it hosts to
add 
> and remove an indicator from the navState.
> 
> As an aside, should the Primer capture the issues involved with trying
> to use a post with a render url? Things such as submitted forms are
> likely to be lost as they don't translate into anywhere on the getMarkup
> message.
> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 10/19/2004 01:28 PM
> 
>                  
> To
>                  Rich
Thompson/Watson/IBM@IBMUS
> cc
>                  wsrp@lists.oasis-open.org
> Subject
>                  Re:
[wsrp] [CR308] - Add requestMethod field to MarkupParams
> 
> 
>                  
> 
> 
> 
> 
> 
> That is the work-around with WSRP1.0. Any reason against adding such
a
> field? It would make it easy for web developers.
> 
> Subbu
> 
> Rich Thompson wrote:
>  >
>  > Do we really need this field? The portlet has to already
know this to
>  > have coded the URL to use the right method. It can easily
use that
>  > knowledge (possibly by passing it to itself in navState)
if it is
>  > actually proxying the markup from somewhere else.
>  >
>  > Rich
>  >
>  >
>  > *Rich Thompson/Watson/IBM@IBMUS*
>  >
>  > 10/19/2004 09:00 AM
>  >
>  >                
 
>  > To
>  >                
 wsrp@lists.oasis-open.org
>  > cc
>  >                
 
>  > Subject
>  >                
 [wsrp] [CR308] - Add requestMethod field to MarkupParams
>  >
>  >
>  >                
 
>  >
>  >
>  >
>  >
>  >
>  >
>  > Document: Spec
>  > Section: 6.1.9 MarkupParams Type
>  > Requested by: Subbu Allamaraju
>  > Old Text:
>  > New Text:
>  >   [O] string      requestMethod
>  >
>  >   . requestMethod: This field indicates the type of
the HTTP request
>  > used by the client to submit data to the Consumer. The
Consumer MUST
>  > supply a valid HTTP method as specified in Section 5.1.1
of RFC 2616 as
>  > a value for this field.
>  >
>  > Reasoning: In most situations, portlets can be programmed
to be agnostic
>  > to how the client submitted a request to the Consumer.
However, there
>  > are situations where a portlet must be aware of the type
of the request
>  > (such as GET, POST etc.) used by the client. For example,
a portlet may
>  > be acting as a proxy to fetch resources over HTTP from
remote server. In
>  > this case, the portlet must be aware of the request type
so that it can
>  > faithfully proxy resources.
>  >
>  > In the current protocol, portlets can dictate the method
type used for a
>  > request within the markup (e.g., HTML forms, links, JavaScript
etc). But
>  > portlets cannot infer the method used by the client without
explicitly
>  > embedding it in its navigationalState for every URL created.
The
>  > proposed optional requestMethod field will address this
need.
>  >
>  > Errata? no
> 
> 


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgroup.php.