Sounds like a good plan.
Rich Thompson wrote:
I agree that many of the sections
about
portlet url parameters are clear about when the parameter makes sense
(e.g.
the two you cite). I suspect there could be value to reworking the BNF
section to reflect those restrictions all in one place.
There are quite a few places where
we
comment on some field of a reused structure not having an impact (most
common is probably the usage field in the PropertyDescription
structure).
If we can agree on other fields where such comments make sense, I would
favor adding them for the purpose of making the spec more crisply
defined.
Richard is proposing preferedTitle is one such field.
Rich
FYI I had recently checked this:
Section 10.2.1.5 and 10.2.1.6 are very explicit about where wsrp_mode
and window_state are valid:
The wsrp-mode portlet URL parameter MAY be used whenever the
wsrp-urlType portlet URL parameter has a value of “blockingAction” or
“render”.
The wsrp-windowState portlet URL parameter MAY be used whenever the
wsrp-urlType portlet URL parameter has a value of “blockingAction” or
“render”.
-Mike-
Richard Jacob wrote:
>What also strikes me in this context is that we seem to be
ambigeous
when
>we're reusing our structures / url-rewrite-tokens.
>I think we should have a more crisp definition on which structure
>elements/members sense (or are even allowed) for which operation.
>I would argue that this significantly helps developers in
understanding
and
>implementing the same protocol without the possibility to
(mis-)interpret
>the spec in different ways.
>So it's a tradeoff between protocol flexibility and protocol
clarity.
>One example here is the reuse of markupContext with getResource().
I don't
>think that setting a new portlet title makes sense when delivering
a
>resource if we agree on Rich's semantical differentiation between
>getMarkup() and getResource() - and I have the sense that we
probably
have.
>The same issue is the window state and portlet mode in resource
URLs.
>
>Reviewing chapter 10 it striked me that we don't clearly describe
which
url
>parameters are allowed for which url-type (example wsrp-url in
action
URLs
>makes definitly no sense).
>I would therefor mandate to rewrite the BNF of our URL formats to
clearly
>denote which url params can be used for which url-type. Also I would
>suggest to use BNF notation to denote mandatory and optional
parameters.
>I think this would also help developers to understand the semantics
of the
>URLs and their according operations better.
>
>Mit freundlichen Gruessen / best regards,
>
> Richard Jacob
>______________________________________________________
>IBM Lab Boeblingen, Germany
>Dept.8288, WebSphere Portal Server Development
>WSRP Team Lead & Technical Lead
>WSRP Standardization
>Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
>Email: mailto:richard.jacob@de.ibm.com
>
>
>
> Rich Thompson
> <richt2@us.ibm.co
> m>
To
>
WSRP TC
<wsrp@lists.oasis-open.org>
> 02/21/06 05:21 PM
cc
>
>
Subject
>
Re: [wsrp]
Clearification: Resource
>
URLs and
markup params, etc.
>
>
>
>
>
>
>
>
>
>
>
>I agree with your general comments; Without having spent much time
>reviewing this phrasing, I would think the clarifications would look
>something like:
>
>- (6.1.13 - MarkupResponse): Since the MarkupContext structure could
>provide a new sessionID after the Consumer has begun sending the
page
to
>the End-User, special handling is required in order to not lose
state
>related to the new session. Even for stateless Consumers, there are
>techniques to properly handle this issue (e.g. HTTP cookies).
>
>- (6.2 - getMarkup): This operation's semantics are that the
Consumer
is
>aggregating a page which includes the Portlet's markup.
>
>- (6.3 - getResource): This operation's semantics are that the
client
has
>requested additional information in a manner that utilized the
Consumer
as
>a proxy for supplying that information.
>
>Rich
>
>
> Subbu Allamaraju
> <subbu@bea.com>
>
>
To
> 02/21/06 10:12 AM
Rich Thompson/Watson/IBM@IBMUS
>
cc
>
WSRP
TC
>
<wsrp@lists.oasis-open.org>
>
Subject
>
Re:
[wsrp] Clearification:
>
Resource
URLs and markup params,
>
etc.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>>As to session, I agree that getMarkup already introduces the
problem
of
>>a late notification that a new session now exists. What would
people
>>think about adding text to 6.1.13 (MarkupResponse definition)
describing
>>how a stateless Consumer would need to write any new session
information
>>to a cookie since it is likely too late to place that
information
onto
>>all URLs within the page (I suppose the other option is to
require
>>Consumer URL rewriting and delay all rewriting until responses
have been
>>received from all Portlets ... I would not favor describing
this
option
>>in the spec)?
>>
>>
>
>Instead of mentioning specific implementation choices, how about
>highlighting the fact that consumers must be ready to honor
sessionID
>changes getMarkup and getResource so that they can provide
meaningful
>user experience?
>
>
>
>>Just to not loose potential spec changes suggested so far (does
this
>>list miss any??):
>>
>> 1. Clarify difference in the semantics of getMarkup and
getResource:
>> Consumer request related to page aggregation
vs client request
>> related to need for additional information.
>>
>>
>
>In principle, I agree, but would not want to make statements that
limit
>the use of getResource to static resources, or such requests to be
>always driven by client requests after markup generation. The
consumer
>may want to pre-fetch resources.
>
>
>
>> 2. Add sentence(s) to MarkupResponse.sessionContext (6.1.13)
>> describing how a stateless Consumer can handle
such late knowledge
>> of a new Portlet session.
>>
>>
>
>Agreed.
>
>
>
>> 3. 6.9/6.10 should note that HandleEventsResponse can also
return
>> newMode and newWindowState (see above quote
from 6.9).
>>
>>
>
>Agreed.
>
>Subbu
>
>
>
>
>
>>*Richard Jacob <richard.jacob@de.ibm.com>*
>>
>>02/21/06 06:04 AM
>>
>>
>>To
>> Subbu
Allamaraju <subbu@bea.com>
>>cc
>> WSRP TC
<wsrp@lists.oasis-open.org>
>>Subject
>> Re: [wsrp]
Clearification: Resource URLs and markup
>>
>>
>params, etc.
>
>
>>
>>
>>
>>
>>
>>
>>Subbu Allamaraju <subbu@bea.com> wrote on 02/21/2006
05:50:37
AM:
>>
>> > > - 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.
>> >
>> > My interpretation is that, these parameters apply to the
portlet
>> > processing the request, and not necessarily to the
consumer
applying
>> > decorations to the markup returned. When a URL contains a
parameter
>>
>>
>with
>
>
>> > a specific window state, the consumer is merely asking
the
producer to
>> > generate markup or resource reflecting that window state.
I don't see
>>
>>
>a
>
>
>> > requirement in the spec to change the window state or
mode
of the
>> > portlet, although that's what typical portal-consumers
may
do.
>> >
>>huh?
>>We explicitly say that an URL invocation of a render/pbia URL
includes
>>
>>
>the
>
>
>>request to change the mode/window state.
>>Therefor I would say the contrary: Consumers should honor this
(or be
>>strongly advised to do so) otherwise
>>the user experience will suffer. It seems strange for me to
ignore
the
>>request. I mean we're trying to define a common aggregated UI
behavior
>>
>>
>and
>
>
>>this certainly contradicts it.
>>
>> > > - 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
>> >
>> > I think, this interpretation is specific to what the
consumer
is doing
>> > with the markup or resource. If the consumer is
aggregating
the
>>
>>
>response
>
>
>> > into a page that has windows-like titlebars, it might use
the title in
>> > the manner you suggest. Other usages of this field are
possible.
For
>> > example, a special purpose consumer may be displaying
resources
in
>>
>>
>popup
>
>
>> > browser windows, and use the title in the browser title
bar.
>> >
>> > > - 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.
>> >
>> > I agree that the stateless consumer use cases break down
with
>>
>>
>sessionID
>
>
>> > returned from getMarkup or getResource. As Mike points
out,
we have
>>
>>
>this
>
>
>> > problem with getMarkup itself.
>> >
>> > > 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?
>> >
>> > Is it impossible to keep the consumer stateless? Perhaps
not. To be
>> > truely stateless, consumer can't just push various pieces
of state
>>
>>
>into
>
>
>> > the markup when the page is getting generated on the
server
side and
>> > expect the state to ramain constant.
>>I think currently they can because the render result is a
result
of the
>>Consumer processing. Therefor the Consumer has the control.
>>
>> > IMO, consumers will have to rely on
>> > browser side gimmicks to support state updates that
happen
after the
>> > page aggregation started (with getMarkup), or even much
later
(with
>> > getResource).
>>Well, things brings us again to AJAX style.
>>But this breaks the "rule" that the Cosumer is in control
and that the
>>
>>
>page
>
>
>>state is opaque/mainted by the consumer.
>>Now you seem to imply that portlets/resources can manipulate
the
overall
>>page state. I think this isn't true with what WSRP defines
today
and to
>>enable that we would need to drop some level of opaqueness of
the
overall
>>state.
>>
>> >
>> > Subbu
>> >
>> > >
>> > > Rich
>> > >
>> > >
>> > > *Subbu Allamaraju <subbu@bea.com>*
>> > >
>> > > 02/15/06 11:48 AM
>> > >
>> > >
>> > > To
>> > > WSRP TC <wsrp@lists.oasis-open.org>
>> > > cc
>> > >
>> > > Subject
>> > > Re: [wsrp] Clearification: Resource URLs
and markup params, etc.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > 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
>
>
>> >
>> >
>> >
>> >
---------------------------------------------------------------------
>> > 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
>
>
>
---------------------------------------------------------------------
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
|