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.
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:
>
> 1) Proceed to view (profile/profile1.jsp) in Edit Profile dialog.
> 2) Navigate to view (profile/logon.jsp) using browser's Back button.
> 3) Click create profile link (no response).
> 4) Repeat (3), IllegalArgumentException is thrown.
>
> The difference (as compared to test case 1) being the two ViewState's
> in question do not have similar transitions ("create"), causing the
> exception.
>
> Can someone clarify the behavior in (3) -- in either test case. The
> ShaleViewHandler gets a shot in (3), but seems the
> DialogNavigationHandler doesn't, until (4).
>
> If this is a solved problem, please let me know. Even better, if
> anyone could demonstrate a solution with the usecases war, that'd be
> nice. At the onset, I'm thinking of having my custom
> DialogNavigationHandler add implicit transitions to the state machine
> to realign the server side dialog depending on the activity (viewId)
> which was the source for the JSF outcome.
>
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
