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: some eventing thoughts


We had some discussions here about eventing and I wanted to share with you
some thoughts.
We asked ourselves whether it would be valueable to take "render events"
into account.
Let me try to define what I mean by render event:
- a render event is a event that takes as payload similar to other events
but only manipulates navigational state, i.e.
currentNavState+eventPayload->newNavstate
currentNavState would be transferred similar to handle event, as a response
a new navState would come back (or markup+new navState).
- render events are not allowed to modify any further state, only navState

Why this would make sense:
- it seems that a lot of use cases indeed trigger navState changes only in
portlets participating in portlet intercommunication
One typical example: Portlet provides list of articles in stock, click on
article -> articleSelected(id) event is fired, another portlet displaying
the article details modifies its navState based on the id selected
- renderEvents could be safely distributed to all participating portlets
similar to getMarkup. I think we have some discussions around how isolated
calls of handleEvents are, or whether there must be some kind of blocking.
- renderEvents do not trigger potential cache invalidations like our
"normal" events in principle do. Since the Consumer can safely compute the
cache key based on the navState+event payload (even if the new NavState
would not be returned) , it can keep pages in its cache and reserve them if
the input event again changes the navState, e.g. in the above example the
user first displays article #1, then article#2, then back to #1. The page
rendered by the 2nd article #1 invocation could be completly served from
the Consumer's cache.

Of course this also raises some questions:
- if an event is a renderEvent or an "actionEvent" (our current event
definition) must be decided by the event sink, i.e. the portlet receiving
the event.
This means that portlet meta data would need to declare whether an event is
considered as render or action event
- does the consumer need to seperate the distribution of these events? can
we make it one handle events call but with both types in them?

Comments appreciated.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]