Re: [wsrp] GET, POST and render URLs

[Subbu Allamaraju <subbu@bea.com>]

May be I'm misunderstanding something, but with portlet APIs like 
JSR168, the portlet or the container needs to encode some key to decide 
what to render, except for the initial view.

Regards,
Subbu

Andre Kramer wrote:
> 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
>