tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anatoli Krassavine" <anatoli.krassav...@intellidos.com>
Subject visit-engine, etc
Date Sun, 01 Jun 2003 22:08:40 GMT
  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


Mime
View raw message