Re: Tapestry-IoC: binding service without code, just convention over configuration
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
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 ListT 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 BaseListPageT, 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]
Re: Tapestry-IoC: binding service without code, just convention over configuration
Em Thu, 20 Nov 2008 13:41:46 -0300, Chris Lewis [EMAIL PROTECTED] escreveu: Thanks for the input Thiago. All discussions are good discussions. :) 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? Yes, but not the full matter. 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. It isn't, and that's exactly where my point is. Most of the time a controller method will just delegate to a corresponding DAO method, but not always. My User controller save() method, for example, encrypts the password before sending it to the DAO. This isn't a persistence issue, it isn't an user interface one, it is a business rule issue, and I keep them separate. 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? This is a common confusion: there is the controller in the MVC pattern and the controller in the 3-tier architecture, and both are different things. A controller in MVC, in Tapestry, would be a page class. The View would be the template. This MVC controller has only user interface code, not business rules code. A controller in a 3-tier architecture has business rules code and no user interface code. This way, for example, I can implement a Swing interface to my applications just rewriting pure user interface code. No business rules code is rewritten. The advantage is complete separation of concerns: user interface in MVC, business rules in controller classes and persistence in DAOs. This way, I can change any tier implementation completely (as long as the tier interfaces don't change) without affecting the other tiers. Thanks again for sharing, I value such conversation :-). So I do! :) -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-IoC: binding service without code, just convention over configuration
One more example . . . Em Thu, 20 Nov 2008 14:59:05 -0300, Thiago H. de Paula Figueiredo [EMAIL PROTECTED] escreveu: This is a common confusion: there is the controller in the MVC pattern and the controller in the 3-tier architecture, and both are different things. A controller in MVC, in Tapestry, would be a page class. The View would be the template. This MVC controller has only user interface code, not business rules code. A controller in a 3-tier architecture has business rules code and no user interface code. This way, for example, I can implement a Swing interface to my applications just rewriting pure user interface code. No business rules code is rewritten. Once I made a Java Web frameworks comparison presentation (Struts 1, Struts 2, JSF, and Tapestry 5). In order to compare them I wrote a simple application (almost the same as the Ars Machina example project) in a 3-tier architecture, just like I described above. The DAO and business rules were implemented once, as a separate project. Then, for each framework, I built a Web interface, just importing the example core project. If I implemented the business rules in Tapestry page classes, for example, I would need to rewrite them when implementing the Struts 1 (argh!) version. I love Tapestry (I even have some open-source projects wrote on the top of it) and I don't plan to replace it, but I really want to be able to replace the user interface or add a new one any time I want with very little effort. The targets here are mantainability, flexibility, separation of concerns, ..., and mental sanity. :) -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry-IoC: binding service without code, just convention over configuration
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 ListT 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 BaseListPageT, 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
Re: Tapestry-IoC: binding service without code, just convention over configuration
I think Tapestry makes it easier to separate your business logic out as IoC services or even Spring beans. It's easier to inject a service or bean in Tapestry than in any framework I'm aware of. My of the examples, demos or prototypes do intentionally blur the layers a bit, but you are anything but trapped in that simple, flat model. On Thu, Nov 20, 2008 at 10:09 AM, Thiago H. de Paula Figueiredo [EMAIL PROTECTED] wrote: One more example . . . Em Thu, 20 Nov 2008 14:59:05 -0300, Thiago H. de Paula Figueiredo [EMAIL PROTECTED] escreveu: This is a common confusion: there is the controller in the MVC pattern and the controller in the 3-tier architecture, and both are different things. A controller in MVC, in Tapestry, would be a page class. The View would be the template. This MVC controller has only user interface code, not business rules code. A controller in a 3-tier architecture has business rules code and no user interface code. This way, for example, I can implement a Swing interface to my applications just rewriting pure user interface code. No business rules code is rewritten. Once I made a Java Web frameworks comparison presentation (Struts 1, Struts 2, JSF, and Tapestry 5). In order to compare them I wrote a simple application (almost the same as the Ars Machina example project) in a 3-tier architecture, just like I described above. The DAO and business rules were implemented once, as a separate project. Then, for each framework, I built a Web interface, just importing the example core project. If I implemented the business rules in Tapestry page classes, for example, I would need to rewrite them when implementing the Struts 1 (argh!) version. I love Tapestry (I even have some open-source projects wrote on the top of it) and I don't plan to replace it, but I really want to be able to replace the user interface or add a new one any time I want with very little effort. The targets here are mantainability, flexibility, separation of concerns, ..., and mental sanity. :) -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - 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]
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 ListT 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 BaseListPageT, 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
Re: Tapestry-IoC: binding service without code, just convention over configuration
Em Thu, 20 Nov 2008 14:16:33 -0300, Jonathan Barker [EMAIL PROTECTED] escreveu: Ah, I had to jump in. Everybody is invited! I like using business services that keep data access code out of my pages. That part feels good. So do I! :) Unfortunately, that often means that a findAll() in the DAO has a corresponding findAll() in the service and that just feels silly. Mantainability has downsides . . . :) 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. My approach (and the general 3-tier too) is to have pages and any user interface code always using controllers, never using DAOs directly. 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. That's one of the reasons I wrote the Ars Machina Generic DAO, Generic DAO-Hibernate and Generic Controller: all the common methods (findAll, findById, save, update, delete, findByExample, etc) are already written. I don't have to rewrite them for every entity class. 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. That's what I want to provide default service implementations in Tapestry-IoC: not having to implement trivial DAOs and controller implementations, just the ones that have methods that my generic DAO and generic controller don't have, and still use the whole user inteface classes never use DAOs directly mantra. If anyone figures out the One True Way, let me know! In the meantime, I'll settle for keeping Session out of my pages. My own one true way was described in this message. :) Comments are invited! ;) -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-IoC: binding service without code, just convention over configuration
Em Thu, 20 Nov 2008 14:14:59 -0300, Howard Lewis Ship [EMAIL PROTECTED] escreveu: I think Tapestry makes it easier to separate your business logic out as IoC services or even Spring beans. It's easier to inject a service or bean in Tapestry than in any framework I'm aware of. I completely agree. My of the examples, demos or prototypes do intentionally blur the layers a bit, but you are anything but trapped in that simple, flat model. As far as I know, I cannot put the @CommitAfter method in one IoC service and have its calls wrapped in a transaction, just components and pages methods. If I'm wrong, I'll use Tapestry-Hibernate. If not, I'm still waiting to have time to write Tapestry-Transaction. :) And I wouldn't even need much time, as Tapestry IoC aspect-oriented support is amazingly simple and powerful. ;) -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-IoC: binding service without code, just convention over configuration
Em Thu, 20 Nov 2008 15:28:02 -0300, Thiago H. de Paula Figueiredo [EMAIL PROTECTED] escreveu: As far as I know, I cannot put the @CommitAfter method in one IoC service and have its calls wrapped in a transaction, just components and pages methods. If I'm wrong, I'll use Tapestry-Hibernate. If not, I'm still waiting to have time to write Tapestry-Transaction. :) And I wouldn't even need much time, as Tapestry IoC aspect-oriented support is amazingly simple and powerful. ;) Reading the Tapestry-Hibernate, I've found that I was wrong. The last time I've read it, there was not mention of the HibernateTransactionDecorator. Nice! Just one comment: could we annotate the method implementation in a concrete class instead of annotating the service method (in the interface)? -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor Consultor, desenvolvedor e instrutor em Java http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry-IoC: binding service without code, just convention over configuration
That's one of the reasons I wrote the Ars Machina Generic DAO, Generic DAO-Hibernate and Generic Controller: all the common methods (findAll, findById, save, update, delete, findByExample, etc) are already written. I don't have to rewrite them for every entity class. My generic dao is pretty much the same and includes everything you said. The design began when I started using T4 and really just added Generics to what was already available with Spring's HibernateTemplate. I've extended to include findByQuery and a few others that I find REALLY handy during development to take advantage of Tapestry class reloading. (I later add methods to the relevant DAO to replace it, and get *QL out of the view.). 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. That's what I want to provide default service implementations in Tapestry-IoC: not having to implement trivial DAOs and controller implementations, just the ones that have methods that my generic DAO and generic controller don't have, and still use the whole user inteface classes never use DAOs directly mantra. Well that makes sense. It's the repetitive stuff that makes me feel like there's a better way. Jonathan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry-IoC: binding service without code, just convention over configuration
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 ListT findAll(int firstResult, int maxResults
Tapestry-IoC: binding service without code, just convention over configuration
Hi!
I have been wondering about some ways to write even less configuration
with Tapestry-IoC and yet more convention over configuration.
At first we had:
public static void bind(ServiceBinder binder) {
binder.bind(Service.class, ServiceImplementation.class);
}
Then, if ServiceImplementation is in the same package, we can write:
public static void bind(ServiceBinder binder) {
binder.bind(Service.class);
}
I'm thinking of not even have that binder.bind() call, automatically
binding services located in packages defined by some convention. How could
I implement that? Can we add services to a Registry or use ServiceBinder
just like we can use add objects to a service distributed configuration? I
spent some time looking at the Tapestry sources, but I couldn't find an
answer.
Another related funcionality I was thinking was to automatically provide
some well-know service implementations when no one was explicitly
providaded. Example: suppose we have the convention that every entity
class must a corresponding controller class. Then I want to provide a
default controller implementation for it if none is provided, because some
components and pages expect one controller instance for each entity class.
How could I do that?
My goal is to to have non-trivial zero configuration (or almost zero
configuration) applications in Tapestry, provided that they follow the
conventions.
Thanks in advance. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-IoC: binding service without code, just convention over configuration
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
public static void bind(ServiceBinder binder)
{
new AutoServiceBinder(my.package.root).bind(binder);
}
On Wed, Nov 19, 2008 at 11:12 AM, Thiago H. de Paula Figueiredo
[EMAIL PROTECTED] wrote:
Hi!
I have been wondering about some ways to write even less configuration with
Tapestry-IoC and yet more convention over configuration.
At first we had:
public static void bind(ServiceBinder binder) {
binder.bind(Service.class, ServiceImplementation.class);
}
Then, if ServiceImplementation is in the same package, we can write:
public static void bind(ServiceBinder binder) {
binder.bind(Service.class);
}
I'm thinking of not even have that binder.bind() call, automatically binding
services located in packages defined by some convention. How could I
implement that? Can we add services to a Registry or use ServiceBinder just
like we can use add objects to a service distributed configuration? I spent
some time looking at the Tapestry sources, but I couldn't find an answer.
Another related funcionality I was thinking was to automatically provide
some well-know service implementations when no one was explicitly
providaded. Example: suppose we have the convention that every entity class
must a corresponding controller class. Then I want to provide a default
controller implementation for it if none is provided, because some
components and pages expect one controller instance for each entity class.
How could I do that?
My goal is to to have non-trivial zero configuration (or almost zero
configuration) applications in Tapestry, provided that they follow the
conventions.
Thanks in advance. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
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]
Re: Tapestry-IoC: binding service without code, just convention over configuration
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship [EMAIL PROTECTED]
escreveu:
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
public static void bind(ServiceBinder binder)
{
new AutoServiceBinder(my.package.root).bind(binder);
}
As Tapestry already knows the application package root, we could even not
have the above step.
Suppose br.com.arsmachina.example.web (I like to put everything
interface-related in a separate package) is my root package. Then I use
the following conventions:
Entities: br.com.arsmachina.example.entity.
DAO definitions: br.com.arsmachina.example.dao.
DAO implementatinos: br.com.arsmachina.example.dao.impl.
Controller definitions: br.com.arsmachina.example.controller.
Controller implementatinos: br.com.arsmachina.example.controller.impl.
For a given entity, say, User:
br.com.arsmachina.entity.User
br.com.arsmachina.entity.dao.UserDAO
br.com.arsmachina.entity.dao.impl.UserDAOImpl
br.com.arsmachina.entity.controller.UserController
br.com.arsmachina.entity.controller.impl.UserControllerImpl
I already implemented something related in Tapestry CRUD
(www.arsmachina.com.br/project/tapestrycrud) using ClassNameLocator, but
to automatically associate entities with their controllers and entities
with their encoders
(http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/tapestry-crud/trunk/src/main/java/br/com/arsmachina/tapestrycrud/encoder/Encoder.java?revision=274view=markup).
Howard, the Ars Machina Project (that includes packages like Tapestry CRUD
and Tapestry Access Logger) was released while you were in Europe, so I
guess you haven't notice the release message I sent to this mailing list .
. . I would love to have your feedback about my packages. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-IoC: binding service without code, just convention over configuration
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship [EMAIL PROTECTED]
escreveu:
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
public static void bind(ServiceBinder binder)
{
new AutoServiceBinder(my.package.root).bind(binder);
}
How can I get a ClassNameLocator instance in bind(ServiceBinder binder)?
Trying to inject through public static void bind(ServiceBinder binder,
ClassNameLocator classNameLocator) does not work (method is never
invoked). It must be static, so I cannot use a constructor in my module
class.
And what about the creation of default implementation for unbound services?
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-IoC: binding service without code, just convention over configuration
Hi Thiago,
Out of architectural curiosity, what do you use a UserController for in
your example?
Thiago H. de Paula Figueiredo wrote:
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship
[EMAIL PROTECTED] escreveu:
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
public static void bind(ServiceBinder binder)
{
new AutoServiceBinder(my.package.root).bind(binder);
}
As Tapestry already knows the application package root, we could even
not have the above step.
Suppose br.com.arsmachina.example.web (I like to put everything
interface-related in a separate package) is my root package. Then I
use the following conventions:
Entities: br.com.arsmachina.example.entity.
DAO definitions: br.com.arsmachina.example.dao.
DAO implementatinos: br.com.arsmachina.example.dao.impl.
Controller definitions: br.com.arsmachina.example.controller.
Controller implementatinos: br.com.arsmachina.example.controller.impl.
For a given entity, say, User:
br.com.arsmachina.entity.User
br.com.arsmachina.entity.dao.UserDAO
br.com.arsmachina.entity.dao.impl.UserDAOImpl
br.com.arsmachina.entity.controller.UserController
br.com.arsmachina.entity.controller.impl.UserControllerImpl
I already implemented something related in Tapestry CRUD
(www.arsmachina.com.br/project/tapestrycrud) using ClassNameLocator,
but to automatically associate entities with their controllers and
entities with their encoders
(http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/tapestry-crud/trunk/src/main/java/br/com/arsmachina/tapestrycrud/encoder/Encoder.java?revision=274view=markup).
Howard, the Ars Machina Project (that includes packages like Tapestry
CRUD and Tapestry Access Logger) was released while you were in
Europe, so I guess you haven't notice the release message I sent to
this mailing list . . . I would love to have your feedback about my
packages. :)
--
http://thegodcode.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-IoC: binding service without code, just convention over configuration
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 ListT 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 BaseListPageT, 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). -- Thiago H. de Paula Figueiredo Independent Java consultant, developer, and instructor http://www.arsmachina.com.br/thiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry-IoC: binding service without code, just convention over configuration
I'm thinking of not even have that binder.bind() call, automatically
binding services located in packages defined by some convention.
Very interesting idea. This mechanism could be something similar to Spring's
classpath scanning for managed components:
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-classpath-scanning
It would allow us auto-bind services based on regex, annotation or any
custom strategy with zero additional configuration. We could for instance
use this annotation based strategy:
@Service
public class MyService implements MyServiceImpl {
...
}
And IOC registry would be able during startup automatically detect all
classes with @Service annotation in some specific package and bind them. I
would really like it.
On Wed, Nov 19, 2008 at 7:12 PM, Thiago H. de Paula Figueiredo
[EMAIL PROTECTED] wrote:
Hi!
I have been wondering about some ways to write even less configuration with
Tapestry-IoC and yet more convention over configuration.
At first we had:
public static void bind(ServiceBinder binder) {
binder.bind(Service.class, ServiceImplementation.class);
}
Then, if ServiceImplementation is in the same package, we can write:
public static void bind(ServiceBinder binder) {
binder.bind(Service.class);
}
I'm thinking of not even have that binder.bind() call, automatically
binding services located in packages defined by some convention. How could I
implement that? Can we add services to a Registry or use ServiceBinder just
like we can use add objects to a service distributed configuration? I spent
some time looking at the Tapestry sources, but I couldn't find an answer.
Another related funcionality I was thinking was to automatically provide
some well-know service implementations when no one was explicitly
providaded. Example: suppose we have the convention that every entity class
must a corresponding controller class. Then I want to provide a default
controller implementation for it if none is provided, because some
components and pages expect one controller instance for each entity class.
How could I do that?
My goal is to to have non-trivial zero configuration (or almost zero
configuration) applications in Tapestry, provided that they follow the
conventions.
Thanks in advance. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
