You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Vjeran Marcinko <vj...@email.t-com.hr> on 2005/08/14 16:22:10 UTC
Is injection overkill for pages/components?
Hi all.
I started experimentally porting my small Tapestry3.0 apps to 4.0), and
cannot get away from feel that dependency injection is a bit overkill for
web pages/components. (BTW, boot time in 4.0 is much, much larger. I assume
it is due to HiveMind bytecode enhancing many things in there ?)
Maybe it's because I always tend to unit test just business classes, not web
ones, so I don't see so much usefulness in DI there. I don't run into cases
when I want to inject different implementations of dependency in my web
page/component class. Are there some other benefits?
Burden is that when using service locator, if some dependency is needed on
many places (such as Visit) I can centralize fetching of this object in
superclass, and on the other hand, with DI, I have to define it in every
spec XML. I know that annotations will come to rescue, but untill then....
:-(
Similar case is page that requires many messages from .properties. In old
3.0 days it's not much work, just call getMessage(key) and that's it. Now, I
would have to inject every message by specifying it in XML. Too much typing
just for simple message fetch. Same for injecting pages..etc...
Suddenly, my page classes end up having really lot of ugly abstract methods,
and long spec XMLs...
Thoughts?
Cheers,
Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Is injection overkill for pages/components?
Posted by Adam Greene <ag...@iq-2000.com>.
As to messages, if you are using the messages as parameters, just use the
message: prefix.
----- Original Message -----
From: "Kent Tong" <ke...@cpttm.org.mo>
To: <ta...@jakarta.apache.org>
Sent: Monday, August 15, 2005 1:57 PM
Subject: Re: Is injection overkill for pages/components?
> Vjeran Marcinko <vjeran.marcinko <at> email.t-com.hr> writes:
>
>> I started experimentally porting my small Tapestry3.0 apps to 4.0), and
>> cannot get away from feel that dependency injection is a bit overkill for
>> web pages/components. (BTW, boot time in 4.0 is much, much larger. I
>> assume
>> it is due to HiveMind bytecode enhancing many things in there ?)
>
> Agreed (regarding the boot time). I think this is a major issue to be
> tackled.
>
>> Burden is that when using service locator, if some dependency is needed
>> on
>> many places (such as Visit) I can centralize fetching of this object in
>> superclass, and on the other hand, with DI, I have to define it in every
>> spec XML. I know that annotations will come to rescue, but untill
>> then....
>
> Right. It may help a little by encapsulating it into a component:
>
> ClearingHouse.jwc:
> <component-specification>
> <inject property="visit" type="state" object="visit"/>
> <inject property="global" type="state" object="global"/>
> </component-specification>
>
> Foo.html:
> <span jwcid="ch@ClearingHouse"/>
>
> Foo.java:
>
> getComponent("ch").getProperty("visit");
> getComponent("ch").getProperty("global");
>
> It isn't too much work as the ClearingHouse component is defined
> only once.
>
>> Similar case is page that requires many messages from .properties. In old
>> 3.0 days it's not much work, just call getMessage(key) and that's it.
>> Now, I
>> would have to inject every message by specifying it in XML. Too much
>> typing
>> just for simple message fetch. Same for injecting pages..etc...
>
> You don't have to use injection. For example, you may try:
>
> getMessages().getMessage(key);
>
> You can also define a convenient method in your base page:
>
> class Base {
> String getMsg(String key) {
> return getMessages().getMessage(key);
> }
> }
>
> --
> Author of an e-Book for learning Tapestry
> (http://www.agileskills2.org/EWDT)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Is injection overkill for pages/components?
Posted by Kent Tong <ke...@cpttm.org.mo>.
Vjeran Marcinko <vjeran.marcinko <at> email.t-com.hr> writes:
> I started experimentally porting my small Tapestry3.0 apps to 4.0), and
> cannot get away from feel that dependency injection is a bit overkill for
> web pages/components. (BTW, boot time in 4.0 is much, much larger. I assume
> it is due to HiveMind bytecode enhancing many things in there ?)
Agreed (regarding the boot time). I think this is a major issue to be
tackled.
> Burden is that when using service locator, if some dependency is needed on
> many places (such as Visit) I can centralize fetching of this object in
> superclass, and on the other hand, with DI, I have to define it in every
> spec XML. I know that annotations will come to rescue, but untill then....
Right. It may help a little by encapsulating it into a component:
ClearingHouse.jwc:
<component-specification>
<inject property="visit" type="state" object="visit"/>
<inject property="global" type="state" object="global"/>
</component-specification>
Foo.html:
<span jwcid="ch@ClearingHouse"/>
Foo.java:
getComponent("ch").getProperty("visit");
getComponent("ch").getProperty("global");
It isn't too much work as the ClearingHouse component is defined
only once.
> Similar case is page that requires many messages from .properties. In old
> 3.0 days it's not much work, just call getMessage(key) and that's it. Now, I
> would have to inject every message by specifying it in XML. Too much typing
> just for simple message fetch. Same for injecting pages..etc...
You don't have to use injection. For example, you may try:
getMessages().getMessage(key);
You can also define a convenient method in your base page:
class Base {
String getMsg(String key) {
return getMessages().getMessage(key);
}
}
--
Author of an e-Book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Some more T4 questions/problems
Posted by Howard Lewis Ship <hl...@gmail.com>.
And thats one of many valid arguments for why a framework that
requires you to extend a base class is flawed. Anyone got a time
machine?
On 8/15/05, Onno Scheffers <on...@atomicdigitalstudios.com> wrote:
> Howard Lewis Ship wrote:
>
> >This is the essense of backwards compatibility.
> >
> >
> Thanks for the answers Howard.
> The reason I asked if I still need to extend the BasePage was because I
> figured you may have implemented an alternative to the BasePage without
> those warnings. IMO a framework should only give deprecation-warnings
> during compile if the framework-user does something in a deprecated way.
> It's just weird to get compiler-warnings if you do things the proper
> way. It causes confusion.
>
> regards,
>
> Onno
>
> >On 8/14/05, Onno Scheffers <on...@atomicdigitalstudios.com> wrote:
> >
> >
> >>I'm trying to get to grips with the Tapestry 4 way of doing things (beta
> >>4). I still have a couple of questions:
> >>
> >>- For every page that extends the BasePage I get 4 deprecation warnings:
> >> Warning: Warning: line (14)[deprecation]
> >>removePageRenderListener(org.apache.tapestry.event.PageRenderListener)
> >>in org.apache.tapestry.IPage has been deprecated
> >> Warning: Warning: line (14)[deprecation]
> >>addPageRenderListener(org.apache.tapestry.event.PageRenderListener) in
> >>org.apache.tapestry.IPage has been deprecated
> >> Warning: Warning: line (14)[deprecation] getGlobal() in
> >>org.apache.tapestry.IPage has been deprecated
> >> Warning: Warning: line (14)[deprecation] getVisit() in
> >>org.apache.tapestry.IPage has been deprecated
> >>This quickly grows into a huge number of warnings. I do still need to
> >>extend the BasePage, right? (The 'QuickStart: DirectLink' example still
> >>does).
> >>
> >>
> >>- The user guide on the website is not yet complete regarding
> >>validation; I use the T3 way of using validFields, which gives me
> >>runtime deprecation-warnings in my log.
> >> What should I use instead of ValidFields?
> >>
> >>
> >
> >TextField, and make use of the new translator and validators
> >parameters. Yes, its not well documented yet!
> >
> >
> >
> >>- When I implement my own ValidationDelegate the writeSuffix method
> >>always gets null as a validator parameter. Is that supposed to happen?
> >>Or does that have to do with my previous question?
> >>
> >>
> >
> >The writeSuffix method is getting invoked for all sorts of stuff now,
> >not just ValidFields. For TextField, TextArea, etc., the validator
> >parameter will be null.
> >
> >
> >
> >> Validation itself is working, so I know the validators are ok. I've
> >>tried it with the 'validator:'-prefix, setting up <bean>s for validators
> >>and even provided validators through my own Page class just
> >> to be sure. But no matter what I try I end up with a null-validator in
> >>the writeSuffix method of my custom ValidationDelegate.
> >>
> >>
> >>Any helps would be appreciated.
> >>
> >>Regards,
> >>
> >>Onno
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Some more T4 questions/problems
Posted by Onno Scheffers <on...@AtomicDigitalStudios.com>.
Howard Lewis Ship wrote:
>This is the essense of backwards compatibility.
>
>
Thanks for the answers Howard.
The reason I asked if I still need to extend the BasePage was because I
figured you may have implemented an alternative to the BasePage without
those warnings. IMO a framework should only give deprecation-warnings
during compile if the framework-user does something in a deprecated way.
It's just weird to get compiler-warnings if you do things the proper
way. It causes confusion.
regards,
Onno
>On 8/14/05, Onno Scheffers <on...@atomicdigitalstudios.com> wrote:
>
>
>>I'm trying to get to grips with the Tapestry 4 way of doing things (beta
>>4). I still have a couple of questions:
>>
>>- For every page that extends the BasePage I get 4 deprecation warnings:
>> Warning: Warning: line (14)[deprecation]
>>removePageRenderListener(org.apache.tapestry.event.PageRenderListener)
>>in org.apache.tapestry.IPage has been deprecated
>> Warning: Warning: line (14)[deprecation]
>>addPageRenderListener(org.apache.tapestry.event.PageRenderListener) in
>>org.apache.tapestry.IPage has been deprecated
>> Warning: Warning: line (14)[deprecation] getGlobal() in
>>org.apache.tapestry.IPage has been deprecated
>> Warning: Warning: line (14)[deprecation] getVisit() in
>>org.apache.tapestry.IPage has been deprecated
>>This quickly grows into a huge number of warnings. I do still need to
>>extend the BasePage, right? (The 'QuickStart: DirectLink' example still
>>does).
>>
>>
>>- The user guide on the website is not yet complete regarding
>>validation; I use the T3 way of using validFields, which gives me
>>runtime deprecation-warnings in my log.
>> What should I use instead of ValidFields?
>>
>>
>
>TextField, and make use of the new translator and validators
>parameters. Yes, its not well documented yet!
>
>
>
>>- When I implement my own ValidationDelegate the writeSuffix method
>>always gets null as a validator parameter. Is that supposed to happen?
>>Or does that have to do with my previous question?
>>
>>
>
>The writeSuffix method is getting invoked for all sorts of stuff now,
>not just ValidFields. For TextField, TextArea, etc., the validator
>parameter will be null.
>
>
>
>> Validation itself is working, so I know the validators are ok. I've
>>tried it with the 'validator:'-prefix, setting up <bean>s for validators
>>and even provided validators through my own Page class just
>> to be sure. But no matter what I try I end up with a null-validator in
>>the writeSuffix method of my custom ValidationDelegate.
>>
>>
>>Any helps would be appreciated.
>>
>>Regards,
>>
>>Onno
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Some more T4 questions/problems
Posted by Howard Lewis Ship <hl...@gmail.com>.
Yes, and you are going to continue to get deprecation warnings until
at least Tapestry 4.1, when the deprecated methods are removed. This
is the essense of backwards compatibility. You may be new to Tapestry
(I can't tell), but there are an awful lot of Tapestry 3 applications
out there, dependent upon the old APIs.
On 8/14/05, Onno Scheffers <on...@atomicdigitalstudios.com> wrote:
> I'm trying to get to grips with the Tapestry 4 way of doing things (beta
> 4). I still have a couple of questions:
>
> - For every page that extends the BasePage I get 4 deprecation warnings:
> Warning: Warning: line (14)[deprecation]
> removePageRenderListener(org.apache.tapestry.event.PageRenderListener)
> in org.apache.tapestry.IPage has been deprecated
> Warning: Warning: line (14)[deprecation]
> addPageRenderListener(org.apache.tapestry.event.PageRenderListener) in
> org.apache.tapestry.IPage has been deprecated
> Warning: Warning: line (14)[deprecation] getGlobal() in
> org.apache.tapestry.IPage has been deprecated
> Warning: Warning: line (14)[deprecation] getVisit() in
> org.apache.tapestry.IPage has been deprecated
> This quickly grows into a huge number of warnings. I do still need to
> extend the BasePage, right? (The 'QuickStart: DirectLink' example still
> does).
>
>
> - The user guide on the website is not yet complete regarding
> validation; I use the T3 way of using validFields, which gives me
> runtime deprecation-warnings in my log.
> What should I use instead of ValidFields?
TextField, and make use of the new translator and validators
parameters. Yes, its not well documented yet!
>
>
> - When I implement my own ValidationDelegate the writeSuffix method
> always gets null as a validator parameter. Is that supposed to happen?
> Or does that have to do with my previous question?
The writeSuffix method is getting invoked for all sorts of stuff now,
not just ValidFields. For TextField, TextArea, etc., the validator
parameter will be null.
> Validation itself is working, so I know the validators are ok. I've
> tried it with the 'validator:'-prefix, setting up <bean>s for validators
> and even provided validators through my own Page class just
> to be sure. But no matter what I try I end up with a null-validator in
> the writeSuffix method of my custom ValidationDelegate.
>
>
> Any helps would be appreciated.
>
> Regards,
>
> Onno
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Some more T4 questions/problems
Posted by Onno Scheffers <on...@AtomicDigitalStudios.com>.
I'm trying to get to grips with the Tapestry 4 way of doing things (beta
4). I still have a couple of questions:
- For every page that extends the BasePage I get 4 deprecation warnings:
Warning: Warning: line (14)[deprecation]
removePageRenderListener(org.apache.tapestry.event.PageRenderListener)
in org.apache.tapestry.IPage has been deprecated
Warning: Warning: line (14)[deprecation]
addPageRenderListener(org.apache.tapestry.event.PageRenderListener) in
org.apache.tapestry.IPage has been deprecated
Warning: Warning: line (14)[deprecation] getGlobal() in
org.apache.tapestry.IPage has been deprecated
Warning: Warning: line (14)[deprecation] getVisit() in
org.apache.tapestry.IPage has been deprecated
This quickly grows into a huge number of warnings. I do still need to
extend the BasePage, right? (The 'QuickStart: DirectLink' example still
does).
- The user guide on the website is not yet complete regarding
validation; I use the T3 way of using validFields, which gives me
runtime deprecation-warnings in my log.
What should I use instead of ValidFields?
- When I implement my own ValidationDelegate the writeSuffix method
always gets null as a validator parameter. Is that supposed to happen?
Or does that have to do with my previous question?
Validation itself is working, so I know the validators are ok. I've
tried it with the 'validator:'-prefix, setting up <bean>s for validators
and even provided validators through my own Page class just
to be sure. But no matter what I try I end up with a null-validator in
the writeSuffix method of my custom ValidationDelegate.
Any helps would be appreciated.
Regards,
Onno
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Is injection overkill for pages/components?
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <vj...@email.t-com.hr> wrote:
> ----- Original Message -----
> From: "Paul Cantrell" <ca...@pobox.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Is injection overkill for pages/components?
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
----- Original Message -----
From: "Paul Cantrell" <ca...@pobox.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Is injection overkill for pages/components?
Posted by Paul Cantrell <ca...@pobox.com>.
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?" (The truth is that
there are even times when you really don't need getter and setter
methods. Shocking!)
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 do agree, though, that use of dependency injection can get out of
control, and may not be necessary in every Tapestry project. So ask
yourself: "Is this a customization point? Do I need to decouple these
two classes?" If your team is small and self-contained enough that
tight coupling of code isn't a problem, if your project only gets
deployed for one customer and customization isn't an issue, if
decoupling makes the code harder to comprehend -- don't do it!
Conversely, if decoupling and non-intrusive customization are
problems for you, dependency injection may be a good solution.
Cheers,
Paul
On Aug 14, 2005, at 8:22 AM, Vjeran Marcinko wrote:
> Hi all.
>
> I started experimentally porting my small Tapestry3.0 apps to 4.0),
> and cannot get away from feel that dependency injection is a bit
> overkill for web pages/components. (BTW, boot time in 4.0 is much,
> much larger. I assume it is due to HiveMind bytecode enhancing many
> things in there ?)
> Maybe it's because I always tend to unit test just business
> classes, not web ones, so I don't see so much usefulness in DI
> there. I don't run into cases when I want to inject different
> implementations of dependency in my web page/component class. Are
> there some other benefits?
>
> Burden is that when using service locator, if some dependency is
> needed on many places (such as Visit) I can centralize fetching of
> this object in superclass, and on the other hand, with DI, I have
> to define it in every spec XML. I know that annotations will come
> to rescue, but untill then.... :-(
>
> Similar case is page that requires many messages from .properties.
> In old 3.0 days it's not much work, just call getMessage(key) and
> that's it. Now, I would have to inject every message by specifying
> it in XML. Too much typing just for simple message fetch. Same for
> injecting pages..etc...
>
> Suddenly, my page classes end up having really lot of ugly abstract
> methods, and long spec XMLs...
>
> Thoughts?
>
> Cheers,
> Vjeran
>
>
_________________________________________________________________
"Nationalism is an infantile disease. It is the measles of mankind."
-- Albert Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org