Rahul Akolkar <[EMAIL PROTECTED]> 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
