shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Spencer <pau...@apache.org>
Subject Re: [dialog] Missing requirements?
Date Tue, 29 Aug 2006 02:19:08 GMT
Craig,
Yes, the use of session manage beans with more then one dialog will produce
unpredictable results. The documentation should include a warning regarding
the use of session and application managed beans with dialogs.  In general
only request managed beans should be used with dialogs.

You are correct "users do the darndest things"

Paul Spencer

Craig McClanahan wrote:
> On 8/28/06, Paul Spencer <paulsp@apache.org> wrote:
> 
>>
>> Craig McClanahan wrote:
>> > On 8/28/06, Paul Spencer <paulsp@apache.org> 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.
>> #{
>> > dialog.data.foo}), 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 ...
> 
> <snip>
> 
>>
>> Paul Spencer
>>
> 
> 
> Craig
> 
> 
> ------------------------------------------------------------------------
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.11.6/428 - Release Date: 8/25/2006


Mime
View raw message