I am glad *somebody* uses something like "the Visit" object. Indeed in
HLS' book "Tapestry in Action" he recommends using a Visit object.
However, in none (or almost none in the case that I missed it) of the
examples, tutorials, Kent's book, and so forth a Visit object is used.
Instead ASOs are used.
So my question: should I use a central Visit object to manage my
application state or should I use an ASO? Or did I miss somethinng
essential and are those two the same thing? Could somebody please
explain? In my projects so far I have been using a Visit object (T3).
Thanks,
Martijn
Ron Piterman wrote:
Sounds very right to me...
keeping business logic and the presentation apart...
Cheers,
Ron
ציטוט Rob Dennett:
In Tapestry in Action, there is a T3 example of a hangman game where
some of the page class’s logic is shifted to the Visit object. The
documentation recommends having the page classes (and, I guess, the
component classes too) act as facades for POJOs. In keeping with
that, I created a class that maintains the state of the page
properties and deals with listener method code, but has no
Tapestry-specific code in it. It returns a value that tells various
listener methods in the page class to do Tapestry-specific things. I
am planning to make this class an ASO. Is this an appropriate place
for it? Should it be a Spring bean? Given that we will probably
never create another front end for it, is this an unnecessary layer
of indirection? What is the T4 best practice?
Thanks,
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
*Cumquat Information Technology*
De Dreef 19
3706 BR Zeist
T +31 (0)30 - 6940490
F +31 (0)10 - 6940499
http://www.cumquat.nl <http://www.cumquat.nl/>
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
M +31 6 22 384 318
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
