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.


Rich,

Thanks;
Thats explains subtleties.
Regards,

Wesley


Rich Thompson wrote:

>
> Good questions!
>
> 1. The difference in language you note was decided on (this was one of 
> the more protracted discussions around conformance language ...) based 
> on the difference in the Consumer processing required to approve the 
> request. Both strongly encourage approval, but the windowState 
> language recognizes reasons for denial might not be exceptional (e.g. 
> overall page integrity plays a role).
>
> 2. You are right that the real thing is having MarkupParams always 
> contain the actual value after the Consumer has processed any request 
> to change a mode or windowState value. I also tend to agree that some 
> reference to the actual semantics in 10.2.1.5 and 10.2.1.6 would be 
> useful. This is orthogonal to the question of whether the semantics of 
> getResource preclude even requesting a mode or windowState change ...
>
> Rich
>
>
> *Wesley Budziwojski <wesley.budziwojski@Sun.COM>*
>
> 02/22/06 06:06 PM
>
> 	
> To
> 	Rich Thompson/Watson/IBM@IBMUS
> cc
> 	WSRP TC <wsrp@lists.oasis-open.org>
> Subject
> 	Re: [wsrp] Clearification: Resource URLs and markup params, etc.
>
>
>
> 	
>
>
>
>
>
> I was wondering if you could clarify;
>
> 1)Mode/state
> It seems that request and change of both wsrp-mode and 
> wsrp-windowState are intended to happen in the same fashion that is
> Porlet requests a change, consumer MUST honor it (unless exception), 
> consumer reflects status in markup param?
> However wording in respective sections is slightly different:
>
> "consumer MUST respect requests to change the mode outside of 
> exceptional circumstances ()"
> "consumer SHOULD choose to respect this request to change the window 
> state.."
>
> If indeed the intended behavior was the same the wording should 
> reflect that.
>
>
> 2) Section10.2.1.5 and 10.2.1.6
> changing mode or windowState param in MarkupParams is secondary thing 
> IMHO the actual request is to change mode or windowState.
> Consumer reflect "acceptance" (or deny if special circumstances arose) 
> of the request by submitting proper params?
>
> Those sections have references to 6.9/6.10 but only in context of 
> allowable selection.
> Making a general reference in terms of actual semantics of 
> request/change would be useful IMO particularly for the reader who 
> jumped to this section without reviewing 6.0
>
> Thanks,
> Wesley
>
> Rich Thompson wrote:
>
> I think one must examine the meaning of the portlet url parameters 
> before attempting to assign meaning for potential new uses. In the 
> case of wsrp-mode, the meaning is defined in 10.2.1.5 as "a request to 
> change the mode parameter in MarkupParams into the mode specified as 
> the value for this portlet URL parameter". Section 6.9 discusses how 
> the mode parameter describes the Consumer is management of the 
> End-User's interactions with the Portlet and that all the Portlet can 
> do is request changes related to this management. Consumer denial of 
> the request is limited to "exceptional circumstances" with a provided 
> example of "access control restrictions". What I am hearing on this 
> email thread is that people view processing a resource URL as another 
> such example as the semantics of a resource URL do not provide an 
> opportunity for the Consumer to adjust how it is managing the 
> Portlet's markup.
>
> Of course there are implementation choices which allow the Consumer to 
> impact the larger page as part of a URL activation, but I would argue 
> there is a semantic mismatch between those implementation choices and 
> what the spec defines for a resource URL. Rather than attempting a 
> force fit of the semantics, I would encourage exploring whether those 
> choices aren't actually extending the getMarkup semantics to include 
> partial page updates. I suspect that is a better semantic match and it 
> explicitly recognizes that the protocol is being extended by the 
> implementation.
>
> Rich
>
> *Subbu Allamaraju <**_subbu@bea.com_* <mailto:subbu@bea.com>*>*
>
> 02/21/06 10:34 PM
>
> 	
> To
> 	WSRP TC <_wsrp@lists.oasis-open.org_ <mailto:wsrp@lists.oasis-open.org>>
> cc
> 	
> Subject
> 	Re: [wsrp] Clearification: Resource URLs and markup params, etc.
>
>
>
>
> 	
>
>
>
>
>
>
> Interesting. I have not noticed this till you pointed it out.
>
> What does it then mean to supply windowState and mode params with
> getResource requests? To keep these symmetric, we should include these
> params for resource URLs, and specify that these parameters do not
> indicate a mode/window state change, but only apply to the current 
> request?
>
> Subbu
>
> Michael Freedman wrote:
> > 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_ <mailto:richt2@us.ibm.co>
> >> m>
> >> To WSRP TC
> >> <_wsrp@lists.oasis-open.org_ <mailto: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_ <mailto:subbu@bea.com>>
> >>
> >>
> >> To 02/21/06 10:12 AM Rich
> >> Thompson/Watson/IBM@IBMUS
> >>
> >> cc WSRP
> >> TC
> >> <_wsrp@lists.oasis-open.org_ <mailto: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_ 
> <mailto:richard.jacob@de.ibm.com>>*
> >>>
> >>> 02/21/06 06:04 AM
> >>>
> >>>
> >>> To
> >>> Subbu Allamaraju <_subbu@bea.com_ <mailto:subbu@bea.com>>
> >>> cc
> >>> WSRP TC <_wsrp@lists.oasis-open.org_ 
> <mailto:wsrp@lists.oasis-open.org>>
> >>> Subject
> >>> Re: [wsrp] Clearification: Resource URLs and markup
> >>>
> >>
> >> params, etc.
> >>
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Subbu Allamaraju <_subbu@bea.com_ <mailto: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_ <mailto:subbu@bea.com>>*
> >>> > >
> >>> > > 02/15/06 11:48 AM
> >>> > >
> >>> > >
> >>> > > To
> >>> > > WSRP TC <_wsrp@lists.oasis-open.org_ 
> <mailto: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_
>
>
> --------------------------------------------------------------------- 
> 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]