tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: Transitions
Date Sun, 21 Sep 2003 16:16:31 GMT
I know integrating workflow has been a long-running desire of mine, so let's see what you got
going.
Alas, I'm swamped with book rewrites at the moment.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Mindbridge [mailto:mindbridgeweb@yahoo.com] 
> Sent: Sunday, September 21, 2003 7:41 AM
> To: Tapestry development
> Subject: Transitions
> 
> 
> Hi guys,
> 
> I'd like to present some ideas for developments in Tapestry. 
> We have been discussing them with Tsvetelin for a while and 
> we have clear ideas as to how they can be integrated in the 
> framework, but we will initially present the ideas only 
> conceptually in an attempt to keep the discussion away from 
> its implementation at the moment and blurring it with details 
> :). Let's see if the ideas make sense first.
> 
> Since there are quite a few things, I will split the 
> descriptions into several emails. 
> 
> 
> TRANSITIONS
> 
> The way web applications typically operate at the moment is 
> to present a page, wait for the user to perform some actions, 
> then activate another page depending on the actions of the 
> user. In a sense this is a state machine, albeit a rather complex one.
> 
> Let's call this going from one page to another a "go-to" 
> transition. In those transitions we do not remember where we 
> came from, we only care where we are at the moment. Those are 
> the predominant transitions that occur in a web application right now.
> 
> Now let's consider a simple "Are you sure?" page that asks 
> the user whether he really would like to perform the action 
> that he has selected. This page may be activated from a 
> number of places (when deleting an item from a list, when 
> about to send email, etc.) and upon completion it must go 
> back to where it was invoked and return a result (ok or 
> cancel). There is an obvious analogy to that process in the 
> programming world -- invoking a function. Thus, let's name 
> this process a "call" transition and the set of pages that we 
> call into a 'unit' (to use Geoff's naming).
> 
> Web frameworks do not normally have built-in support for 
> "call" transitions. The reason is that this is relatively 
> easily implemented in the simpler cases. In Tapestry, for 
> example, you would have a persistent property in the "Are you 
> sure?" page that will contain the name of the page where you 
> would have to return once the user responds. This is passed 
> to the page when it is activated from the place it is invoked.
> 
> Unfortunately this approach is limited and does not work in 
> the general case for the following reasons:
> 
>     - The 'unit' may be called recursively. Let's say you 
> call A. It can then call B, which could then call A again. 
> When using the approach above you would know where to go back 
> in the latter transition, but you would lose this information 
> about the first one. A 'stack' is necessary to remember who 
> has been invoked and by whom (cf. functions).
> 
>     - The 'unit' may be more complex and contain a set of 
> several pages. You should theoretically be able to easily 
> 'return' from any of these pages.
> 
>     - The infamous Back and Refresh buttons that users like 
> to use a lot may cause havoc in the organization of the 
> application. For example, X calls A, which calls B, which 
> calls A again. Instead of responding to what he sees, the 
> user presses 'Back' until he reaches the first A and clicks 
> on a button there. This is a 'check-mate' for simpler 
> schemes. They would perform improper actions unrelated to 
> what the user sees on screen at that point and return you to 
> B rather than X. In most cases even the simplest user actions 
> involving 'call' transitions and the Back button are 
> problematic without a special scheme for handling that. 
> 
> 
> Should the framework support 'call' transitions, essentially 
> allowing the Web UI equivalent of functions?
> 
> The big problem is this: whether one likes it or not, 'call' 
> transitions cannot really be avoided in more complex 
> applications. The developers may try to work around them by 
> rearranging the interface, but there are always things like 
> the 'Are you sure?' page above that lend themselves naturally 
> to the 'call' approach and would require a lot of copy-paste 
> (at least) to work around that. Even so, people are rarely 
> fully protected against the Back button issues described above.
> 
> Our experience: A long time ago we developed a Stack 
> component (written by Tsvetelin) that allows something like 
> what was described above. We did not intend to use it a lot 
> initially, but nowadays it pops up regularly in the UIs we 
> develop. Basically, when you have a new tool in your toolbox, 
> you start using the actions that this tool allows far more 
> frequently. Over the months this component has improved 
> greatly, adding handling for the Back button, etc. 
> Nevertheless, it is clear that it cannot provide everything 
> necessary -- support from the framework proper is sorely 
> needed. What's more, it is natural to have this support 
> there, in the same way that programming languages have 
> support for functions -- you can do far more complex stuff 
> much more easily. The fact that this could make Tapestry far 
> better and more usable than the competition is just an 
> additional perk :)
> 
> 
> Before I go further, do you think this needs to be considered? 
> 
> 
> Best regards,
> -mb
> 


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


Mime
View raw message