The long term theory of IoC/DI is that you will be exposed to less and less API. Today, with Tapestry, you see the base classes (BasePage, BaseComponent) and extend from those, which imposes their "inheritance surface area" to your code ... and causes a number of issues as we grow and improve the APIs.
As Tapestry evolves to a POJO model, and the base class stuff dissapears, what you'll see is that simple apps have no dependencies on the Tapestry APIs at all. As your app increases in complexity, it will be *incrementally* exposed to specific API objects (such ass WebRequest, or IEngineService). Already, in the rewrites of my training labs, I can see the benefits. I can talk about page class, skirt around the abstract thing and the BasePage thing, and get right to the meat, without a sidetrack to IEngine or IRequestCycle. On 8/14/05, Vjeran Marcinko <[EMAIL PROTECTED]> wrote: > ----- Original Message ----- > From: "Paul Cantrell" <[EMAIL PROTECTED]> > To: "Tapestry users" <[email protected]> > Sent: Sunday, August 14, 2005 8:13 PM > Subject: Re: Is injection overkill for pages/components? > > > > Dependency injection / inversion of control / service oriented > > architectures are definitely the latest fashion in software > > engineering -- and every fad wants to run amock. There's a tendency -- > > especially in the Java world -- to take a situational principle and turn > > into a global rule. It's a lot easier to think, "Always do X!" than "Is X > > appropriate in this situation?" > > Couldn't said it better! It is in the nature of human beings to love > simplicity, thus they hate when you offer them some > technology/design/whatever, and tell them they have to *think* when to use > it. Thinking is hard. It's so much nicer to take something as final solution > to everything. > Though practice is obviously harder - one always has to weights benefits and > tradeoffs. Actually, in my last project I even did the thing that goes > against all stadard web practices. I hardcoded messages inside page classes! > Because I realized that I almost never have to skin/localize messages in my > kind of web apps, and .properties files only make mess, and force me to > introduce loosy-typed key->message connection. Keeping everything in java, I > use all the benefits of my IDE as refactorings etc... > > > But it's worth keeping in mind that, beneath the fad, there is a real > > problem that dependency injection solves. Because Tapestry uses Hivemind, > > it's possible to customize a lot of behaviors (e.g. squeezing custom > > types to strings, custom URL schemes, custom lifecycle hooks) without > > forking code or playing nastry tricks with subclasses. Hivemind is well > > worth the 4 or 5 seconds Tapestry takes to start up on my laptop. > > I actually really like it being taken as container. Because of HiveMind, and > when major bugs are solved, I think that *implementation* of Tapestry's user > API will be top notch. It's just that user API itself still suffers from > complexity, and some legacy burdens. > > -Vjeran > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
