RE: [wsrp-coord] Data oriented use case

["Goldstein, Scott" <Scott.Goldstein@vignette.com>]

Mike,

Thanks for the write up.  A couple of comments:

1.  I would propose adding an additional use case which is a variation
of item #1:

#6.  A fourth portlet which has a list of contexts that can be chosen by
the end user by selecting a URL.  For instance, the portlet may list a
set of URLs, each corresponding to a postal code in and around a
particular city.

Why is this use case important?  Essentially, it's feasible that the
URLs listed be render URLs, because they're merely passing the postal
code as a parameter to the page that's shared by the portlets.  This has
the following implications:

	1.  Portlet Developer mindset/convenience - As you pointed out,
it's useful for users to see a single model, page parameters --> portlet
parameters.  I think the same holds true for developers in the reverse
order, portlet parameters --> page parameters.  In this situation, the
developer has the mindset, "I have a postal code that I would like to
place in the URL as a query parameter and have it available to all
portlets on the page.  How do I achieve this?"  In addition, it removes
the need to write additional logic within performBlockingInteraction(),
which would take the postal code from the pbia() request and pass the
exact same data through an event.  If it were possible to map the postal
code parameter to a page parameter, this would not be necessary, making
the developers job much easier.
	2.  Performance - Even if a Consumer is written to take
advantage of the optimization of a portlet returning markup during a
pbia() call, there's still the fact that this operation is blocking.  If
it were a render URL, the portlet containing the URL could be invoked in
parallel with the other portlets on the page.
	3.  Consistent URLs - If this mechanism were possible, the
Consumer could be written such that these URLs are of the same format as
those created in use cases 2 and 5.  This leads to improved efficiency
for systems such as Page Level Caching and Metrics/Reporting.


2.  Comment on your final note - I disagree with this based on the use
case I mentioned above.  I would like to see a mechanism in which the
"public" render parameters that you propose can be set just as portlets
set navigational state.  This would have the effect of setting the
associated page parameter, which is passed to all of the portlets on the
page.  In essence, this gives the ability to a portlet to change the
context of the page through a render URL or action response without the
inconvenience and overhead of an event.

Scott       

-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com] 
Sent: Tuesday, June 15, 2004 5:56 PM
To: wsrp-coord@lists.oasis-open.org
Subject: [wsrp-coord] Data oriented use case

Well I finally have an early draft pulling together some of my thoughts.

 Its attached.  If possible please review before tomorrow's concall as 
we may spend some time discussing it.
       -Mike-