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 <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
> On 8/28/06, Paul Spencer <[EMAIL PROTECTED]> 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
