[Seaside] Re: Application/Session Objects

[Yanni Chiu]

Martin J. Laubach wrote:
> |  It seems to me that using the http req/resp as a transaction
> |  boundary is an unnecessary and potentially limiting constraint.
> 
>   The problem is: even though you don't see the http req/resp
> mechanism from your Seaside app, it still is there. And the user
> may decide at any point to do something unexpected, like hitting
> the back button, abandoning a session. So when your database
> transaction spans multiple web pages and the user breaks out of
> your planned path... *boom* you end up with left open transactions,
> transaction starts in already open transactions and whatnot...

Then I think there's missing application logic,
which may be easier to write with good framework
support. Tightly coupling the domain logic to the
http req/resp is "code smell", IMHO. What happens
when you want to automate a task? Would you then
be forced to mock up an http request in order for
the correct logic to execute.

As for back button, abandoned session, abandoned workflow
- well that's what application logic is for. From the users
point of view, they'll already be seeing navigation boundaries
if #isolate: is used, or if they use the back button more than
the default 10 (or 20?) times. Application logic which
detects the undesired navigation and re-orients the user
seems to be along the same vein.

BTW, I saw a presentation on the Spring Web Flow (Java)
framework, about two weeks ago. They seem to have gone
with a page navigation as state machine approach - i.e.
define which page transitions are allowable and support
that paradigm with a framework. They also mentioned some
continuation support, but I've not investigated further.
Another aside, it seems to me that much of the Spring Framework
is designed to bypass the strong typing of the Java language.

A useful insight they had was that there are two styles of
web applications, which I'll call "brochure" and "workflow".
They were clear that their Spring Web Flow was suitable for
workflows, and somewhat unsuitable for brochures. Just
something to keep in mind.