On 12/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
Yes, I think is a bad choice use directly the State object of the dialog
machinery.
But what I really need is to know the possible transaction names of the
current dialog in the current state....in the old version of shale I
used, the only way to know it was use directly the State object.
Don't you think could be useful have an utility class that return some
information like:
- current dialog name
- current view name
- possibles transactions
This information is all an internal implementation detail of the particular
dialog implementation you are using. There is no guarantee that this
information even exists .
Without this utilities, is there another way to resolve my problem?
I don't understand (because my English is very bad :) ) what you mean
for "data" item....
In the new design, DialogContext is the API you use to deal with a
particular active dialog. For example, you can programmatically stop the
dialog if you want, by calling:
FacesContext context = FacesContext.getCurrentInstance();
DialogContext dc = (DialogContext)
context.getExternalContext().getRequestMap().get(Constants.DIALOG_BEAN
);
dc.stop();
In addition to methods like stop(), DialogContext includes the following
API:
public Object getData();
public void setData();
so that you can use the "data" property to store application related
information. You can either use one of your own beans (see how the Use
Cases example application does this for the logon dialog), or the Dialog
implementation will provide you a map.
From a binding expression, you can get to this information easily. Assume
you have an "authorized" boolean property indicating that the user has been
authorized. Reference it like this:
#{dialog.data.authorized}
Storing application specific state in the "data" property means you do not
need any access to the internals of the dialog manager.
Craig
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: 3 dicembre 2006 00.26
To: [email protected]
Subject: Re: How know current State?
On 12/2/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
wrote:
>
> I have implemented an extension of t:panelNavigation
> (x:shalePanelNavigation) that set active all items of the panel that
> have an action callable based of the current state of the current
> dialog. At the moment I do:
> - take the current state (I use an old version)
> - obtain shaleState.getTransitionOutcomes() (in Iterator trans)
> - for each item of the panel navigation I check if his action ha a
value
> present in the iterator trans
> - if true I set active the item...otherwise disactive
>
> Obviously I have some application standards to respects for a correct
> use of this panel navigation, but at the moment is perfect for us.
>
> I hope is a good reason Craig.... :)
Well, it is certainly an *understandable* reason :-). However, I fear
that
enabling access to the information you propose will affect your
application
design in negative ways. The information needed to determine what
navigation choices should be available can be stored in an application
data
structure that is independent of the dialog machinery, and kept in the
"data" item, without needing any reference to the internals.
Among other things, that would let you migrate later to a more
sophisticated
dialog management system like the Commons SCXML version (or even
something
completely different like Spring WebFlow) without having to rearchitect
everything once the State object no longer exists :-).
Thanks in advance
> Mario
Craig
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the email by you is prohibited.
