Thiago, Every product that I know of other than tapestry has a well defined API. I am not knocking tapestry, it is a great product, but it's the only one that I know of that does not have a well defined API but is a collection of by-convention like injection points, static methods to override, property collections and ephemeral services. It's very difficult to get your head around these things for a new or seasoned developer. There is no central point to go to find out what features are there to solve a particular problem, and it is because there are too many ways to do things.
In my opinion it's because tapestry overuses injection, annotations and by-convention methods over a plain-and-simple interfaces and APIs. I am fairly new to tapestry - about 6 months. But I have been in this business for 20 years and this is the opinion of not just me but a product of trying to explain tapestry to my team members and problems what we have been encountering. I am just trying to make suggestions to improve tapestry from a new developer perspective. You know tapestry very well, perhaps too well :). I am happy to try to bring a different perspective to the table. On Aug 24, 2011, at 10:15 AM, "Thiago H. de Paula Figueiredo" <[email protected]> wrote: > On Wed, 24 Aug 2011 10:51:24 -0300, Lenny Primak <[email protected]> > wrote: > >> I have been thinking about this as well. This is a general problem with >> dependency injection. When a.developer wants something, it's hard to search >> for it in the world of DI. it's much easier to have an API to do things. > > Tapestry-IoC and Tapestry themselves are/provide APIs, don't they? :) > >> Right now there are hundreds of objects to inject, and each of them has many >> getter methods and indirections to get at the thing that a developer might >> want. > > Which getter methods and indirections? I can't recall almost any cases of > this and I'm using Tapestry 5 since 5.0.5. > >> Also there are hundreds of contribution and override points. > > I disagree. This is something very service-specific, so the service > documentation should talk about that. > >> Its next to impossible to find the right thing to do when coming from a new >> developer perspective. Even if you know what to inject or contribute, it's >> hard without the code examples. >> It's partly a documentation problem but I think it's really hard to fix just >> in the docs since the are so many permutations of what a developer might do. > > I don't know if I like this idea. This seems too much like a blanket solution > for some different problems that could be solved in a better way. As someone > said in another unrelated thread, this looks like a code solution for a > documentation problem. To me, this looks like the better solution would be > more entries in the FAQ and more cookbook examples. > > If something is really needed, I prefer to provide it as a direct injection. > This API would be huge and difficult to maintain, and easy maintenance is a > top priority for Tapestry, maybe even the first one. > > And please continue posting ideas! Even if some suggestion isn't adopted, the > discussion itself can be very valuable. I do think we need to provide the > ServletContext as something @Inject'able. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and > instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
