tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Lewis-Shell" <rlewissh...@mac.com>
Subject Re: visit-engine, etc
Date Mon, 02 Jun 2003 20:47:43 GMT
As I understood it, in a stateful application, the engine has a reference to
its visit, and that reference does not change - they are very much coupled.
Am I wrong?

I too have always found the engine/visit distinction confusing, and I put it
down to my WebObjects 'training'.  Joe - you are a WO refugee too right?  It
is all too tempting to feel at home with WOApplication = Engine, and
WOSession = Visit, but WOSession is more like Engine+Visit, and
WOApplication is more like the Servlet I would guess.

R

----- Original Message -----
From: "Anatoli Krassavine" <anatoli.krassavine@intellidos.com>
To: "Tapestry development" <tapestry-dev@jakarta.apache.org>;
<joe@panmachine.biz>
Sent: Monday, June 02, 2003 10:08 AM
Subject: visit-engine, etc


>   Hello Joe,
>
>   Actually I do not feel it is appropriate to continue this discussion in
> this thread - it
> is getting a way too theoretical - we all have to move on. I fired my shot
> because I
> was concerned that Lewis might decide to combine Visit and Engine back
> together (circa
> first release). My fault, I am starting getting paranoid in my old age...
>
>   In a nutshell, Joe, you are using Visit as a controller. Your arguments
> are
> correct for the way you are using it - it makes no sense to have two
> closely-coupled
> controllers side-by-side. Nevertheless, this is not the way Tapestry was
> designed. While
> not inherently flawed, your approach means that you are not using all the
> features of
> the framework. You are also likely to run into troubles with advanced
> situations
> (clustering inside JBoss comes to mind).
>
>   As for "not addressing the Model layer in Tapestry"... Visit is a model
> for all
> practical means and purposes. It hides data persistence and data access
> logic
> and provides a javabean API to access it. True, this is not fitting
ideally
> a textbook definition of MVC model - on the other hand few real-life
designs
> do.
>   Visit provides quite a high level of abstraction, not defining any
> explicit ***Model interface. Under the circumstances and taking into
account
> rampant use of reflection, that seems reasonable to me.
>
>   Cheers,
>    Toly
>
> -----Original Message-----
> From: joe panico [mailto:joe@panmachine.biz]
> Sent: 31 May 2003 23:19
> To: anatoli.krassavine@intellidos.com; Tapestry development;
> joe@panmachine.biz
> Subject: RE: naming question (attention: Geoff!)
>
>
> The visit is part of the Control layer in the MVC scheme. Tapestry doesn't
> address the Model layer at all.
>
> regards,
>
> joe panico
> --
> Open WebMail Project (http://openwebmail.org)
>
>
> ---------- Original Message -----------
> From: "Anatoli Krassavine" <anatoli.krassavine@intellidos.com>
> To: "Tapestry development" <tapestry-dev@jakarta.apache.org>,
> <joe@panmachine.biz>
> Sent: Sat, 31 May 2003 21:09:05 +0100
> Subject: RE: naming question (attention: Geoff!)
>
> > Hello,
> >
> >   I believe it was a very good architectural decision
> > on Howard's part. In Tapestry visit/engine separation is a clear
> > case of MVC (model-view-controller) architbecture - almost a textbook
> > example.
> >
> >   Visit is a model - it is supposed to be a pure data structure.
> > Ideally it is a pure value-object - a bunch of getters/setters and
> > a persistence logic bundled on the side.
> >
> >   Engine is a controller. It is responsible for application business
> > logic only. Note that Tapestry engine does not store any state - one
> > could switch engines in the middle of the session (with the same
> > visit object).
> >
> >   Pages serve as view (implementing MVC on lower level, etc).
> >
> >   One should not mix together controller and model even if they seem
> > to work with the same data. This is actually a situation when more is
> > better - "separation of concerns" allows for cleaner, more flexible
> > design.
> >
> >   You are writing:
> > "Visit ends up needing to know about certain application life-cycle
> > events, such as the boundaries of request-response cycles and
> > session termination/expiration."
> >
> >   Actually this is an incorrect use of visit. All this business
> > logic should be moved outside of visit into dedicated controllers -
> >  probably accessed through engine.
> >
> >   Purists might argue whether Visit should be named Session, etc, but
> > it is beyond point now.
> >
> >   Cheers,
> >    Toly
> >
> > -----Original Message-----
> > From: joe panico [mailto:joe@panmachine.biz]
> > Sent: 31 May 2003 18:53
> > To: Tapestry development
> > Subject: Re: naming question (attention: Geoff!)
> >
> > Howard,
> >
> > I still believe that the most confusing terminology/design in
> > Tapestry is the Engine/Visit business. First, Engine does not, to me,
> >  sound like a per-session construct. Instead, it sounds like a piece
> > of the app-server core (strictly terminology). Second, I don't
> > understand why the user needs to hear about 2 per-session classes
> > (Visit and Engine) when one would do (in design, 1 is always better
> > than 2, all else being equal). Third, in my experience, the Visit
> > ends up needing to know about certain application life-cycle events,
> > such as the boundaries of request-response cycles and session
> > termination/expiration. So I have to propagate these events from the
> > Engine to the Visit. In the end, Visit and Engine look very similar,
> > and I have a hard time seeing the benefit of having separate classes.
> >
> > Is it not possible to collapse the Visit and Engine classes/concepts
> > into a single class/concept named "Session"?
> >
> > regards,
> >
> > joe panico
> > --
> > Open WebMail Project (http://openwebmail.org)
> >
> > ---------- Original Message -----------
> > From: "Howard M. Lewis Ship" <hlship@attbi.com>
> > To: "Tapestry-Dev" <tapestry-dev@jakarta.apache.org>
> > Sent: Sat, 31 May 2003 09:30:52 -0400
> > Subject: naming question (attention: Geoff!)
> >
> > > I've become increasingly unhappy with some Tapestry terminology.
> > >  What with the package name change, we know the upgrade from 2.3 to
> > > 3.0 is going to take a little work, so I've been seeing it as a
> > > chance to do some non-backwards compatible changes.
> > >
> > > Basically, in the book and in the docs, I've been talking about
> > > localized *messages* not localized *strings*.
> > >
> > > In light of that, I think <string-binding> should be <message-
> > > binding> and the "string:" prefix should be "message:".  Also, <set-
> > > string-property> should be <set-message-property> (inside <bean>).
> > >
> > > Obviously changing <string-binding> complicates things when people
> > > upgrade from the Tapestry2.3/DTD1.3 to Tapestry3.0/DTD1.4.  <string-
> > > binding> would still work in DTD 1.3, of course.
> > >
> > > "string:" vs. "message:" is a non-issue, because it was introduced
> > > with 3.0.
> > >
> > > A last minute change to make before the beta, unless people are very
> > > much against it.
> > >
> > > --
> > > Howard M. Lewis Ship
> > > Creator, Tapestry: Java Web Components
> > > http://jakarta.apache.org/tapestry
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > ------- End of Original Message -------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> ------- End of Original Message -------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> 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