[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-coord] A few questions regarding the current semantics doc
Yossi, I wasn’t aware of the proposed
optimization to return markup from handleEvents(). Thanks for pointing
this out. This would reduce the page display to two steps if
handleEvents() was non-blocking. In other words, if you could call
handleEvents() on those portlets recieveing events and getMarkup() on those
portlets not receiving events in parallel. If handleEvents() was blocking,
it’s still a 3 step process, but the overhead would be reduced. Yes, I agree that the data sharing
mechanism doesn’t cover all coordination use cases, given that a portlet
cannot change its state in getMarkup(). I also agree that if this data is
entered through a form, it would have to be processed through a pbia() call for
validation purposes. In the particular example I presented, this was not
the case however. The data here is provided through a render URL. The main concern here is that, as this
case is common, it should ideally be supported in an efficient manner. Since
goal 4 stated that this use case only applied to the portlet intial state, I
wanted to raise an issue, since the example I presented clearly shows that it extends
beyond the portlet’s initial state. As Rich has mentioned, however,
Mike is reviewing the use case for beyond just the initial state in relation to
the current eventing semantics. I can contact Mike individually to see if
he’d like help/input for this review. Scott From: 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. From:
Goldstein, Scott [mailto:Scott.Goldstein@vignette.com] 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
From: 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. From:
Goldstein, Scott [mailto:Scott.Goldstein@vignette.com] 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 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]