[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp] GET, POST and render URLs
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). Regards, Andre -----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]