You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Rob Dennett <ro...@tmit1.org> on 2005/09/30 18:10:05 UTC
T4 best practice
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
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.8/113 - Release Date: 9/27/2005
Re: T4 best practice
Posted by Martijn Hinten <ma...@cumquat.nl>.
Thanks for confirming this!
Howard Lewis Ship wrote:
>The Visit object *is* an ASO (application state object). Tapestry 4.0
>just liberates the concept, allowing you to define as many as you
>like.
>
>On 10/1/05, Martijn Hinten <ma...@cumquat.nl> wrote:
>
>
>>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: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>--
>>
>>
>>*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/>
>>
>>martijn.hinten@cumquat.nl <ma...@cumquat.nl>
>>M +31 6 22 384 318
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>--
>Howard M. Lewis Ship
>Independent J2EE / Open-Source Java Consultant
>Creator, Jakarta Tapestry
>Creator, Jakarta HiveMind
>
>Professional Tapestry training, mentoring, support
>and project work. http://howardlewisship.com
>
>
--
*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/>
martijn.hinten@cumquat.nl <ma...@cumquat.nl>
M +31 6 22 384 318
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: T4 best practice
Posted by Howard Lewis Ship <hl...@gmail.com>.
The Visit object *is* an ASO (application state object). Tapestry 4.0
just liberates the concept, allowing you to define as many as you
like.
On 10/1/05, Martijn Hinten <ma...@cumquat.nl> wrote:
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> --
>
>
> *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/>
>
> martijn.hinten@cumquat.nl <ma...@cumquat.nl>
> M +31 6 22 384 318
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
RE: T4 best practice
Posted by Patrick Casey <pa...@adelphia.net>.
The visit object is a *per* session object. So if you and I both log
into tapestry application X, we'll each have our own private visit object.
If you want something to be truly global, don't use a visit object or you're
going to be very confused by the results :).
--- Pat
> -----Original Message-----
> From: Martijn Hinten [mailto:martijn.hinten@cumquat.nl]
> Sent: Saturday, October 01, 2005 12:27 PM
> To: Tapestry users
> Subject: Re: T4 best practice
>
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> --
>
>
> *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/>
>
> martijn.hinten@cumquat.nl <ma...@cumquat.nl>
> M +31 6 22 384 318
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: T4 best practice
Posted by Martijn Hinten <ma...@cumquat.nl>.
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
*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/>
martijn.hinten@cumquat.nl <ma...@cumquat.nl>
M +31 6 22 384 318
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: T4 best practice
Posted by Ron Piterman <rp...@gmx.net>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org