You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2008/11/19 19:31:16 UTC
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
<th...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Nov 2008 15:28:02 -0300, Thiago H. de Paula Figueiredo
<th...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Nov 2008 14:14:59 -0300, Howard Lewis Ship <hl...@gmail.com>
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over configuration
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<th...@gmail.com> wrote:
> One more example . . .
>
> Em Thu, 20 Nov 2008 14:59:05 -0300, Thiago H. de Paula Figueiredo
> <th...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
One more example . . .
Em Thu, 20 Nov 2008 14:59:05 -0300, Thiago H. de Paula Figueiredo
<th...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Nov 2008 13:41:46 -0300, Chris Lewis
<ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapestry-IoC: binding service without code, just convention over configuration
Posted by Jonathan Barker <jo...@gmail.com>.
>
> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 20 Nov 2008 14:16:33 -0300, Jonathan Barker
<jo...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over configuration
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<jo...@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:hlship@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
>> <jo...@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_lewis@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
>> >> > <ch...@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-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapestry-IoC: binding service without code, just convention over configuration
Posted by Jonathan Barker <jo...@gmail.com>.
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:hlship@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
> <jo...@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_lewis@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
> >> > <ch...@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-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over configuration
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<jo...@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_lewis@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
>> > <ch...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapestry-IoC: binding service without code, just convention over configuration
Posted by Jonathan Barker <jo...@gmail.com>.
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_lewis@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
> > <ch...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by Chris Lewis <ch...@bellsouth.net>.
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
> <ch...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 19 Nov 2008 17:37:48 -0300, Chris Lewis
<ch...@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).
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by Chris Lewis <ch...@bellsouth.net>.
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
> <hl...@gmail.com> 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=274&view=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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship <hl...@gmail.com>
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=274&view=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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry-IoC: binding service without code, just convention over
configuration
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship <hl...@gmail.com>
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org