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]
