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.


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



Michael Freedman <michael.freedman@oracle.com>

02/21/06 12:50 PM

To
WSRP TC <wsrp@lists.oasis-open.org>
cc

Subject
Re: [wsrp] Clearification: Resource URLs and markup params, etc.







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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]