Howard, Did I miss something? I didn't' realize I could invoke methods using the prop binding. I think I missed that JIRA closure. I look forward to more functionality there - I miss the power of the ognl binding from T4. (I actually do use the t5components OGNL binding for a few things)
In any event, it's hardly ever as simple as dao.findAll(). There are times where I'm up to six or seven injected DAO's on a page thinking it's time to find a better way. BTW, keep up the great work! I can barely keep up with reading the JIRA announcements - I don't know how you manage to actually close them! Jonathan > -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 20, 2008 12:16 > To: Tapestry users > Subject: Re: Tapestry-IoC: binding service without code, just convention > over configuration > > Or you can expose the DAO as a property of the page, and do > source="dao.findAll()" rather than source="findAll()". > > On Thu, Nov 20, 2008 at 9:16 AM, Jonathan Barker > <[EMAIL PROTECTED]> wrote: > > > > Ah, I had to jump in. > > > > I like using business services that keep data access code out of my > pages. > > That part feels good. > > > > Unfortunately, that often means that a findAll() in the DAO has a > > corresponding findAll() in the service and that just feels silly. > > > > As a result, I tend to use services for "complicated" stuff that > involves > > multiple steps or DAO's, and do direct DAO calls from pages for the > simpler > > stuff. Sometimes that means that I'll be injecting services, and the > DAO's > > that the services use into my pages. That also feels silly. > > > > So then I consider the statement that DAO's have become an anti-pattern. > It > > makes sense when you consider the redundant findAll()'s that result from > > separating data access and business services. On the other hand, it > doesn't > > feel good cluttering business services with HQL, SQL, or whatever. > > > > To really muck it up, I've got DAO's that extend a generic base DAO. > That's > > fine until the class hierarchy gets a few levels deep and now I'm > writing > > DAO's for Person, Customer, and Employee. > > > > If anyone figures out the "One True Way", let me know! In the meantime, > > I'll settle for keeping Session out of my pages. > > > > Jonathan > > > > > >> -----Original Message----- > >> From: Chris Lewis [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, November 20, 2008 11:42 > >> To: Tapestry users > >> Subject: Re: Tapestry-IoC: binding service without code, just > convention > >> over configuration > >> > >> Thanks for the input Thiago. I'm curious about your reasoning for > >> avoiding tapestry-hibernate. I use it for it's value encoder and > primary > >> key encoder auto wiring, and that's pretty much it. I avoid injecting > >> Session into pages, and I assume that's the practice you specifically > >> are avoiding in the name of separation of concern, is that right? > >> > >> I use the same kind of DAO pattern, and I manually wire up DAO > >> implementations in bind() (which is where your idea might be > interesting). > >> > >> I value quality architecture as well, but I'm still trying to > understand > >> what you achieve by slapping in the idea of an entity controller that, > >> for what I can understand, is just a layer between your pages and your > >> DAOs. Do share with me if you disagree, but I treat page classes as > >> controllers for their views. In reality they're more like a box of > >> controllers for the various components, but the point is the same. What > >> value then do you gain from not interacting your DAOs directly, and why > >> does that satisfy your architectural wants? > >> > >> Thanks again for sharing, I value such conversation :-). > >> > >> chris > >> > >> Thiago H. de Paula Figueiredo wrote: > >> > Em Wed, 19 Nov 2008 17:37:48 -0300, Chris Lewis > >> > <[EMAIL PROTECTED]> escreveu: > >> > > >> >> Hi Thiago, > >> > > >> > Hi, Chris! > >> > > >> >> Out of architectural curiosity, what do you use a UserController for > in > >> >> your example? > >> > > >> > I'm a strong supporter of n-tier architectures, so the view layer (in > >> > this case, Tapestry) does no business rules nor does data storage > >> > operations, just deals with the user actions*. Therefore, I have an > >> > UserController (an interface) and UserControllerImpl, the class that > >> > implements any business rules or processes (except persistence) > >> > related to my User entity. > >> > > >> > To see one example of this, all the interfaces and classes cited in > >> > this message are part of Ars Machina Project's Generic Authentication > >> > package (http://www.arsmachina.com.br/project/genericauthentication). > >> > You can browse its source here: > >> > http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/generic- > >> authentication/trunk. > >> > > >> > > >> > For the persistence layer, I have DAOs and the Generic DAO and > Generic > >> > DAO-Hibernate packages > >> (http://www.arsmachina.com.br/project/genericdao). > >> > > >> > UserController is a Controller (Generic Controller package, > >> > http://www.arsmachina.com.br/project/genericcontroller), > subinterface. > >> > One of its methods is List<T> findAll(int firstResult, int > maxResults, > >> > SortCriterion... sortConstraints). If you thought of GridDataSource, > >> > you're right. :) > >> > > >> > Tapestry CRUD (http://www.arsmachina.com.br/project/tapestrycrud), > >> > another Ars Machina Project package, defines a BaseListPage<T, K> > >> > abstract class (T = entity class, K = entity class primary key field > >> > type). BaseListPage finds out what entity its is listing, then gets > >> > its associated Controller instance. It is used to generating an > object > >> > listing using the Grid component. This is why I would like to provide > >> > a default Controller instance if none is given: I wouldn't need to > >> > create a trivial Controller implementation for that. ;) > >> > > >> > Have I satisfied your curiosity? :) If not, I can try to explain it > in > >> > a better way. ;) > >> > > >> > * That's why I don't use Tapestry-Hibernate: in my humble opinion, it > >> > puts transaction control (a processing thing, it should be in the > >> > business rules layer) in the wrong layer (view). > >> > > >> > >> -- > >> http://thegodcode.net > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
