In 5.0, you can invoke no-args methods, i.e. map.size() In 5.1, you can invoke methods that take parameters.
On Thu, Nov 20, 2008 at 10:35 AM, Jonathan Barker <jonathan.theit...@gmail.com> wrote: > 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:hls...@gmail.com] >> 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 >> <jonathan.theit...@gmail.com> 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:chris_le...@bellsouth.net] >> >> 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 >> >> > <chris_le...@bellsouth.net> 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: users-unsubscr...@tapestry.apache.org >> >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> > For additional commands, e-mail: users-h...@tapestry.apache.org >> > >> > >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator Apache Tapestry and Apache HiveMind >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
