----- 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]
