[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44 (set new public params)
I don't understand why/how form parameters are to be merged by the
consumer. But is the GET URL then just tracking which slots the portlet
wants and defining default values (which could be in the private nav
state instead)?
Keeping values private to the consumer on a per portlet basis seems to
imply both a heavy burden on the consumer and duplicates nav state
maintenance the portlet needs to do anyway.
As I suggested to Mike, maybe a limited / no - update forwarding of
consumer values is all that is required? With no push back of values we
avoid the issues inherent in maintaining or not maintaining sets of
parameters and user / developers expectations that values be
synchronized.
Regards,
Andre
-----Original Message-----
From: Stefan Hepper [mailto:sthepper@hursley.ibm.com]
Sent: 27 July 2005 13:07
To: Andre Kramer
Cc: Michael Freedman; wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue
#44 (set new public params)
One compelling use case I see for PPs restricted to one portlet is the
support for Form GET :-) so that the consumer can merge the form
parameters into the public parameters.
If I remember the discussion of the non-blocking action semantics
correctly it is different from changing PPs, because you also would
change server side state in this action, but the state change would have
no side effects to other portlets.
I agree that you can also solve the use cases with pbia or events,
however, it is conceptually wrong and has many drawbacks and issues as
mentioned.
I don't see why my portlet that currently stores the selected zip code
as navigational state could not store it in the future as PP so that
Form GET will work and other portlets at least have the chance to access
the zip code. Why would something that the portlet developer currently
has decided can be changed by the end user without action semantic now
need an action semantic because it is shared with other portlets?
Stefan
Andre Kramer wrote:
> Hi Mike (you must be on UK time),
>
>
>
> Could you describe a use case were the PP is just shared between the
> consumer and one portlet? The only ones I can think of are really
> scenarios for a complex consumer (also know as rich or smart client)
> that should be doing Web Services calls that are application specific
> rather than piggy backing on a generic protocol like WSRP.
>
>
>
> My confusions about the separate issues may be caused by not seeing
uses
> that are not communicated between portlets (what I would call shared
but
> non-public) or not maintained between requests (what I would call
> transient). PPs promised to make coordinated values (such as current
> time zone communicated to multiple portlets) easier for portlet
> programmers than full blown event handling but seem to require that
they
> be public and non-transient.
>
>
>
> Thinking ahead, relaxing the blocking semantics of actions would help
> but would this not take the event handling communication round out of
> such interactions hence forcing (or encouraging depending on
viewpoint)
> use of PPs? I think I would rather encourage use of events and
> discourage PPs.
>
>
>
> Regards,
>
> Andre
>
>
>
>
------------------------------------------------------------------------
>
> *From:* Michael Freedman [mailto:michael.freedman@oracle.com]
> *Sent:* 27 July 2005 09:42
> *To:* wsrp-interfaces@lists.oasis-open.org
> *Cc:* Michael Freedman
> *Subject:* Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for
> issue #44 (set new public params)
>
>
>
> How did we take two separate discussions/issues, fuse them into one
and
> make the resulting discussion even more cloudy?
>
> Anyway, on PP let's get back to basics.
> Didn't we decide a few weeks back that we were not going to
> design/describe transient properties in this realease?
> Didn't we decide that PP were a separate concept from transient
> properties? And that the distinction between the two is that PP is
> public navigational state with no defined consumer scope while
transient
> properties are consumer managed state with defined scope?
> And don't we define public navigational state semantics as equivalent
to
> regular navigational state semantics except that the value is not
opaque
> to the consumer?
> So isn't the only issue here whether the use cases Stephan and Richard
> have given us are reasonable/preferrable to solve via PP [as compared
to
> using either events or the to be designed transient properties]?
>
> If so, here are my comments...I think we need to compare constrast
> supporting these use cases with PP vs transient properties. PP
doesn't
> introduce any notion of shared state -- each portlets navigational
state
> is its own. Transient properties will likely support a notion of
shared
> state. Yes, we can add some conventions to PP to require the consumer
> to associate PPs with the same name meaning they should receive the
same
> values -- and this is what we have suggested we use to support the use
> cases. If we want this semantics then, yes we need to offer
equivalent
> mechanisms to the portlet to set public navigational state as we do
> regular navigational state. I think Rich's proposal does this. If we
> end up thinking that once we have transient properties it will make
more
> sense to support these use case with them [since the scope of sharing
> will likely be defined/influenced by the portlets] then I would
suggest
> it might be better if we didn't add this behavior to PPs and merely
> leave them restricted to the defining portlet. If we choose this
later
> approach then we don't need any way for the portlet to set PPs as
> setting regular navigational state should suffice. [And remember, the
> use cases are supportable in 2.0 via events while we wait for a more
> efficient mechanism in 3.0].
>
> As for supporting method GET for render URLs, as I said last week, it
> seems what is being proposed here is exactly what performInteraction
was
> all about. Why isn't this merely a proposal that we add
> performInteraction back into the specification? Rich, can you dust
off
> the old performInteraction description and send it out to folks so we
> can see if we already have a completely designed and if I recall
agreed
> upon set of semantics?
> -Mike-
>
>
> Rich Thompson wrote:
>
>
> I'm sorry, but I find the whole SOAP vs REST debate irrelevant to this
> discussion.
>
> There are some key questions though:
>
> 1. Does the semantics of getMarkup match that of HTTP GET so that
> Consumers can use GET for render links?
>
> If the answer to #1 is yes (I think it is), then:
>
> 2. If PPs are added to URLs, can the Consumer support them for the
scope
> of the user interaction across all portlets on the page without
> violating HTTP GET semantics?
>
> 3. If PPs are added to URLs, can the Consumer support them for a scope
> encompassing multiple user interactions across all portlets interacted
> with and not violate HTTP GET semantics?
>
> I think the answer to all three questions is yes, though #3 requires
the
> Consumer to support PPs as part of its own navigation state. Common
web
> usage would also allow storing the PPs in a user session, though
> technically this would violate GET semantics as it is an update of
> server-side state.
>
> Rich
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>
> <mailto:andre.kramer@eu.citrix.com>*
>
> 07/26/05 10:05 AM
>
>
>
> To
>
>
>
> Rich Thompson/Watson/IBM@IBMUS, <wsrp-interfaces@lists.oasis-open.org>
> <mailto:wsrp-interfaces@lists.oasis-open.org>
>
> cc
>
>
>
>
>
> Subject
>
>
>
> RE: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44
(set
> new public params)
>
>
>
>
>
>
>
>
>
>
>
>
> But surely the (if any) desire is to enable GET semantics between the
> browser and the consumer Portal for optimized "render" interactions?
All
> WSRP operations today use SOAP (and therefore POSTs) and are
explicitly
> not REST. In any case, I would argue for a simple developer model that
> supports the use cases. These, for me, naturally require a statefull
> consumer to serialize updating changes to shared public parameters or
> could possibly be poorly supported by a set-for-one-interaction
> /one-shot imposed limitation. I don't particularly wish to go down the
> "Web GET/POST semantics" rat hole for WSRP just for such a limitation.
>
> Regards,
> Andre
>
>
>
>
>
------------------------------------------------------------------------
>
>
> *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* 26 July 2005 14:15*
> To:* wsrp-interfaces@lists.oasis-open.org
> <mailto:wsrp-interfaces@lists.oasis-open.org>*
> Subject:* RE: [wsrp-interfaces] Fw: [wsrp] Additional use cases for
> issue #44 (set new public params)
>
>
> I can definitely see useful coordination happening without the
reversion
> you describe if the Consumer chooses to treat PPs as part of the
> Consumer's navigational state. This keeps it from impacting state
> managed server-side (i.e. is compatible with GET semantics) while
> enabling ongoing, state-oriented coordination of the portlets being
> rendered for the user (i.e. once the zipcode PP is set, it stays at
that
> value until it is reset by some other user/Consumer/portlet action).
>
> Rich
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>
> <mailto:andre.kramer@eu.citrix.com>*
>
> 07/25/05 10:43 AM
>
>
>
>
>
> To
>
>
>
> Rich Thompson/Watson/IBM@IBMUS, <wsrp-interfaces@lists.oasis-open.org>
> <mailto:wsrp-interfaces@lists.oasis-open.org>
>
> cc
>
>
>
>
>
> Subject
>
>
>
> RE: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44
(set
> new public params)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Could Stefan & Richard please remind us as to when it is useful to
have
> a render URL affect other portlets on a page (just) for the duration
of
> one page fetch, when a subsequent refresh (browser button) is likely
to
> revert to the previous consumer state (as nothing permanent is being
> implied spanning consumer/portlets)?
>
> I suspect any useful coordination state change seems more related to a
> consumer effectively tracking and forwarding shared values and so the
> Web request to the consumer should itself be a POST to the
> consumer/Portal? Given PPs on render URLs that don't last v.s. PPs in
> action replies that do (SHOULD/MUST) aren't developers going to choose
> actions anyway, e.g. updating a charting page's units from imperial to
> metric?
>
> Regards,
> Andre
>
>
>
>
>
>
------------------------------------------------------------------------
>
>
> *
> From:* Rich Thompson [mailto:richt2@us.ibm.com] *
> Sent:* 25 July 2005 15:02*
> To:* wsrp-interfaces@lists.oasis-open.org
> <mailto:wsrp-interfaces@lists.oasis-open.org>*
> Subject:* Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for
> issue #44 (set new public params)
>
>
> I think it might be time to pull this discussion back out of the
> abstract space and relook at the use cases we have accepted as
compelling.
>
> Stefan & Richard have posted some use cases that clearly would benefit
> from PPs being settable on URLs and need a PP scope of at least the
user
> interaction ... including all portlets accessed during the processing
of
> the user interaction. Could you post use cases requiring broader
scopes?
> I presume that if we find them compelling, my answer to Mike's
previous
> inquiry about requiring Consumers to support PPs may need to change.
>
> Rich
>
> *Subbu Allamaraju <subbu@bea.com> <mailto:subbu@bea.com>*
>
> 07/25/05 09:06 AM
>
>
>
>
>
>
>
> To
>
>
>
> wsrp-interfaces@lists.oasis-open.org
> <mailto:wsrp-interfaces@lists.oasis-open.org>
>
> cc
>
>
>
>
>
> Subject
>
>
>
> Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for issue #44
(set
> new public params)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Stefan,
>
> This is question of scoping.
>
> As we have been debating, there are two options to let portlets update
> some shared state (public params). The first option is to let portlets
> encode such change in URLs, and the second is to let producers return
> new public params within SOAP.
>
> Apart from the encoding rules, these options influence scoping of this
> shared state that consumers can implement. If you go with the first
> option, consumers will have to limit this shared state to a user's
> session or just a few portlets on a given page. IMO, this is
restrictive.
>
> However, if you go with the second option, consumer has more choice.
> Consumers can implement wider scoping of this shared state.
>
> Subbu
>
>
> Stefan Hepper wrote:
>> I think this is mixing sematics. Anything that requires a pbia is
ment
>> to be a resource state change. For resource changes you need a
blocking
>> semantic. Navigational state and public params in my mind define the
>> view state of the portlet and changing this state does not require a
>> pbia nor a non-blocking action. The new parameters or state can just
be
>> provided to the portlet.
>>
>> This also relates to the W3C standard about GET and POST:
>>
>> " * Use GET if:
>> o The interaction is more like a question (i.e., it is a
safe
>> operation such as a query, read operation, or lookup).
>> * Use POST if:
>> o The interaction is more like an order, or
>> o The interaction changes the state of the resource in a
way
>> that the user would perceive (e.g., a subscription to a service), or
>> o The user be held accountable for the results of the
>> interaction."
>>
>> I don't see why it is necessary to pay the penalty of an action for
>> changing PPs.
>>
>> Stefan
>>
>>
>>
>> Subbu Allamaraju wrote:
>> > Rich Thompson wrote:
>> >
>> >>
>> >> My comment was that requiring action processing is always
possible,
>> >> but why would we require it in this case and not for
>> >> mode/windowState/navState changes?
>> >
>> >
>> > I agree, but the difference is the encoding rules.
>> >
>> > Subbu
>> >
>> >>
>> >> Rich
>> >>
>> >>
>> >> *Subbu Allamaraju <subbu@bea.com> <mailto:subbu@bea.com>*
>> >>
>> >> 07/22/05 09:48 AM
>> >>
>> >>
>> >> To
>> >> wsrp-interfaces@lists.oasis-open.org
> <mailto:wsrp-interfaces@lists.oasis-open.org>
>> >> cc
>> >>
>> >> Subject
>> >> Re: [wsrp-interfaces] Fw: [wsrp] Additional use cases for
issue
>> >> #44 (set new public params)
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Thinking aloud, can't we map render URL use cases to use pbia?
The
>> >> reason for changing the value of a paramter could be the result
of a
>> >> user interaction, which can then compute new values and return
with
>> pbia
>> >> response.
>> >>
>> >> Subbu
>> >>
>> >>
>> >> Rich Thompson wrote:
>> >> >
>> >> > It is possible to drive every style of update through action
>> >> processing,
>> >> > but I think that short changes the advantages of using render
URLs
>> >> where
>> >> > they are appropriate.
>> >> >
>> >> > New navState can be specified on each URL (including render
>> URLs), why
>> >> > should not the Portlet be able to specify the shared version
(PPs)?
>> >> >
>> >> > Rich
>> >> >
>> >> >
>> >> > *"Andre Kramer" <andre.kramer@eu.citrix.com>
> <mailto:andre.kramer@eu.citrix.com>*
>> >> >
>> >> > 07/22/05 08:02 AM
>> >> >
>> >> > > To
>> >> > Rich Thompson/Watson/IBM@IBMUS,
>> >> <wsrp-interfaces@lists.oasis-open.org>
> <mailto:wsrp-interfaces@lists.oasis-open.org>
>> >> > cc
>> >> > > Subject
>> >> > RE: [wsrp-interfaces] Fw: [wsrp] Additional
use
>> >> cases for issue #44
>> >> > (set new public params)
>> >> >
>> >> >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > After reading your previous email, I was driving towards a
similar
>> >> > recommendation for Portlets to "re-fresh" public parameters
by
>> >> return on
>> >> > each WSRP interaction so that a consumer is more likely to
forward
>> >> > values that have been recently actively returned and I agree
this
>> >> means
>> >> > Portlets have to maintain/store public param values e.g. in
>> >> navigational
>> >> > state. But, with such advice, I see no reason to have public
>> >> parameters
>> >> > to visibly appear on URLs (rewrite expressions or templates)
at
>> >> all. Why
>> >> > introduce a new encoding and (in markup) transport mechanism
> when it
>> >> > seems a preferable Web Service (in SOAP response) encoding
and
>> >> transport
>> >> > is already available and recommended?
>> >> > > Regards,
>> >> > Andre
>> >> > >
>> >> >
>> >>
>>
------------------------------------------------------------------------
>> >> >
>> >> > *From:* Rich Thompson [mailto:richt2@us.ibm.com] *
>> >> > Sent:* 22 July 2005 12:24*
>> >> > To:* wsrp-interfaces@lists.oasis-open.org*
> <mailto:wsrp-interfaces@lists.oasis-open.org*>
>> >> > Subject:* Re: [wsrp-interfaces] Fw: [wsrp] Additional use
cases for
>> >> > issue #44 (set new public params)
>> >> > >
>> >> > The Interfaces SC discussion raised the question about the
scope of
>> >> PPs
>> >> > set in this manner. Namely; does the Portlet need to keep
>> >> specifying the
>> >> > PPs on all subsequent requests or can it depend on the
Consumer to
>> >> > resupply those values in the future (i.e. some scope, like
>> >> user-session,
>> >> > becomes mandated).
>> >> >
>> >> > I think we should be careful to leave scoping questions up to
the
>> >> > Consumer, but if PPs are to function as a coordination model,
>> then we
>> >> > also have to discourage Portlets from setting all PPs on
every
>> URL. A
>> >> > model where Portlets are encouraged to store current PP
values
>> >> > (preferably in navState) for use as default values should the
>> Consumer
>> >> > not supply a value on a subsequent invocation and only do PP
> setting
>> >> > when a value needs to change accomplishes this. It removes
>> setting the
>> >> > value each time such that coordination happens in a more
reasonable
>> >> > manner while also providing for reasonable user experience,
even
>> when
>> >> > the Consumer does not support and PP scope beyond the user
>> >> interaction.
>> >> >
>> >> > Note: We could consider a model where Portlets MUST encode
all
>> PPs on
>> >> > all URLs such that this supplies the scope, rather than the
> Consumer
>> >> > determining the scope, but that this fails as the Portlet
might not
>> >> have
>> >> > access to all PPs (security and privacy reasons).
>> >> >
>> >> > Rich
>> >> >
>> >> > *Rich Thompson/Watson/IBM@IBMUS*
>> >> >
>> >> > 07/07/05 11:54 AM
>> >> >
>> >> > > To
>> >> > wsrp-interfaces@lists.oasis-open.org
>> >> > cc
>> >> > > Subject
>> >> > [wsrp-interfaces] Fw: [wsrp] Additional use
cases
>> >> for issue #44 (set
>> >> > new public params)
>> >> >
>> >> >
>> >> > >
>> >> >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Reposting, as requested ...
>> >> > ----- Forwarded by Rich Thompson/Watson/IBM on 07/07/05 11:52
AM
>> -----
>> >> >
>> >> > *Rich Thompson/Watson/IBM@IBMUS*
>> >> >
>> >> > 06/15/05 09:24 AM
>> >> >
>> >> > > To: WSRP TC
>> >> <wsrp@lists.oasis-open.org> <mailto:wsrp@lists.oasis-open.org>
>> >> > cc: > Subject: Re: [wsrp]
Additional use
>> >> cases for issue #44 (set
>> >> > new public params)
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > I had taken a to-do from the Interfaces SC to develop (in
>> conjunction
>> >> > with Stefan, Richard and Mike) a proposal for this portion of
Issue
>> >> #44.
>> >> > Here is that proposal: *_
>> >> >
>> >> > Philosophy:_* Since Public Parameters (PP) are another aspect
of
>> >> > Consumer managed state that is exposed to Portlets (the other
two
>> are
>> >> > modes and windowState), Portlets should be able to request
>> changes to
>> >> > PPs in much the same way as they do modes and windowStates
(on URLs
>> >> and
>> >> > in responses from pbia and handleEvents). *_
>> >> >
>> >> > On URLs: (2 issues)_*
>> >> > 1. Need to encode 3 pieces of information (request to set a
PP, the
>> >> > PPname and the PPvalue) into 2 places (name=value) when using
a
>> >> > querystring and deal with the reduced set of characters
allowed
>> in the
>> >> > path portion ('=' is not allowed). Templates also introduce
an
> issue
>> >> > with how to encode multiple PPs ... preferably with the
Template
>> only
>> >> > having a single placeholder.
>> >> > -Proposal:
>> >> > 1. All public parameters specified on a URL are concatenated
in the
>> >> form
>> >> > of "PPname1=PPvalue1&PPname2=PPvalue2".
>> >> > 2. The resulting string is URL encoded (changes '=' into %3D
> and '&'
>> >> > into %26) to make it valid in both the querystring and path
>> >> portions of
>> >> > a URL.
>> >> > 3. This URL encoded string becomes the value for the
>> >> > wsrp-publicParameter URL parameter, regardless of whether
template
>> >> > processing or Consumer URL rewriting is in use.
>> >> >
>> >> > 2. How to encode complex PPvalues? I suggest serializing the
>> >> PPvalue to
>> >> > XML and URL encoding this XML. The Consumer would then
receive
>> the PP,
>> >> > recognize it is of a complex type (based on PPname) and
decode the
>> >> > PPvalue to get the XML. *_
>> >> >
>> >> > On Operation responses:_*
>> >> > 1. Return PP requests via a field much as newMode and
> newWindowState
>> >> > request updates to those aspects of Consumer managed state.
Suggest
>> >> this
>> >> > field be of type QNamedStringArray, though it could be an
array of
>> >> > NamedString if we do not want to introduce a usage of a type
from
>> the
>> >> > 'extra' namespace.
>> >> >
>> >> > Rich
>> >> >
>> >> > *Michael Freedman <michael.freedman@oracle.com>
> <mailto:michael.freedman@oracle.com>*
>> >> >
>> >> > 05/24/05 07:55 PM
>> >> >
>> >> > >
>> >> >
>> >> > To
>> >> > WSRP TC <wsrp@lists.oasis-open.org>
> <mailto:wsrp@lists.oasis-open.org>
>> >> > cc
>> >> > > Subject
>> >> > Re: [wsrp] Additional use cases for issue
#44 (set
>> >> new public params)
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > I too am interested in hearing people's current opinions.
Our
> early
>> >> > coordination discussions considered this carefully. It was
>> decided at
>> >> > that time to not support two coordination models that
delivered
>> >> > equivalent function. Though I pushed strongly for such a
parameter
>> >> > style mechanism, the subcomittee preferred Events because it
not
>> only
>> >> > allowed state to be transferred but also actions. The
current
>> public
>> >> > parameter model was introduced by me later and was crafted
>> >> specifically
>> >> > to not step on the the toes of Events. >
>> >> > To extend this conversation I would like to pose:
>> >> > 1. We consider whether publicParameters should be
QNames so
>> >> they
>> >> > can be shared/reused across producers. Note: this is likely
needed
>> >> > whether we stick with events or add the ability to encode a
public
>> >> > parameter directly in the URL.
>> >> > 2. We consider adding a new "defined event" called
>> >> > publicParameterValueChanged. The payload of this event would
> be the
>> >> > QName of the parameter and an Object any holding the parmeter
value
>> >> > [though it might be nice to support our Any/String optional
pair
>> style
>> >> > here].
>> >> > 3. We consider defining the meaning of publicParameter
whose
>> >> > capability contains the value "required" as meaning that
normal
>> >> usage of
>> >> > this portlet requires the consumer to provide this value.
The
>> portlet
>> >> > would still have to deal with situations in which this wasn't
>> provided
>> >> > but likely an end-user would consider this usage
>> crufty/abnormal. For
>> >> > example if a portlet required a CustID parameter and didn't
receive
>> >> one
>> >> > it could display a view that asks for a custID. The key here
by
>> >> saying
>> >> > "required" [we can choose a different capability name] the
consumer
>> >> can
>> >> > distinguish between those public parameters that have a
secondary
>> >> impact
>> >> > on the portlet [optional] and those that have a primary or
> important
>> >> > impact [required].
>> >> > -Mike-
>> >> >
>> >> > Stefan Hepper wrote:
>> >> > Hi,
>> >> > I've some use cases that may be a good match for the ability
to set
>> >> new
>> >> > public parameters by the producer and to encode public
> parameters in
>> >> > URls by the producer.
>> >> >
>> >> > 1. displaying content based on a specific product id:
>> >> > - Portlet A allows to select a product from a list
>> >> > - User clicks on a specific product
>> >> > - Portlet B renders details of this product
>> >> > - Portlet C renders currently available number of items on
> stock for
>> >> > this product
>> >> > - user wants to bookmark this result in order to come back to
>> product
>> >> > tomorrow
>> >> >
>> >> > implementation with events:
>> >> > Portlet A encodes the customer selection URLs as POST action
links
>> >> > Portlet A receives a performBlockingInteraction call
>> >> > Portlet A returns event productID=10
>> >> > Portlet B receive a blocking handleEvents call for
productID=10 and
>> >> > returns new navigational state
>> >> > Portlet C receive a blocking handleEvents call for
productID=10 and
>> >> > returns new navigational state
>> >> >
>> >> > implementation with public params:
>> >> > Portlet A encodes the product selection URLs as GET render
links
>> with
>> >> > the productID as public param
>> >> > Portlet A receives a render call with the public param
productID=10
>> >> > Portlet B receives a render call with the public param
productID=10
>> >> > Portlet C receives a render call with the public param
productID=10
>> >> >
>> >> > which would be much more efficient and also consistent with
the W3C
>> >> > architecture as links that do only change view state should
be
>> encoded
>> >> > as GET links.
>> >> >
>> >> >
>> >> > 2. display content based on a specific customer id
>> >> >
>> >> > 3. display content based on the selected state of a map
>> >> > portlet A displays a map of USA
>> >> > portlet B displays information on the selected state (#
people
>> >> > registered, capital, ...)
>> >> > portlet C displays all IBM labs in that state
>> >> >
>> >> > and many more.
>> >> >
>> >> >
>> >> > This would allow to have some gobal navigational state that
can
>> be set
>> >> > via URLs by portlets. Also portlets may want to set new
public
>> >> params as
>> >> > a result of an blocking interaction or a handle event call.
>> >> >
>> >> >
>> >> > What do you think?
>> >> >
>> >> >
>> >> > Stefan
>> >> >
>> >> >
>> >> >
>>
---------------------------------------------------------------------
>> >> > 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]