On 11/10/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > Rahul, > > These are interesting use cases. I'm not sure that there is an easy > solution to these problems though. The "back" button and browser > cacheing are handy for the end user but certainly a PITA for > developers! > > One option would be to use the "Token Pattern" (See Core J2EE > Patterns). Shale has an <s:token> that might help you here. I > haven't used it in Shale yet but I have used it in regular Struts. <snip/>
I call that the "Hänsel and Gretel pattern" [1], where one moves around the application dropping breadcrumbs à la "I was here" markers. Personally, I'm not too fond of that pattern, since the application state / data model usually holds enough cues to address these situations. But, the pattern works well and is easy to understand which are major pluses. More importantly though, personal preferences aside, I'm trying to find a solution to address this at the Shale framework level, rather than the application development level. I'm sure more than just the "Token Pattern" solution exist in the latter case. Approaching this from a framework perspective, one needs to define: * The public contract - Where the framework conditionally promises certain services (i.e. the framework promises to realign the dialog server-side based on the viewId the outcome came from, if the application developer indicates that is his/her wish) * Breakage of contract - Where the framework makes it clear what it lost by not availing of the offered services (i.e. the application developer now needs to worry about the IllegalArgumentException's and a "synchronization" scheme of choice having waived the benefits obtained from requesting a dialog which can make certain decisions based on some "smarts" that the application author did not have to explicitly author) I suspect having the ability to handle these use cases within the framework will be appreciated by quite a few developers. But, enough talk. Here is some code -- got around to trying the implicit transitions bit today, albeit with SCXML dialogs since thats my need -- link has the proof of concept implementation, and has a comparison table for the two UI test cases I began this thread with: http://people.apache.org/~rahul/shale/align-dialog/ *time-sensitive URL* Feedback is welcome, constructive criticism or opinion on the open issue even more so (looks like the open issue must have a simple faces based explanation?). -Rahul [1] http://en.wikipedia.org/wiki/Hansel_and_Gretel > > It looks like the validate() method will add an error message. I > guess its up to the developer to check for that error message (perhaps > during the ViewController prerender() method?) > > If anyone is using <s:token> in their applications now, I'd be curious > to know how you decided to implement it. > > sean > > > On 11/4/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > I like Shale dialogs, though there are a couple of issues I'd like to > > investigate. Always helps to know these aren't solved problems. > > > > I dislike the IllegalArgumentException in > > DialogNavigationHandler#handleNavigation(), and want to work on > > eliminating it altogether by handling and delegation, decorated by > > some (additional) implicit behavior. IMO, its far too easy to confuse > > the dialog (state). Cases in point: > > > > UI Test case 1: > > > > 1) Proceed to view (profile/profile2.jsp) in Edit Profile dialog. > > 2) Navigate to view (profile/profile1.jsp) using browser's Back button. > > 3) Fill out username/passwords, click Next (no response). > > 4) Repeat (3), dialog transitions to view (profile/profile3). > > > > The server-side dialog isn't aware of (2) and continues to believe the > > dialog state is as it was in (1). So, instead of next from page 1 in > > (4) taking us to page 2, it takes us to page 3. In this test case, > > since the ViewState's for page 1 and page 2 have similar transitions > > ("next"), we don't see an exception. > > > > UI Test case 2: <snap/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
