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] Clearification: Resource URLs and markup params, etc.


On the question of modes and states, I don't see why a portlet should 
not specify mode and window state params on a resource URL. The resource 
generated may depend on the window state and mode.

The real question is whether the mode and window state specified in a 
resource URL applies to  subsequent getMarkup/pbia/he calls or not. The 
spec leaves this open. It also leaves the same question open for normal 
action and render URLs.

On your point on session, the question is not whether a portlet can 
return a new sessionID or not, but how it relates to the sessionID 
returned via a getMarkup/pbia/he. If a producer chooses to return a new 
sessionID, I would expect the consumer to use that in subsequent calls. 
This is because, from the consumer's point, getResource is just another 
request for a portlet.

I can see at least one use case for returning a new sessionID. That is 
when a portlet is generating the resource, e.g. to generate some 
response for an Ajax request. It should be able to create new session 
either when there is no session currently, or when the current session 
expired.

On the question of title, my interpretation is that the title returned 
via any operation applies to the current markup returned, and it is up 
to the consumer to treat it as a new title replacing the current one, or 
use it just for that rendition of the markup/resource. So, I don't an issue.

Subbu

Stefan Hepper wrote:
> Subbu Allamaraju wrote:
>> Stefan Hepper wrote:
>>> I've some questions regarding the resource URLs. From the current 
>>> version of the spec it is not clear to me how getResource and 
>>> getMarkup relate to each other.
>>> - What happens if I specific new nav params, new portlet mode / 
>>> window state on the resource URL? Will they be valid for the next 
>>> getMarkup call?
>>
>> Should they be? I think the semantics are the same as that of a render 
>> URL.
> 
> Depends if we say that getResource and getMarkup are related or not. I 
> think they they should be related and that there should be only one set 
> of portlet mode, window state, nav params, per POP. I also think that we 
> should not allow a resource URL to change this state, that doesn't make 
> sense to me.
> 
>>
>>> - What are the semantics for portlet mode and window state when 
>>> rendering a resource? What portlet mode and window state will the 
>>> portlet receive if nothing is specified?
>>
>> I would assume that this is up to the resource handler or the producer 
>> or portlet.
>>
> 
> You mean that the result may be different per mode or window state? I 
> can see use cases for this, but think that the spec should state that 
> the getResource calls gets the current portlet mode and window state.
> 
>>> - Can you specify navigational state on a resource URL? (yes I assume 
>>> based on the current spec)
>>
>> Yes
>>
>>> - Why can the getResource call create a new session?
>>
>> It might, if the consumer does not include the current sessionID.
>>
> 
> Why would a getResource call need to create a session? What would be the 
> use case?
> 
>> Could you elaborate on why you think getResource and getMarkup are not 
>> related. As far as the context provided by the consumer is concerned, 
>> they are similar. The only difference is on the semantics of the 
>> response.
>>
> 
> When reading the spec again I could not find a sentence saying that they 
> are related. I think this needs to be clarified.
> 
> Another thing I noted is that the getResource operation is allowed to 
> change the portlet title. I think that does not really make sense. What 
> is the use case for allowing to change the title in getResource?
> 
> Stefan
> 
>> 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]