How know current State?

[ma...@accenture.com]

Hi,

I need to know the current State of the Current Dialog. Is there a way
to know it?

 

Thanks in advance

Mario



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.

Re: How know current State?

[Rahul Akolkar <ra...@gmail.com>]

On 12/1/06, mario.buonopane@accenture.com <ma...@accenture.com> wrote:
> Hi,
>
> I need to know the current State of the Current Dialog. Is there a way
> to know it?
>
<snip/>

There isn't a public API for that. Can you please articulate your
usecase for needing it? (that may get some ideas going)

-Rahul


>
>
> Thanks in advance
>
> Mario
>
>

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/12/06, mario.buonopane@accenture.com <ma...@accenture.com>
wrote:
>
> Ok, I understand your point of view.
> I have two more questions Craig:
> - Is there a way to know the current dialog name?


The request scoped attribute named "dialog" is of type DialogContext, from
which you can call getName() to get the dialog name.

- In my version of shale, when I call an outcome not present in the
> dialog, I receive an Exception (generic). Is there the possibility to
> receive a specific Exception? (in this way I have the possibility to
> send a manage the error).


Are you using the "Basic" implementation with a recent nightly build?  If
so, you should actually be getting an IllegalStateException in this case,
with a message like:

    Cannot find transition 'foo' for state 'bar' of dialog 'baz'

Having some framework-specific exceptions for cases like this seems like it
would be a good idea.

Also, if you use my suggestion of making your data object a
DialogContextListener, you'll be notified (via a call to onException()) when
such an exception occurs.

Thanks in advance
> Mario


Craig

RE: How know current State?

[ma...@accenture.com]

Ok, I understand your point of view.
I have two more questions Craig:
- Is there a way to know the current dialog name?

- In my version of shale, when I call an outcome not present in the
dialog, I receive an Exception (generic). Is there the possibility to
receive a specific Exception? (in this way I have the possibility to
send a manage the error). 

Thanks in advance
Mario

-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of Craig
McClanahan
Sent: 12 dicembre 2006 19.54
To: user@shale.apache.org
Subject: Re: How know current State?

On 12/12/06, mario.buonopane@accenture.com
<ma...@accenture.com>
wrote:
>
> Thanks Craig....
> Is there a way to know the list of transictions name I have
configured,
> in the dialog, at the current state? (I need this information because
if
> an outcome is not possible in the current state I want disable the
item
> of the panelNavigation...otherwise the user receive an Exception If he
> click on the item)


No, you only know the names of the states.  As we have discussed before,
I
think it's a really bad idea to code your application in terms of the
internal details of the dialog engine (i.e. the names of the transitions
themselves).  You should instead be creating boolean functions that
allow
you to enable or disable things in terms of the application's
structures,
not the dialog manager's structures.

As a concrete example, assume you have a "details" button that should be
enabled only for a user who is a manager.  The button itself could be
coded
something like this:

    <h:commandButton id="details" ...
disabled="#{dialog.data.notManager}"/>

and in your data bean class you'd have a method:

    public boolean isNotManager() { ... }

Note that you need not have any knowledge at all that dialogs are being
used
to manage the conversation ... it's all about thinking in terms of the
concepts of your application.

For your use case about enabling a link only if a certain page has been
reached, I previously responded with an example of how to do that based
solely on the fact that you have reached a certain state.  It's the same
general idea.


Regards
> 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.

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/12/06, mario.buonopane@accenture.com <ma...@accenture.com>
wrote:
>
> Thanks Craig....
> Is there a way to know the list of transictions name I have configured,
> in the dialog, at the current state? (I need this information because if
> an outcome is not possible in the current state I want disable the item
> of the panelNavigation...otherwise the user receive an Exception If he
> click on the item)


No, you only know the names of the states.  As we have discussed before, I
think it's a really bad idea to code your application in terms of the
internal details of the dialog engine (i.e. the names of the transitions
themselves).  You should instead be creating boolean functions that allow
you to enable or disable things in terms of the application's structures,
not the dialog manager's structures.

As a concrete example, assume you have a "details" button that should be
enabled only for a user who is a manager.  The button itself could be coded
something like this:

    <h:commandButton id="details" ... disabled="#{dialog.data.notManager}"/>

and in your data bean class you'd have a method:

    public boolean isNotManager() { ... }

Note that you need not have any knowledge at all that dialogs are being used
to manage the conversation ... it's all about thinking in terms of the
concepts of your application.

For your use case about enabling a link only if a certain page has been
reached, I previously responded with an example of how to do that based
solely on the fact that you have reached a certain state.  It's the same
general idea.


Regards
> Mario


Craig

RE: How know current State?

[ma...@accenture.com]

Thanks Craig....
Is there a way to know the list of transictions name I have configured,
in the dialog, at the current state? (I need this information because if
an outcome is not possible in the current state I want disable the item
of the panelNavigation...otherwise the user receive an Exception If he
click on the item)

Ciao
Mario



-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of Craig
McClanahan
Sent: 10 dicembre 2006 04.06
To: user@shale.apache.org
Subject: Re: How know current State?

On 12/4/06, mario.buonopane@accenture.com
<ma...@accenture.com>
wrote:
>
> Yes Craig, subclassing BasicDialogContext could be sufficient for me.


OK, I have implemented a strategy that should satisfy both of us :-).
You'll need a fairly recent nightly build to get the relevant changes.
Basically, what you'll want to do is this:

* Use a JavaBean class to store state information for the current
  instance.  You can either register this yourself by calling setData()
  on the DialogContext instance yourself, or configure the dialog
  system to automatically instantiate an instance of your class whenever
  a new DialogContext instance is created.

* Make this class implement the
org.apache.shale.dialog.DialogContextListener
  interface.  The simplest way to proceed, if you don't have to use a
different
  base class, is to extend AbstractDialogContextListener -- that way you
only have
  to implement the event handling methods you are interested in.

* The framework will call the onEntry() method or your class whenever a
new
  state is entered.  The state name will be passed in as a string so
that
you can
  use it to change (for example) what navigation choices should be
enabled.

There are other, more advanced, techniques to using the event listener
support, but this is the easiest way to accomplish what you've described
for
your use case -- and it now does not require you to become dependent
upon
any of the internals of the dialog implementation.

Thanks a lot
> Mario


Craig


-----Original Message-----
> From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > <ma...@accenture.com>
> > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > <ma...@accenture.com>
> > > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > > <ma...@accenture.com>
> > > > > 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.
>


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.

RE: How know current State?

[ma...@accenture.com]

Thanks Craig....
Is there a way to know the list of transictions name I have configured,
in the dialog, at the current state? (I need this information because if
an outcome is not possible in the current state I want disable the item
of the panelNavigation...otherwise the user receive an Exception If he
click on the item)

Regards
Mario

-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of Craig
McClanahan
Sent: 10 dicembre 2006 04.06
To: user@shale.apache.org
Subject: Re: How know current State?

On 12/4/06, mario.buonopane@accenture.com
<ma...@accenture.com>
wrote:
>
> Yes Craig, subclassing BasicDialogContext could be sufficient for me.


OK, I have implemented a strategy that should satisfy both of us :-).
You'll need a fairly recent nightly build to get the relevant changes.
Basically, what you'll want to do is this:

* Use a JavaBean class to store state information for the current
  instance.  You can either register this yourself by calling setData()
  on the DialogContext instance yourself, or configure the dialog
  system to automatically instantiate an instance of your class whenever
  a new DialogContext instance is created.

* Make this class implement the
org.apache.shale.dialog.DialogContextListener
  interface.  The simplest way to proceed, if you don't have to use a
different
  base class, is to extend AbstractDialogContextListener -- that way you
only have
  to implement the event handling methods you are interested in.

* The framework will call the onEntry() method or your class whenever a
new
  state is entered.  The state name will be passed in as a string so
that
you can
  use it to change (for example) what navigation choices should be
enabled.

There are other, more advanced, techniques to using the event listener
support, but this is the easiest way to accomplish what you've described
for
your use case -- and it now does not require you to become dependent
upon
any of the internals of the dialog implementation.

Thanks a lot
> Mario


Craig


-----Original Message-----
> From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > <ma...@accenture.com>
> > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > <ma...@accenture.com>
> > > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > > <ma...@accenture.com>
> > > > > 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.
>


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.

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/4/06, mario.buonopane@accenture.com <ma...@accenture.com>
wrote:
>
> Yes Craig, subclassing BasicDialogContext could be sufficient for me.


OK, I have implemented a strategy that should satisfy both of us :-).
You'll need a fairly recent nightly build to get the relevant changes.
Basically, what you'll want to do is this:

* Use a JavaBean class to store state information for the current
  instance.  You can either register this yourself by calling setData()
  on the DialogContext instance yourself, or configure the dialog
  system to automatically instantiate an instance of your class whenever
  a new DialogContext instance is created.

* Make this class implement the
org.apache.shale.dialog.DialogContextListener
  interface.  The simplest way to proceed, if you don't have to use a
different
  base class, is to extend AbstractDialogContextListener -- that way you
only have
  to implement the event handling methods you are interested in.

* The framework will call the onEntry() method or your class whenever a new
  state is entered.  The state name will be passed in as a string so that
you can
  use it to change (for example) what navigation choices should be enabled.

There are other, more advanced, techniques to using the event listener
support, but this is the easiest way to accomplish what you've described for
your use case -- and it now does not require you to become dependent upon
any of the internals of the dialog implementation.

Thanks a lot
> Mario


Craig


-----Original Message-----
> From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > <ma...@accenture.com>
> > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > <ma...@accenture.com>
> > > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > > <ma...@accenture.com>
> > > > > 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.
>

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/4/06, mario.buonopane@accenture.com <ma...@accenture.com>
wrote:
>
> Yes Craig, subclassing BasicDialogContext could be sufficient for me.


In looking at how much private API would need to be made protected or public
for this (a *lot*, unfortunately), I've reminded myself that there is an
alternative strategy possible with the current implementation -- there are
JavaBean style events that you can register listeners for, including when a
DialogContext transitions to a new state.  You get back the state *name*
instead of any internal implementation details, so you are still linked to
metadata in your dialog configuration, but that is still substantially less
dependence on internal implementation details like the State classes
themselves.

There are still a couple of places we need to add event capabilities (so you
can know, for example, when a new DialogContext instance was created via
navigation) that I'm going to look at in the next couple of days.

Craig

Thanks a lot
> Mario
>
> -----Original Message-----
> From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > <ma...@accenture.com>
> > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > <ma...@accenture.com>
> > > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > > <ma...@accenture.com>
> > > > > 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.
>

RE: How know current State?

[ma...@accenture.com]

Yes Craig, subclassing BasicDialogContext could be sufficient for me.

Thanks a lot
Mario 

-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
<ma...@accenture.com>
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > <ma...@accenture.com>
> > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > <ma...@accenture.com>
> > > > 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.

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/4/06, mario.buonopane@accenture.com <ma...@accenture.com>
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > <ma...@accenture.com>
> > > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > > <ma...@accenture.com>
> > > > 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.
>

RE: How know current State?

[ma...@accenture.com]

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? 
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.......


-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
<ma...@accenture.com>
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > <ma...@accenture.com>
> > > 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.

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/4/06, mario.buonopane@accenture.com <ma...@accenture.com>
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > > <ma...@accenture.com>
> > > 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.
>

RE: How know current State?

[ma...@accenture.com]

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. 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. 


-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
<ma...@accenture.com>
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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.

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/3/06, mario.buonopane@accenture.com <ma...@accenture.com>
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> > <ma...@accenture.com>
> > 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.
>

RE: How know current State?

[ma...@accenture.com]

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. 


-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
<ma...@accenture.com>
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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.

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/3/06, mario.buonopane@accenture.com <ma...@accenture.com>
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
> <ma...@accenture.com>
> 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.
>

RE: How know current State?

[ma...@accenture.com]

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 

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....



-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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, mario.buonopane@accenture.com
<ma...@accenture.com>
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.

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/2/06, mario.buonopane@accenture.com <ma...@accenture.com>
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

RE: How know current State?

[ma...@accenture.com]

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.... :)

Thanks in advance
Mario
 

-----Original Message-----
From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On Behalf Of Craig
McClanahan
Sent: 1 dicembre 2006 20.18
To: user@shale.apache.org
Subject: Re: How know current State?

On 12/1/06, mario.buonopane@accenture.com
<ma...@accenture.com>
wrote:
>
> Hi,
>
> I need to know the current State of the Current Dialog. Is there a way
> to know it?


There is no public API (on DialogContext) that gives you this
information
currently ... indeed, there is no guarantee that the underlying dialog
system actually has any concept of "state" the way that the old
implementation did.  I would also consider needing to know the state as
a
potential red flag on your application design -- the focus should be on
building pages that don't need to know such things.  If you need
information
that is application specific, consider using the "data" object instead.

Can you describe a use case for why the application would need to know
the
current state?  Is this information something that can be inferred from
stuff inside your "data" object instead?

In the mean time, it would be possible to create your own version of
BasicDialogContext with a public getState() method that would look at
the
top Position on the "positions" stack, and pull the State out of there,
and
configure the system to use that instead.  You'll need to do
cut-and-paste
reuse, because this class was not designed to be subclassed.  The design
idea, as mentioned above, was to hide all the details about internal
implementation.  Note also that if you expose a State object to your
application, you'll be depending on APIs that are internal to Shale and
are
*not* guaranteed to remain compatible across releases, so we'd better
have a
really good reason to do it :-).

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.

Re: How know current State?

[Craig McClanahan <cr...@apache.org>]

On 12/1/06, mario.buonopane@accenture.com <ma...@accenture.com>
wrote:
>
> Hi,
>
> I need to know the current State of the Current Dialog. Is there a way
> to know it?


There is no public API (on DialogContext) that gives you this information
currently ... indeed, there is no guarantee that the underlying dialog
system actually has any concept of "state" the way that the old
implementation did.  I would also consider needing to know the state as a
potential red flag on your application design -- the focus should be on
building pages that don't need to know such things.  If you need information
that is application specific, consider using the "data" object instead.

Can you describe a use case for why the application would need to know the
current state?  Is this information something that can be inferred from
stuff inside your "data" object instead?

In the mean time, it would be possible to create your own version of
BasicDialogContext with a public getState() method that would look at the
top Position on the "positions" stack, and pull the State out of there, and
configure the system to use that instead.  You'll need to do cut-and-paste
reuse, because this class was not designed to be subclassed.  The design
idea, as mentioned above, was to hide all the details about internal
implementation.  Note also that if you expose a State object to your
application, you'll be depending on APIs that are internal to Shale and are
*not* guaranteed to remain compatible across releases, so we'd better have a
really good reason to do it :-).

Thanks in advance
>
> Mario


Craig