Hi Scott,
Indeed it is a
3 step process, I ignored the third one because it can be “optimized” into
the second one (see open question 7). Let’s assume for the sake of this discussion
we will do this optimization, since we are talking about optimizing the protocol.
However, I don’t
think what you are suggesting can work as is, because during getMarkup, a
portlet MUST NOT change its state, which makes handling an event that changes
its data impossible (in other words the next getMarkup must return the same
markup as the previous one).
So the next step
is to say that only a handleEvents to each portlet is needed (since it can
return markup).
What we gained
here is we do not need the initial pbia, at the price that consumer must
know when the value (of “sales region” in your example”) was changed by the
user, rather than leaving this responsibility to the portlet in which this
happened. I still don’t understand how you propose to do this, which is I
meant by the “all portlets are equal” remark.
If your suggestion
is that the portlet expose which name in its formParameters represents a
shared state parameter, I think this is a valid suggestion, but it goes a
little too far on making assumptions on the way the portlets and consumers
are implemented for achieving an optimization (for example, the portlet will
not get a chance to validate the value that was entered). But this is just
my opinion…
In any case, we
have agreed before that there is a possibility of building a shared state
mechanism on top of the events mechanism (regardless of whether it starts
with a pbia), but we also agreed to defer the discussion.
Yossi.
Currently, I think
it’s a three step process:
1.
pbia() call to
create the event
2.
handleEvents()
call to distribute the event
3.
getMarkup() calls
to render the portlets
The data use case
suggests that this can possibly be reduced to a one step through a new form
of non-opaque state shared amongst all portlets on the page. This state
is carried within a request parameter within the “sales region” URL’s. The
parameter is then set within a field on the MarkupParams. This form of sharing
would reduce the process to only the getMarkup() call.
I’m not quite
sure I understand what you mean when you say, “The assumption here is that
all the portlets in the page are equal, so you can not assume the “change
sales region” is somehow especially “near” the consumer.” Could you clarify?
Scott
Hi Scott,
Regarding 1, I
think we all agree this is a common use case, perhaps the most common one.
However, I don’t see how it can be solved generally in a more performant manner,
in a WSRP environment. Specifically, I don’t see the how using the “initial
state” direction can solve this.
The assumption
here is that all the portlets in the page are equal, so you can not assume
the “change sales region” is somehow especially “near” the consumer.
Can you explain
how you would optimize this? (Currently it is a two step process, where the
second step involves multiple WS requests in parallel, so an optimization
would probably require making it a single step process.)
Yossi.
I have a
few questions regarding the current eventing semantics document. These are
all items which have been discussed before I joined the TC, so I apologize
if I'm simply missing information which has already been presented.
1. The
data use case written up by Mike has been translated into goal 4 of the document.
The goal states that the data use case only applies to the initial state
of the portlet. It's not clear to me, though, why this limitation has been
set. Consider the following example:
There are
several portlets on a page which comprise a composite application to share
company sales information. One portlet contains a set of links for all of
the sales regions in the company. When a user selects a sales region in
this portlet, the rest of the portlets on the page display some specific
information about the selected sales region.
Though I
agree that this example can be implemented using the current eventing framework,
I don't feel that it can be done in an ideal fashion. It would require a
pbia() call when selecting a sales region and additional calls for each portlet
to distribute the resulting event. This is a lot of overhead, considering
all that’s needed is to pass a sales region id to all of the portlets on
the page. This seems like a common portlet coordination use case which should,
ideally, be handled in an efficient manner. Do others agree? Does it, therefore,
make sense to expand goal 4 beyond just the initial state of the portlet?
Or, am I incorrectly interpreting the term, "initial state"?
2. Besides
the use case presented by Mike, are there any other documented use cases
which are being used as input to the document? The other URL listed seems
to describe a general business scenario rather than concrete portlet coordination
use cases.
3. What
are the use cases for returning a new Portlet Mode and Window State from handleEvents()? I’m guessing
that this may still be under discussion, since the document still has question
marks for these two return fields.
4. What
happens when two portlets return the Maximized window state? Does section
3.2.3 come into play here? Is it up to the portal to decide? This issue
seems similar to the redirectURL problem discussed last week.
Thanks for
the information.
Scott