OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] GET, POST and render URLs



Andre Kramer wrote:
> I agree with everything except the last two sentences! I prefer the
> performInteraction proposal (non-blocking with no nav state changes) but
> would consider re-naming it to "performRender" or simply "render".
> Inputs on getMarkup would confuse, as developers would expect them to be
> always present (implied replay after performBlockingInteraction).

Why would the developer expect those params on all requests. The same 
developer also authors the page that generated this request.

Regards,
Subbu

> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 17 August 2005 15:26
> To: wsrp@lists.oasis-open.org
> Subject: [wsrp] GET, POST and render URLs
> 
> During last week's interfaces call, we discussed the question of GET,
> POST and render URLs. To follow up this discussion, I would like to make
> 
> a few comments.
> 
> At a semantic level, I see two different issues here.
> 
> a. Mapping GET to getMarkup request, leaving POST for interactions.
> 
> b. Supporting render URLs via getMarkup.
> 
> AFAIR, it was the second issue that prompted the first one. I think we
> can make some progress if we treat these as two seperate issues.
> 
> On the first question, I don't think that the protocol ought to specify
> whether a user-agent's GET request be mapped to getMarkup (or
> getResource) or not. The decision should be left to the Consumer. I
> don't see this as breaking HTTP or the W3C arch recommendations. We're
> just letting the Consumer make the choice.
> 
> The second question addresses a hole in the current specification.
> Currently, WSRP only supports render URLs whose parameters are known at
> the time of generating the markup. This prevents a portlet from
> capturing request data via a form or a URL created dynamically in the
> browser.
> 
> To support a render URL, Consumers currently resort to a
> performBlockingInteraction, and this has several side effects.
> Performance is definitely one concern. But my main concern is the
> mapping of semantics. For instance, the pbia would cause new nav state
> which would replace the current nav state, and that's the not the intent
> 
> of render URLs.
> 
> I suggest that we add form parameters to getMarkup. This would allow the
> 
> consumers to correctly implement render URLs.
> 
> Regards,
> 
> Subbu
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]