[shale] Robust dialogs

[Rahul Akolkar <ra...@gmail.com>]

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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Robust dialogs

[Rahul Akolkar <ra...@gmail.com>]

On 11/11/05, Michael Jouravlev <jm...@gmail.com> wrote:
<snip/>
>
> I cannot tell you about Shale since I use plain Struts + my own
> library. Anyway, the concept is simple:
>
<snap/>
>
> I don't think I will be using Shale anytime soon ;-) But I would like
> to showcase my approach in the comparison of wizards. After all, what
> matters is how browser sees it.
>
<snip/>

Well, if you're only thinking about the end user (who is probably the
most important player in the end-to-end pipeline). Sorry if I misled
you, but my exercise was about minimizing the application development
effort to produce a threshold end-user UI experience, given a
particular framework (which is why using Shale dialogs becomes
important for any meaningful comparison).


>
> I am not sure what do you mean by red herring. Can you clarify, please?
>
<snap/>

I thought that statement was a distraction. Etymological details for
red herring are here [1] ;-)


> The sample app initialized, but Tomcat does not see it running:  "The
> requested resource (/struts-shale-usecases) is not available." Do I
> need something else besides the WAR file?
>
<snip/>

That one is an unmodified Shale nightly, snapshoted to the date I
grabbed the code. Not sure what it could be, other than Wendy's
pointer.

-Rahul

[1] http://www.fallacyfiles.org/redherrf.html



>
> Michael.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Robust dialogs

[Wendy Smoak <ws...@gmail.com>]

On 11/10/05, Michael Jouravlev <jm...@gmail.com> wrote:

> The sample app initialized, but Tomcat does not see it running:  "The
> requested resource (/struts-shale-usecases) is not available." Do I
> need something else besides the WAR file?

Just a guess:  Shale requires Servlet 2.4 (so Tomcat 5.x)
   http://struts.apache.org/shale/index.html#Foundations

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Robust dialogs

[Michael Jouravlev <jm...@gmail.com>]

On 11/10/05, Rahul Akolkar <ra...@gmail.com> wrote:
> > You can compare your
> > testing examples with wizard, which works:
> > http://www.superinterface.com/wizard/signupWizard.do
> <snip/>
>
> Cool. Like the FrontController style setup, you've obviously spent
> time thinking about these kind of usecases.

Yep, quite some :-)

> > Try to use refresh, back, forward and other stuff. You can control the
> > wizard using only designated buttons. The key point is redirecting to
> > the same address.
> >
> <snip/>
>
> But, I'm not sure what to make of this (haven't looked at the code).
> It is unclear to me how much effort is involved in making Shale
> dialogs comply to the "redirect to same address" need.

I cannot tell you about Shale since I use plain Struts + my own
library. Anyway, the concept is simple:

* keep the state on the server
* after processing user input, redirect to the same address, this
prevents browser session history from growing
* serve pages as non-cachable, therefore...
* whenever a user navigates to wizard location, he sees a page
corresponding to current wizard state

My wizard engine is very small, three small classes, no XML, no J2EE,
can be tested in console app. Then I add UI to it, buttons that send
commands, and panels/pages.

> If you want to
> showcase this with the Shale dialogs in the usecases war, I'd be
> interested in knowing how much work was involved.
...
> So, to re-iterate the requirements are:
> 1) "Wizard style" dialog with bi-directional navigation
> 2) Navigation using designated buttons, commandLinks etc. and browser
> navigation buttons.
> 3) Client - dialog alignment at all times, with minimum explicit authoring

I don't think I will be using Shale anytime soon ;-) But I would like
to showcase my approach in the comparison of wizards. After all, what
matters is how browser sees it.

> > On the other hand, this fiddling with navigation buttons is not much
> > relevant for Ajax app.
> <snap/>
>
> This is definitely a red herring.

I am not sure what do you mean by red herring. Can you clarify, please?

> I think it may be best to fork a new thread if we continue this
> conversation, so we can follow the multiple approaches separately.

Ok, please do start a new one with an appropriate subject. In User or in Dev?

> As I said before, if you have the desire and the cycles, I'd be
> interested in your rendition of the Shale usecases war (with your
> preferred approach).

Right, maybe I will try to implement my approach in Shale as well.

> [1] http://people.apache.org/~rahul/shale/align-dialog/

The sample app initialized, but Tomcat does not see it running:  "The
requested resource (/struts-shale-usecases) is not available." Do I
need something else besides the WAR file?

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Robust dialogs

[Rahul Akolkar <ra...@gmail.com>]

On 11/10/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 11/4/05, Rahul Akolkar <ra...@gmail.com> 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.
> >
<snip/>
>
> I am sorry but I just could not keep silence ;-)
<snap/>

Ofcourse, please, speak up. Do they ask you to be silent around here?
;-) Didn't get why you're sorry.


> You can compare your
> testing examples with wizard, which works:
> http://www.superinterface.com/wizard/signupWizard.do
<snip/>

Cool. Like the FrontController style setup, you've obviously spent
time thinking about these kind of usecases.


>
> Try to use refresh, back, forward and other stuff. You can control the
> wizard using only designated buttons. The key point is redirecting to
> the same address.
>
<snip/>

But, I'm not sure what to make of this (haven't looked at the code).
It is unclear to me how much effort is involved in making Shale
dialogs comply to the "redirect to same address" need. If you want to
showcase this with the Shale dialogs in the usecases war, I'd be
interested in knowing how much work was involved.

I'd also be very happy to create a third column along with the
approach I'm trying in this comparison table [1]. The only reason I
didn't put that on the wiki was that wiki pages are a bit tough to get
rid of once created, and I don't have to leave clutter on the Apache
wiki.

So, to re-iterate the requirements are:
1) "Wizard style" dialog with bi-directional navigation
2) Navigation using designated buttons, commandLinks etc. and browser
navigation buttons.
3) Client - dialog alignment at all times, with minimum explicit authoring

The browser navigation buttons are listed since I'd rather not worry
about someone using Opera or some other unfavorable browser that
doesn't meet the requirements (even if thats a corner case), and folks
like to use browser buttons anyway [2].


> On the other hand, this fiddling with navigation buttons is not much
> relevant for Ajax app.
<snap/>

This is definitely a red herring.

I think it may be best to fork a new thread if we continue this
conversation, so we can follow the multiple approaches separately.

As I said before, if you have the desire and the cycles, I'd be
interested in your rendition of the Shale usecases war (with your
preferred approach).

-Rahul

[1] http://people.apache.org/~rahul/shale/align-dialog/
[2] http://www.cosc.canterbury.ac.nz/andrew.cockburn/papers/ijhcsAnalysis.pdf
(somewhat dated, but interesting nevertheless)

>
> Michael.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Robust dialogs

[Michael Jouravlev <jm...@gmail.com>]

On 11/4/05, Rahul Akolkar <ra...@gmail.com> 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.

I am sorry but I just could not keep silence ;-) You can compare your
testing examples with wizard, which works:
http://www.superinterface.com/wizard/signupWizard.do

Try to use refresh, back, forward and other stuff. You can control the
wizard using only designated buttons. The key point is redirecting to
the same address.

On the other hand, this fiddling with navigation buttons is not much
relevant for Ajax app.

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Robust dialogs

[Rahul Akolkar <ra...@gmail.com>]

On 11/10/05, Sean Schofield <se...@gmail.com> 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 <ra...@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Robust dialogs

[Sean Schofield <se...@gmail.com>]

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 <ra...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org