tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mindbridge" <mindbridge...@yahoo.com>
Subject Transitions
Date Sun, 21 Sep 2003 11:40:39 GMT
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. 


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

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

    - 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

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,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message