On Nov 16, 2007 10:39 PM, Patrick Moore <[EMAIL PROTECTED]> wrote: > Hi Howard -- > > I appreciate the work you are doing on T5 and look forward to moving to it > when it is further along. > > I just want to comment on the only-constructor injection policy that you are > promoting. And the fact that the two paragraphs are contradictory. In the > first you acknowledge that services may be outside the scope of Tapestry > IoC. But in the next you go on to say that "To encourage service > implementations to properly store service depenencies as final instance > variables, such dependencies are passed > only into the constructor." which doesn't jive with the > "place-nice-with-others" phrasing in the first paragraph. > > I disagree with philosophy of forcing people to have the services only > injected via constructors because: > > 1. it results in a monster constructors for some key services.
I would say that those key services may be insufficiently factored into smaller cooperating services. Seperation of concerns! > 2. yet another barrier to converting from T4 > 3. unnecessarily imposing a requirement on the Tapestry developer. > 4. meaningless - just because you force a monster constructor doesn't > mean the person is going to make it a final member. > 5. You are assuming that it is unconceivable for services once wired > together to ever want to be rewired - and this is not the case. I see that as a whole can of worms. I strongly think that static structure / dynamic behavior extends into the services tier. > > But at the end of the day - why be dogmatic about this? Because I'm a very stubborn person? Points well taken. We could definitely do something like Guice and allow the Inject annotation on methods as well as method parameters, to indicate a method which represents a point of injection. > > Or did I misunderstand something? > > -Pat > > P.S. the case for rewiring is thus: Originally wiring the service it is > wired to a local version of another service. While the server is running, > the local service is turned off and replaced with a reference to a remote > version of the service. This would happen if the box is experiencing high > traffic volumes and rather than handle all the work on the current box, the > server starts sending some traffic to an different server. The idea of > rigid, statically wired services defeats this flexibility. > > > On Nov 10, 2007 3:22 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > Services are loaded by the normal class loader without any special > > trickery. We create classes (proxies and such), but don't modify > > existing classes for Tapestry IoC. This is necessary to ensure that > > services code inter-operates properly with all kinds of third party, > > legacy and other code that is far, far beyond the scope of Tapestry > > IoC. > > > > To encourage service implementations to properly store service > > depenencies as final instance variables, such dependencies are passed > > only into the constructor. > > > > So for services, injection is assumed, for the constructor parameters > > (as if an @Inject annotation was present). > > > > > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
