On 8/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On the wiki[1], we've got mandatory requirement #9 talking about support for
"Support for multiple active dialog instances within a single page" (i.e.
more than one instance within a particular JSF view. Thinking about this
further, I'm not sure we really need that ... and Seam doesn't support it
either. Seam passes around a single conversationId for the entire request,
although this identifier gives you access to a stack of nested active
conversations somewhat like what we currently do with subdialogs.
<snip/>
So, I've had a cursory glance at SWF. It does something similar,
passing around (to the client) a "flow execution key" which identifies
a particular conversation instance in the subsequent request. Given
this modus operandi, It does seem unlikely that a particular view
could be involved with multiple active dialogs (at the same time).
One implication of this is if we wanted to build a special variable resolver
that resolved, say, "context" to the Context object for the current dialog.
If there is guaranteed to be at most one active dialog instance on a single
view, then this is pretty straightforward ... just go grab the value for the
dialog identifier (from however you passed it back and forth), and map it to
the corresponding Context instance that was cached in session scope. If
there is the possibility of more than one dialog in the current view, then
the VariableResolver doesn't have enough "context" (err, sorry :-) to figure
out which one to select when it evaluates an expression like '#{context}".
We clearly need to be able to support individual dialogs active in different
windows or frames (mandatory requirement 10), but those are each individual
views so it shouldn't cause grief. But, do we really need multiple dialogs
active *within* a single window or frame?
<snap/>
The Reusable Dialog Components (RDC) framework [1],[2] did this for
speech applications (each speech widget / component is a JSP tag which
has an internal state machine that drives the markup generated over
multiple round trips -- and in a "mixed initiative" dialog, multiple
RDCs may be active within a single view) at the same time. The markup
from each component gensyms form field names such that the component
ID is part of these names, and the components (each of which can be
thought of as dialogs) then know how to not trip over each other.
Having said that, I don't have good usecases where it makes sense to
have multiple active dialogs in Shale (non-speech apps, unless we drop
down to similar components as "DialogHolder"s granularity). The RDC
analogy though, would roughly translate to having the param
conversationId be replaced by something gensym'ed with some dialog
instance identifier and a well-known prefix or suffix.
-Rahul
[1] http://jakarta.apache.org/taglibs/doc/rdc-doc/intro.html
[2] http://wiki.apache.org/jakarta-taglibs/ReusableDialogComponents/Tutorials
Craig
[1] http://wiki.apache.org/shale/DialogManagerFeature
