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. 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. But at the end of the day - why be dogmatic about this? 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). > >
