Yes, but would it be fair to say that it is a T4 best practice to create a session-scoped ASO that handles all non-Tapestry-specific page logic for each page (and maybe for each custom component) in the application? Or should this logic live in the page class, or in a HiveMind service or in a Spring bean?
Thanks, Rob -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Saturday, October 01, 2005 5:13 PM To: Tapestry users Subject: Re: T4 best practice 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 <[EMAIL PROTECTED]> 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: [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] > > -- 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 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 9/30/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.9/116 - Release Date: 9/30/2005 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
