shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [dialog] Missing requirements?
Date Tue, 29 Aug 2006 02:04:11 GMT
On 8/28/06, Paul Spencer <> wrote:
> Craig McClanahan wrote:
> > On 8/28/06, Paul Spencer <> wrote:
> >
> >>
> >> Should the following be added as a requirements:
> >>
> >> o A managed bean can be populated by one or more action and views
> solely
> >> via
> >>    configuration.  The use of the dialog API by the user's application
> is
> >> not needed.
> >>    Said another way, an existing JSF Bean and view, view.jsp, can be
> >> broken up into
> >>    a dialog by configuring the dialog and breaking apart view.jsp into
> >> many
> >>    jsp files.
> >>    (Currently this is possible when using session managed beans.)
> >
> >
> >
> > I'm not quite sure how to articulate this as a requirement.  Woutd it be
> > sufficient to say "You should be able to utilize the dialog
> functionality
> > WITHOUT being required to use the provided state storage mechanism (i.e.
> #{
> >}), as long as the application manages this state itself"
> or
> > something like that?.  If so, I think that might be a reasonable
> > requirement
> > to add -- although in practice I'm having a hard time figuring out how a
> > dialog framework could make this NOT work.
> >
> Like you, I am not real sure about the wording.  Although I do not agree
> with
> the phrase "as long as the application manages this state itself."  My
> intent
> is for the states and transitions to be configurable and managed by the
> Shale
> Dialog manager.  We may be "splitting hairs" on the wording, If so I will
> leave
> the wording to your discretion.

One thing to consider, as you contemplate building apps this way.  The new
dialog functionality lets an individual user participate in more than one
dialog (in separate windows or frames) at the same time.  Consider what
happens if the user opens a new window (but still part of the same session)
and starts a new instance of the *same* dialog.  If you do use the data
management support provided by the (new) dialog functionality, that's no
problem ... the framework makes sure that it gets the right data for the
right window.  But if you're trying to manage this yourself in the
application, that becomes *your* problem.

It's not so big a deal if the user is using different dialogs in different
windows/frames ... but as we all know, users do the darndest things
sometimes ...

> Paul Spencer


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message