[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp] GET, POST and render URLs
getMarkup would be shared between requests with inputs and requests to fetch markup - hence the potential for confusion. Regards, Andre -----Original Message----- From: Subbu Allamaraju [mailto:subbu@bea.com] Sent: 17 August 2005 16:53 To: wsrp@lists.oasis-open.org 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 > --------------------------------------------------------------------- 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]