> -----Original Message-----
> From: Adam Hardy [mailto:[EMAIL PROTECTED]
==////==
>
>
> Pilgrim, Peter on 01/08/05 09:30, wrote:
> > Struts 2 should force an Action or ActionForm to be interface or
> > subclass of an abstract type, hence dependency injection.
> >
Oops! My wording was wrong.
Struts 2 should [definitely] __NOT__ force an Action or ActionForm
implement an a particular interface or interfaces, or be a
concrete subclass of any abstract type.
Hence dependency injection presupposes the existance of a container
and also a lifecycle manager.
> > If the former is the case, then it follows that calling the action
> > method should be flexible
> >
> > public void bluegrass(ActionContext ac) { /* ... */}
> >
> > or
> >
> > public void bluegrass() {
> > ActionContext ac = typeOfThreadLocal.getFromSomeWhere();
> > /* ... */ }
> >
> > then you need to handle absurdities like so (the general case )
> >
> > public void bluegrass( A a, B b, ... ActionContext ac, ...
> Y y, Z z )
> > { /* ... */}
> >
>
> Dependency injection lets me swap implementations really
> easily, so for
> instance in testing for business tier, I can have either real DAOs or
> Mock DAOs depending on the XML configuration I choose.
>
> So in the servlet tier, what would be the advantages? In
> testing again I
> guess, choosing to inject either the real Factories or Mock Factories
> (or Delegates or Session Facade, choose your pattern).
>
> You could put this IoC in the struts-config. It could also inject the
> form bean, if the plan allows for its seperation from the action. The
> action would have to be instantiated for each request in that case,
> rather than having one per container.
>
And in particular putting this dependency injection and
assembly information also inside the struts-config would remove
one more XML file to configure.
--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston,
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
==============================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
