tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Viktor Szathmary" <phrak...@imapmail.org>
Subject Re: Engine vs Visit (was: naming question)
Date Mon, 02 Jun 2003 22:45:06 GMT
On Mon, 02 Jun 2003 17:32:12 -0500, "Viktor Szathmary"
<phraktle@imapmail.org> said:
> hi,
> 
> On Sat, 31 May 2003 12:52:40 -0500, "joe panico" <joe@panmachine.biz>
> said:
> 
> > 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
> 
> i'm also somewhat confused on why the Engine should be stored in the
> session... i don't think it should contain anything specific to the
> session. on the other hand i can see that pooling is useful for this
> object, but it should not matter which instance of the Engine is used for
> the duration of a request - that sort of stuff should be kept in the
> Visit, imho...

let me refine this, since i am aware of how *tapestry* uses the engine,
and why it needs to be in the session (persistent page properties,
etc)...
this is more a question about the perspective of the *developer*.. why
should a developer extend Engine as opposed to a having a Visit object,
etc..

for example the VLib example stores a cache in there for the duration of
the request, and clears it in the end... care have been taken to make the
properties transient, etc. so the "best practice" based on this seems to
be "don't store session-state in the Engine, put it in the Visit", and
"keep request-duration objects in the Engine"... in which case from a
*developer* standpoint it is counterintuitive, that Engine would be
stored in the session.. the only reason is because the *framework* needs
it there...

   viktor


-- 
http://www.fastmail.fm - mmm... Fastmail...

Mime
View raw message