Yes Craig, subclassing BasicDialogContext could be sufficient for me. Thanks a lot Mario
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: 4 dicembre 2006 18.04 To: user@shale.apache.org Subject: Re: How know current State? On 12/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Craig, why the programmer or common base class have to implement some > stuff to decide if the user can go from Page1 to Page2 if I have already > setted in dialog manager config? Because it is *not* necessarily settled in the dialog manager config, for the entire lifetime of your application. What happens when you refine your dialog configuration later, to adapt to changing requirements? You just broke everything, because the connections are too fragile. That is bad architectural design, in my opinion. Using the component I wrote, the programmer does not know what > happen....is the component that decide basing on the dialog manager...is > just one single point of dependency injection to dialog manager. > > Please, give us the possibility to know this information....... At this point, the farthest I would feel comfortable going is making it a little easier to subclass BasicDialogContext to add this kind of access in your own custom subclass. I am not planning on adding this access directly, because I do not want to encourage developers to do what you are wanting to do. Craig -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig > McClanahan > Sent: 4 dicembre 2006 17.02 > To: user@shale.apache.org > Subject: Re: How know current State? > > On 12/4/06, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> > wrote: > > > > Yes, but in this way the programmer must disable/enable the commands > > basing on the dialog. If in dialog x you have decide that you cannot > go > > directly to page2 from page1, in this way you must replicate the logic > > also in code. > > > Or use a common base class for all your wizards that implements the > common > usage patterns. > > Having some utility like: Boolean > > isTransactionPossible(String transictionName) the programmer can know > if > > is possible go from Page2 to Page1 using a specific "outcome". We work > > like you explain but with the add-on of the my:shalePanelNavigation > that > > in rendering phase decide if a specific item has an action (outcome) > > callable in the current dialog. > > > My point is that the application programmer should concentrate on > application level things. In other words, making a decision "can the > user > go to Page2" based on whatever policies your application design dicates. > This decision should be encapsulated into a method that can be used to > make > navigation decisions, instead of making the application developer have > to be > aware of the intricate mechanics of *how* that decision is implemented > (understanding states and transitions). > > Craig > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Craig > > McClanahan > > Sent: 4 dicembre 2006 00.30 > > To: user@shale.apache.org > > Subject: Re: How know current State? > > > > On 12/3/06, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> > > wrote: > > > > > > Craig, > > > I use the panelNavigation in a wizard....suppose the panelNavigation > > has > > > 3 items: > > > Page1 (call outcome "gotopage1") > > > Page2 (call outcome "gotopage2") > > > Page3 (call outcome "gotopage3") > > > > > > In our wizard, generally, we don't want the user go directly to > Page2 > > > clicking on item "Page2" when he stay on Page1 but pressing the > > > "confirm" button. But generally, when the user is on Page N we > permit > > to > > > go directly in Page N-1 clicking on item of panelNavigation (for > > example > > > if the user is on Page2 can go in Page1 clicking on Page1 item). We > > like > > > put all this logic in the dialog manager and not in the application > > > (programmatically). Is the analyst that, creating the dialog, decide > > if > > > the user can or not click on a item in a particular state. Having > the > > > transiction names and view name configured in the dialog manager can > > > help this implementation, otherwise I'll have to manage this problem > > > with application logic. > > > > > > One approach would be to having a custom JavaBean class for the data > > that > > includes: > > > > public class MyData { > > > > private booelan page1Disabled = true; > > public boolean isPage1Disabled() { return page1Disabled; } > > > > private boolean page2Disabled = true; > > public boolean isPage2Disabled() { return page2Disabled; } > > > > private boolean page3Disabled = true; > > public boolean isPage3Disabled() { return page3Disabled; } > > > > public String gotoPage1() { page1Disabled = false; return > "Go"; > > } > > public String gotoPage2() { page2Disabled = false; return > "Go"; > > } > > public String gotoPage3() { page3Disabled = false; return > "Go"; > > } > > > > } > > > > Now, the trick is to make sure that the actual navigation choices call > > the > > appropriate gotoPageX methods, instead of navigating to the page > > directly. > > You can do that by having the three <t:commandNavigation> controls > > return a > > logical outcome of "Page1", "Page2", and "Page3", but defining > > transitions > > in your dialog like this: > > > > <dialog name="MyWizard" start="Page1"> > > > > <action name="Page1" method="#{dialog.status.gotoPage1}"> > > <transition outcome="go" state="viewPage1"/> > > </action> > > > > <action name="Page2" method="#{dialog.status.gotoPage2}"> > > <transition outcome="go" state="viewPage2"/> > > </action> > > > > <action name="Page3" method="#{dialog.status.gotoPage3}"> > > <transition outcome="go" state="viewPage3"/> > > </action> > > > > <view name="viewPage1" viewId="/Page1.jsp"> > > <transition name="Page2" state="Page2"/> > > </view> > > > > <view name="viewPage2" viewId="/Page2.jsp"> > > <transition name="Page3" state="Page3"/> > > </view> > > > > <view name="viewPage3" viewId="/Page3.jsp"> > > <transition name="Finish" state="Finish"/> > > </view> > > > > <action name="Finish" method="#{dialog.data.finish}"/> > > > > </dialog> > > > > The basic idea is that you have an action state in between each view > > state > > that updates the boolean flags saying what pages can be accessed. > Note > > that > > the person coding up the pages doesn't have to know anything about > this > > -- > > they write navigation outcomes just like they are used to, and the > > dialog > > manager manages the navigation. > > > > For the person writing your application code (the MyData bean), you > > could > > encapsulate the above kind of navigation management in a base class > that > > provides the methods defined above, and only do new action methods for > > stuff > > that is specific to a particular wizard. > > > > As a final touch, you might want to disable the links to pages that > the > > user > > is not allowed to navigate to yet. Do that by setting the disabled > > property > > on the command navigation links dynamically: > > > > <t:commandNavigation ... disabled="#{dialog.data.page2Disabled}"/> > > > > It's all about thinking about the conversation with the user in terms > of > > a > > state machine > > > > Craig > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > > Craig > > > McClanahan > > > Sent: 3 dicembre 2006 19.16 > > > To: user@shale.apache.org > > > Subject: Re: How know current State? > > > > > > 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: user@shale.apache.org > > > > 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. > > > > > > > > > > > > > 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. > > > > > > > > > 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. > > > > > 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. > 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.
