Yes, I generally agree with the semantics you have described. I think
it is premature for us to warp getResource into the solution for
getting a portlet fragment -- i.e. supporting Ajax. I think it is just
as likely, if not more so, that we will model this via another API and
keep getResource as an in protocol synonym for our proxy resource
function.
As for stateless consumer, huh? getMarkup already returns a
SessionContext pretty much requiring a stateful consumer or at least
adding such language to getResource would seem to add no additional
burden.
-Mike-
Rich Thompson wrote:
This thread happened during a period
when I had connectivity issues and I am just catching up on such
threads.
While there are a number of
particular
questions raised, the larger issue appears to be a need for greater
clarity
on the relationship between getMarkup and getResource. I suspect the
confusion
arises because of the similarity in signature due to both possibly
generating
markup while the difference between them is in the semantics. Here is
my
take on this difference:
- getMarkup: Semantics are that
the Consumer is aggregating portlets into a page. The signature
supplies
data to assist in generating appropriate markup (e.g. mode, navState,
etc)
and allows the return to impact more than just the Portlet's portion of
the aggregated page (e.g. title). Render URLs cause getMarkup
invocations
and are allowed to impact most pieces of the supplied data.
- getResource: Semantics are that
the
client is requesting additional information (image, data, markup, etc)
of the Portlet. This tunnels through the Consumer as a SOAP request,
but
otherwise does not impact the Consumer's handling of the page. The one
processing requirement I could see placing on Consumers is retaining
any
new sessionID the Portlet returns, but even that is questionable. The
reason
it is questionable is that we explicitly state that a stateless
Consumer
is one of he design points the protocol supports. Adding a requirement
to maintain such returned sessionIDs is tantamount to requiring the
Consumer
be stateful. I would want to think through reasonable approaches for a
stateless Consumer before approving such a requirement. Relative to
specific:
- wsrp-mode and
wsrp-windowState portlet url parameters. I would note the descriptions
of these explicitly state that they apply to render and blockingAction
urlTypes. I think maintaining the integrity of the aggregated page
requires
that these not be supported on resource URLs, unless someone can point
out how a Consumer's decorations could be changed or how it would
actually
place a Portlet into maximize windowState as a result of a resource URL
activation.
- title:
This is another case of the Portlet having opportunity to impact the
Consumer
generated portion of the page during page aggregation and therefore
doesn't
apply to resource url processing
- sessionID:
I am willing to debate this one as I can see a number of good use cases
for the Portlet returning a new session, but how a stateless Consumer
could
handle it is important.
In summary, perhaps we need to more
explicitly state the semantic difference between these operations. Do
people
generally agree with the semantics I have described above? Do people
have
other proposals which keep the stateless Consumer supported? Are people
willing to throw out the stateless Consumer design point statements?
Rich
The issue of a producer returning two sessionIDs
in
parallel requests is
possible, and I don't know if the spec can help either the consumer or
the producer.
One way of avoiding returning new sessionIDs is to somehow tie
initCookie with sessionIDs, and raise InvalidCookie fault when there is
a need to return new sessionID. It is possible to design a producer to
tie init cookies to sessions, and never return sessionIDs.
We have had a number of discussions on this topic in the past, and the
solutions are not always pretty.
Subbu
Stefan Hepper wrote:
>
> Subbu Allamaraju wrote:
>> 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.
>>
>
> right, I think that needs to be clearified.
>
>> 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.
>>
>
> what happens if you make a parallel render call in that case?
Shouldn't
> the spec that in that case that the session id returned by both
calls
> must be the same (like in the JSR 168 case where different
portlets
of
> the same web app can create a new session in parallel at render
time)?
>
>> 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.
>>
>
> Still sounds confusing to me that the spec states for title:
> " The title the Portlet would prefer to be used in any decoration
of the
> markup."
> what are decorations for resources?
>
> Stefan
>
>> 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
>>
>>
>>
---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
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
|