> The question is, how will I do that? How can I hook up a command to
> spring?
Commons CoR ships with an object loader that uses the Commons
Dispatcher to create a Catalog (or repository) of Commands. But that's
not the only way to create a Catalog. You could also use Spring to
load your Chains,
On Fri, 11 Mar 2005 13:09:58 -0500, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> [http://raibledesigns.com/page/rd?anchor=appfuse_refactorings_part_ii_spring]
>
> Matt refactored Appfuse "in Anger" for Spring and has never looked back :)
>
What does this mean? Was AppFuse for something else ori
Rod Johnson's progress is from the latter book to the former one.
Spring is in the middle.
On Fri, 11 Mar 2005 19:27:04 +0100, Leon Rosenberg
<[EMAIL PROTECTED]> wrote:
>
> > If anyone is actually interested in IoC containers, check out Rod
> > Johnson's book, "J2EE Development without EJB".
>
> If anyone is actually interested in IoC containers, check out Rod
> Johnson's book, "J2EE Development without EJB".
ok, bought... :-)
Expert One-on-One J2EE Development without EJB
what about
Expert One-to-One J2EE Design and Development ?
regards
Leon
--
Well, a framework is a semi-complete application [Johnson]. A
lightweight container is essentially an object factory, as you
implied.
Struts is more than a framework. It's also a container that manages
the lifecycle of the objects created by the struts-config.
You could, for example, use Spring t
Ted Husted wrote:
As to business objects, the usual advice is to use Plain Old Java
Objects (POJOs).
The current MailReader example application is an excellent example of
creating a set of interfaces to represent business logic, then
instantiating a set of classes to implement the business logic.
T
> :) Basically, the same reason web applications and struts applications
> need a container. :)
hmm... disagreed. Web applications need a container so they don't need
to handle the http protocol theirself, handle jsps, taglibs and all the
other stuff.
struts itself is a framework, not a container.
:) Basically, the same reason web applications and struts applications
need a container. :)
Being able to instantiate objects using a XML driven factory is very,
very convenient, and make programing strategies possible that would be
otherwise impractical.
Consider how difficult a Struts applicati
Yep.
Lately, I've started writing inner classes to access the business
logic for a particular transaction script. The inner classes take
input in a way conventient to the client, (say, by passing in an
ActionForm,) use that input to interact with the business classes, and
return the output in a w
Why do you need a container? Or why do I need a container?
Leon
On Fri, 2005-03-11 at 07:27 -0600, NetSQL wrote:
> I used Hivemind and switch to CoR, which I consider a light weight
> container.
> Good article on CoR at onJava.com.
>
> .V
>
> Manfred Wolff wrote:
> >
> > Ted.
> >
> > +1 to
I used Hivemind and switch to CoR, which I consider a light weight
container.
Good article on CoR at onJava.com.
.V
Manfred Wolff wrote:
Ted.
+1 to this approach. I prefer leightweight container such as hivemind to
manage the entrypoints to the business logic. Hivemind is easy to learn
and you
Yes.
You are describing almost exactly how I write my struts code.
Here are the components I would use to maintain a Customer table:
- com.myorg.domain.bean.Customer.java
- com.myorg.domain.dao.CustomerDao.java (interface)
- com.myorg.domain.service.CustomerService.java (interface)
- com.myor
Ted.
+1 to this approach. I prefer leightweight container such as hivemind to
manage the entrypoints to the business logic. Hivemind is easy to learn
and you have the benefit, that the lifecycle of the business components
may be steered too (such as pooled components, singletons etc.). Other
co
advance and regards
Marco
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: 11 March 2005 11:03
To: Struts Users Mailing List; karthikeyan balasubramanian
Subject: Re: Struts Business Logic :: Best Practices
As to business objects, the usual advice is to use
As to business objects, the usual advice is to use Plain Old Java
Objects (POJOs).
The current MailReader example application is an excellent example of
creating a set of interfaces to represent business logic, then
instantiating a set of classes to implement the business logic.
The MailReader us
15 matches
Mail list logo
