On 1/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Rahul Akolkar <[EMAIL PROTECTED]> wrote on 01/06/2006 05:07:21 PM: > > > On 1/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
