[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams
You convinced me of the issues with such a field. Thanks Subbu Andre Kramer wrote: > I remember this being discussed for 1.0 (having brought it up). I > abandoned it then as: > > 1) a consumer to user agent / client protocol (if any) may not even be > HTTP based. > > 2) a consumer should be free to re-write "URLs" (see 1) as it likes > (even switching method). > > (d) would also significantly lessen any value of this field ... > > Regards, > Andre > > -----Original Message----- > From: Subbu Allamaraju [mailto:subbu@bea.com] > Sent: 01 November 2004 14:57 > To: wsrp@lists.oasis-open.org > Subject: Re: [wsrp] [CR308] - Add requestMethod field to MarkupParams > > Here is another attempt to justify the need for this field. I'm assuming > J2EE environment here, but the same must be true for others. > > a. One of the possible implementations of a Producer is a portlet > container which creates a runtime for portlets. The runtime includes > request and response objects (e.g. HttpServletRequest, and > HttpServletResponse) among other things. Currently, except for the > method used, it is possible to provide usable request and response > objects to portlets. > > b. It should be easy to use third party code (such as servlets, JSPs, > tag libraries etc) in portlets. For example, if a third-party JSP tag > library relies on the request method to do something special, it should > not break or misbehave when it is deployed in a producer runtime. > > c. The proxy example is non-trivial. However, instead of relying on a > getMethod()-like method, the portlet will have to take some extra steps. > > d. Making this field optional would address cost considerations. > > Finally, it is difficult to explain web developers why the Producer > runtime cannot provide a dependable getMethod, because, for portlet > developers, the Producer runtime is (should be) no different from a > typical web container. > > Subbu > > Rich Thompson wrote: > > > > 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. > > > > > > > > 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]