You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by gr...@intellicare.com on 2006/01/06 22:05:56 UTC
[Shale] getting my first dialog to work with Shale/MyFaces
Hi all:
I am back working with Shale after setting it down for a while. So anyway,
I am trying to get my first dialog to work by making a trivial Search and
Cancel button. Here's what i have in dialog-config.xml:
<dialog name="Search Contacts"
start="SearchHome">
<view name="SearchHome"
viewId="/search.jsp">
<transition outcome="search.find"
target="SearchHome"/>
<transition outcome="cancel"
target="Exit"/>
</view>
<end name="Exit"
viewId="/worklist.jsp">
</end>
</dialog>
My /menu.jsp (via tiles mapping) has:
<h:commandLink id="searchStartMenu" action="dialog:Search Contacts">
<h:outputText value="Search" />
</h:commandLink>
However, clicking on Search gives me nasty errors:
[ERROR] [faces] - Servlet.service() for servlet faces threw exception
<java.lang.IllegalArgumentException: Search
Contacts>java.lang.IllegalArgumentException: Search Contacts
at
org.apache.shale.dialog.faces.DialogNavigationHandler.start(DialogNavigationHandler.java:446)
at
org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(DialogNavigationHandler.java:183)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:84)
etc..
Do I need to configure anything else? Or am I running into trouble because
I am using tiles?
(I am working with the nightly struts-shale build dated today).
Thanks in advance,
Geeta
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/8/06, gramani@intellicare.com <gr...@intellicare.com> wrote:
<snip/>
>
> Ah, this is a bad thing for me..(:( I really absolutely have to have an
> always visible and always clickable menu bar and after reading the
> bugzilla notes seems like "breaking out of" a current dialog and starting
> abrand new one without formally ending it is not possible now (hope I have
> that right?). So i will either cludge a solution or stay my use of dialogs
> till you guys have figured out the right solution.
>
<snap/>
Dialog progression is driven purely by UI gestures. There were a
couple of posts on the dev list a few days back that are probably of
interest here:
http://marc.theaimsgroup.com/?l=struts-dev&m=113657007806524&w=2
I don't think a RFE was filed, but I haven't been watching for it
either. I would've filed one myself if I had a patch to propose.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by gr...@intellicare.com.
Rahul Akolkar <ra...@gmail.com> wrote on 01/08/2006 12:43:40 AM:
>
> Not really. I understand your "specs" now, whats the "nasty error" you
> refer to, does that hold any clues?
Ok, so after reading your post and Craig's subsequent reply, I realised
that it is ok to return a "null" from the bean action and Shale would act
in the "usual" way. I was earlier returning the actual name of the view id
i was on and that was what was the problem. Returning null solved that
problem and my dialog works without the cludgy "different name" i thought
I needed..:)
> A couple of things that I think are relevant here:
>
> * A self transition for a view state should be possible (its
> definitely legit in state chart theory, Shale dialogs being state
> charts for a specific purpose).
Yes, as I note above, it was "stupid user" kind of error.
>
> * I tend to use action states since I can visualize the processing
> bits as states in the dialog config (and searching definitely
> qualifies), and the corresponding multiple logical outcomes (error, no
> results, few results, many results) appear as transitions in the
> action state. But, I understand this is subjective.
Ok...
>
> There is nothing wrong with "common" transitions -- Shale calls these
> global transitions -- pending they're truly common. Looking at what
> you have listed:
>
> * Transitions such as the first one (cancel) are useful when
> specified as global transitions, especially in wizard style dialogs,
> otherwise you'd be authoring them redundantly.
>
> * The second one is a candidate for localizing (will be a side-effect
> of having one view state).
Yes, I see now. Though returning "null" now obviates this for me now.
>
> * The third one I believe is refering to the "always clickable" menu
> bar link to initiate the search dialog, and that is going to be
> suspect since Shale dialogs, as of today, work best when you run a
> dialog to completion before beginning another (where completion is
> defined as reaching an end state, that says nothing about any *task*
> being completed). Ofcourse, if you're using dialogs, it'd be good be
> aware of the known issues 35066 [1], 37120 [2] and 37571 [3], if
> you're not already.
Ah, this is a bad thing for me..(:( I really absolutely have to have an
always visible and always clickable menu bar and after reading the
bugzilla notes seems like "breaking out of" a current dialog and starting
abrand new one without formally ending it is not possible now (hope I have
that right?). So i will either cludge a solution or stay my use of dialogs
till you guys have figured out the right solution.
>
> And finally, use the latest nightlies if you can, just saw r366984 [4]
> whiz by, that added better error messages for dialogs.
I am working with the Jan 6th nightly. But as you point out that is way
dated.;)
> > >
> > > -Rahul
Yet once more, many many thanks for your time. I really appreciate it.
Geeta
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/8/06, Craig McClanahan <cr...@apache.org> wrote:
> On 1/7/06, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > [snip]
> > * A self transition for a view state should be possible (its
> > definitely legit in state chart theory, Shale dialogs being state
> > charts for a specific purpose).
>
>
> Self-transitions for a view state are definitely legal, but there's an
> interesting semantic twist here. Since we are in a view state, the
> transition is based on the logical outcome returned by the action method
> that is invoked for the submit button that actually submits the form (phew,
> say that sentence three times real fast :-). If the action method returns
> an outcome that happens to map to the same view identifier, a *new*
> component tree is still created, so you lose any state information you've
> stored in the current component tree. If the action method returns null, on
> the other hand, there is a short circuit to the normal transition mechanism
> that causes the current view to be redisplayed, *without* being recreated.
>
> This was done deliberately, so that action methods within a dialog work
> exactly the way they do outside a dialog. From a state chart perspective,
> you can assume there is an additional unspecified transition that says "if
> the logical outcome is null, redisplay the current component tree without
> recreating it." This can be an important consideration when you are
> designing the UI of your application ... even if the *user* doesn't know or
> care whether a new view was created or not in this scenario, it can
> dramatically simplify your dialog configuration, and your application logic,
> to know that this is a scenario you can rely on.
>
<snip/>
That makes sense. A "stay" (null) transition should retain state, a
"self" transition (amounts to calling onexit and onentry -- which gets
us in initial -- for that state) should not.
Now in terms of DialogNavigationHandler#transition(...) a null outcome
and a stay transition seems to produce the identical State as a return
value and hence identical results from a dialog progression
perspective. A quick test by making the "next" transition on page 2 of
the edit profile dialog (from the shale usecases war) point to the
same state seemed to retain the values in the <h:inputText>s. Is my
quick test missing something?
-Rahul
> Craig
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by Craig McClanahan <cr...@apache.org>.
On 1/7/06, Rahul Akolkar <ra...@gmail.com> wrote:
>
> [snip]
> * A self transition for a view state should be possible (its
> definitely legit in state chart theory, Shale dialogs being state
> charts for a specific purpose).
Self-transitions for a view state are definitely legal, but there's an
interesting semantic twist here. Since we are in a view state, the
transition is based on the logical outcome returned by the action method
that is invoked for the submit button that actually submits the form (phew,
say that sentence three times real fast :-). If the action method returns
an outcome that happens to map to the same view identifier, a *new*
component tree is still created, so you lose any state information you've
stored in the current component tree. If the action method returns null, on
the other hand, there is a short circuit to the normal transition mechanism
that causes the current view to be redisplayed, *without* being recreated.
This was done deliberately, so that action methods within a dialog work
exactly the way they do outside a dialog. From a state chart perspective,
you can assume there is an additional unspecified transition that says "if
the logical outcome is null, redisplay the current component tree without
recreating it." This can be an important consideration when you are
designing the UI of your application ... even if the *user* doesn't know or
care whether a new view was created or not in this scenario, it can
dramatically simplify your dialog configuration, and your application logic,
to know that this is a scenario you can rely on.
Craig
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/7/06, gramani@intellicare.com <gr...@intellicare.com> wrote:
> Rahul Akolkar <ra...@gmail.com> wrote on 01/06/2006 05:07:21 PM:
>
> > On 1/6/06, gramani@intellicare.com <gr...@intellicare.com> wrote:
> > <snip/>
> > My "Search" still throws
> > > a nasty error, but I guess I shall struggle with that awhile before
> > > I give up and ask you again..(:(
> > >
> > <snap/>
> >
> > Possibly rethink the corresponding outbound transition from the
> > SearchHome view state (separate the search and results views).
>
> Thank you Rahul. Actually the specs are that my results appear just below
> my search form and I had already coded things so everything was in
> /search.jsp (I used rendered attributes to render results if present).
> However I guess what Shale requires is for the ids (names) to be different
> (and never mind what those names map to).
<snip/>
Not really. I understand your "specs" now, whats the "nasty error" you
refer to, does that hold any clues?
>
> So that's what i did:
>
> <dialog name="Search Contacts" start="Search Home">
>
> <view name="Search Home" viewId="/search.jsp">
> <transition outcome="ContactListSuccess" target="Contact List"/>
> </view>
>
> <view name="Contact List" viewId="/search.jsp">
>
> </view>
>
> <end name="Home" viewId="/worklist.jsp">
> </end>
>
> </dialog>
>
> This worked for my *first* search: my searchBean.find() returns "
> ContactListSuccess" and everything is hunky dory. Sweet. *However*, since
> my search form is visble above my results, I got a Faces error when I
> searched again! And the error made sense too (;) since I was in the
> "ContactListSuccess" state (after the first successful search) and I was
> now transitioning to "ContactSearchSuccess" again due to the second
> search, which is not a legal outcome according to the dialog. So I moved
> the <transition outcome="ContactListSuccess" target="Contact List"/> up
> so it was a common transition (instead of adding it twice) and then I no
> longer got the error.
>
<snip/>
A couple of things that I think are relevant here:
* A self transition for a view state should be possible (its
definitely legit in state chart theory, Shale dialogs being state
charts for a specific purpose).
* I tend to use action states since I can visualize the processing
bits as states in the dialog config (and searching definitely
qualifies), and the corresponding multiple logical outcomes (error, no
results, few results, many results) appear as transitions in the
action state. But, I understand this is subjective.
> Furthermore, my menu bar, which is always visible and which has a link to
> dialog:Search Contacts also is always clickable. Thus I also need a common
> transition for outcome "Search Contacts". So my dialog now looks like
> this:
>
> <dialog name="Search Contacts" start="Search Home">
> <transition outcome="cancel" target="Home"/>
> <transition outcome="ContactListSuccess" target="Contact List"/>
> <transition outcome="Search Contacts" target="Home"/>
>
> <view name="Search Home" viewId="/search.jsp">
>
> </view>
>
> <view name="Contact List" viewId="/search.jsp">
>
> </view>
>
> <end name="Home" viewId="/worklist.jsp">
> </end>
>
> </dialog>
>
> I do have a few more transitions which I have omitted (which are not
> common), but it really seems to me that by making so many of the
> transitions "common", I am not utilizing what Shale can give me via
> dialogs. Is this correct? Or is this what i have to live with since my
> specs dictate I show the search form above my results and I always have
> the menu bar visible? I get the feeling I may be missing something
> important..
>
<snip/>
There is nothing wrong with "common" transitions -- Shale calls these
global transitions -- pending they're truly common. Looking at what
you have listed:
* Transitions such as the first one (cancel) are useful when
specified as global transitions, especially in wizard style dialogs,
otherwise you'd be authoring them redundantly.
* The second one is a candidate for localizing (will be a side-effect
of having one view state).
* The third one I believe is refering to the "always clickable" menu
bar link to initiate the search dialog, and that is going to be
suspect since Shale dialogs, as of today, work best when you run a
dialog to completion before beginning another (where completion is
defined as reaching an end state, that says nothing about any *task*
being completed). Ofcourse, if you're using dialogs, it'd be good be
aware of the known issues 35066 [1], 37120 [2] and 37571 [3], if
you're not already.
And finally, use the latest nightlies if you can, just saw r366984 [4]
whiz by, that added better error messages for dialogs.
-Rahul
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=35066
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=37120
[3] http://issues.apache.org/bugzilla/show_bug.cgi?id=37571
[4] http://svn.apache.org/viewcvs?rev=366984&view=rev
> >
> > -Rahul
>
> Once again thank you for your time and patience!
> Geeta
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by gr...@intellicare.com.
Rahul Akolkar <ra...@gmail.com> wrote on 01/06/2006 05:07:21 PM:
> On 1/6/06, gramani@intellicare.com <gr...@intellicare.com> wrote:
> <snip/>
> >
> > Actually I found that dialog-config.xml had an xml error so I guess it
was
> > silently not loaded. So I fixed it and now the Cancel works (yeahh!!)
so I
> > think at least I have gotten "into the dialog..:) My "Search" still
throws
> > a nasty error, but I guess I shall struggle with that awhile before I
give
> > up and ask you again..(:(
> >
> <snap/>
>
> Possibly rethink the corresponding outbound transition from the
> SearchHome view state (separate the search and results views).
Thank you Rahul. Actually the specs are that my results appear just below
my search form and I had already coded things so everything was in
/search.jsp (I used rendered attributes to render results if present).
However I guess what Shale requires is for the ids (names) to be different
(and never mind what those names map to). So that's what i did:
<dialog name="Search Contacts" start="Search Home">
<view name="Search Home" viewId="/search.jsp">
<transition outcome="ContactListSuccess" target="Contact List"/>
</view>
<view name="Contact List" viewId="/search.jsp">
</view>
<end name="Home" viewId="/worklist.jsp">
</end>
</dialog>
This worked for my *first* search: my searchBean.find() returns "
ContactListSuccess" and everything is hunky dory. Sweet. *However*, since
my search form is visble above my results, I got a Faces error when I
searched again! And the error made sense too (;) since I was in the
"ContactListSuccess" state (after the first successful search) and I was
now transitioning to "ContactSearchSuccess" again due to the second
search, which is not a legal outcome according to the dialog. So I moved
the <transition outcome="ContactListSuccess" target="Contact List"/> up
so it was a common transition (instead of adding it twice) and then I no
longer got the error.
Furthermore, my menu bar, which is always visible and which has a link to
dialog:Search Contacts also is always clickable. Thus I also need a common
transition for outcome "Search Contacts". So my dialog now looks like
this:
<dialog name="Search Contacts" start="Search Home">
<transition outcome="cancel" target="Home"/>
<transition outcome="ContactListSuccess" target="Contact List"/>
<transition outcome="Search Contacts" target="Home"/>
<view name="Search Home" viewId="/search.jsp">
</view>
<view name="Contact List" viewId="/search.jsp">
</view>
<end name="Home" viewId="/worklist.jsp">
</end>
</dialog>
I do have a few more transitions which I have omitted (which are not
common), but it really seems to me that by making so many of the
transitions "common", I am not utilizing what Shale can give me via
dialogs. Is this correct? Or is this what i have to live with since my
specs dictate I show the search form above my results and I always have
the menu bar visible? I get the feeling I may be missing something
important..
>
> -Rahul
Once again thank you for your time and patience!
Geeta
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by Rahul Akolkar <ra...@gmail.com>.
On 1/6/06, gramani@intellicare.com <gr...@intellicare.com> wrote:
<snip/>
>
> Actually I found that dialog-config.xml had an xml error so I guess it was
> silently not loaded. So I fixed it and now the Cancel works (yeahh!!) so I
> think at least I have gotten "into the dialog..:) My "Search" still throws
> a nasty error, but I guess I shall struggle with that awhile before I give
> up and ask you again..(:(
>
<snap/>
Possibly rethink the corresponding outbound transition from the
SearchHome view state (separate the search and results views).
-Rahul
>
> Thank you again for your time,
> Geeta
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by gr...@intellicare.com.
craigmcc@gmail.com wrote on 01/06/2006 04:18:43 PM:
>
> This particular exception means that Shale could not find a dialog named
> "Search Contacts" in the set of configured dialogs. (Yes, the error
message
> should actually *say* that ... it will tonight :-).
Thanks! :)
In turn, that implies
> the dialog configuration file hasn't been loaded. Is this file named
> "/WEB-INF/dialog-config.xml"?
Actually I found that dialog-config.xml had an xml error so I guess it was
silently not loaded. So I fixed it and now the Cancel works (yeahh!!) so I
think at least I have gotten "into the dialog..:) My "Search" still throws
a nasty error, but I guess I shall struggle with that awhile before I give
up and ask you again..(:(
>
> Craig
Thank you again for your time,
Geeta
Re: [Shale] getting my first dialog to work with Shale/MyFaces
Posted by Craig McClanahan <cr...@apache.org>.
On 1/6/06, gramani@intellicare.com <gr...@intellicare.com> wrote:
>
> Hi all:
>
> I am back working with Shale after setting it down for a while. So anyway,
> I am trying to get my first dialog to work by making a trivial Search and
> Cancel button. Here's what i have in dialog-config.xml:
>
> <dialog name="Search Contacts"
> start="SearchHome">
>
> <view name="SearchHome"
> viewId="/search.jsp">
>
> <transition outcome="search.find"
> target="SearchHome"/>
> <transition outcome="cancel"
> target="Exit"/>
> </view>
>
> <end name="Exit"
> viewId="/worklist.jsp">
> </end>
> </dialog>
>
> My /menu.jsp (via tiles mapping) has:
>
> <h:commandLink id="searchStartMenu" action="dialog:Search Contacts">
> <h:outputText value="Search" />
> </h:commandLink>
>
> However, clicking on Search gives me nasty errors:
> [ERROR] [faces] - Servlet.service() for servlet faces threw exception
> <java.lang.IllegalArgumentException: Search
> Contacts>java.lang.IllegalArgumentException: Search Contacts
> at
> org.apache.shale.dialog.faces.DialogNavigationHandler.start(
> DialogNavigationHandler.java:446)
This particular exception means that Shale could not find a dialog named
"Search Contacts" in the set of configured dialogs. (Yes, the error message
should actually *say* that ... it will tonight :-). In turn, that implies
the dialog configuration file hasn't been loaded. Is this file named
"/WEB-INF/dialog-config.xml"? Do you have the Shale filter defined in
web.xml?
The web site has a useful checklist of stuff to make sure you've set up to
use Shale in a webapp:
http://struts.apache.org/struts-shale/using.html
Craig