tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "joe panico" <...@panmachine.biz>
Subject Re: visit-engine, etc
Date Tue, 03 Jun 2003 01:44:23 GMT

> Joe - you are a WO 
> refugee too right? 

Yep. Maybe I just have WO on the brain. On the other hand, I have been reading
the Tapestry mailing lists for almost 1.5 years now, and I have noticed a
number of Tapestry newbies puzzling over the relative roles of these two objects. 

Yes, when I descibe Tapestry to some of my (former) WO colleagues, I always
tell them WOSession = Visit + Engine. 

If the Visit is storing session-persistent state, then it shouldn't be that
uncommon to run into situations where the Visit needs to be notified about
RequestCycle and http-session events. One simple example is where the Visit
holds reference to some kind of resource that should be cleaned up on Session
termination. You don't want to use finalizers, because those are the
kiss-of-death. So your Visit has to be instructed by the Engine. The lines
start to blur....

joe panico
--
Open WebMail Project (http://openwebmail.org)


---------- Original Message -----------
From: "Richard Lewis-Shell" <rlewisshell@mac.com>
To: <tapestry-dev@jakarta.apache.org>
Sent: Tue, 3 Jun 2003 08:47:43 +1200
Subject: Re: visit-engine, etc

> 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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 -------


Mime
View raw message