Hi,
On Wed, Jul 10, 2002 at 10:15:31AM +0200, [EMAIL PROTECTED] wrote:
>
> My question about the containers was not about whether I should use one
> (Merlin,Fortress,or Phoenix) and what would be the benefit, it was about
> why subclassing AbstractContainer in Fortress :) For example, I didn't have
> to subclass ECM to make things work. I talked about the examples of Marcus
> because he did subclass AbstractContainer for each
> example : servlet example, and swing example.
Yes, in those cases, each example was a separate application,
hence the subclassing in both cases.
The short answer is you don't have to create a new subclass for
each case, that's up to you. The long answer is below.
> My concerns were about the best practices when using Fortress, not about
> whether I should use it or not ;)
Good questions, as Fortress and the concept of a container is still
quite new we're still working out all the answers! :)
This is my understanding of where things fit in. Please note, it's
my interpretation of how I've seen Fortress develop, the others might
point both of us in a different direction with their views as well :)
ECM is purely a component manager, whereas the concept of a
Container is at a higher level.
ECM provides your application with services in the form of
components, it manages the components lifecycle, etc, but ECM
itself doesn't offer any paradigm for how you structure your
application past the component level. As a result, I think many people
use ECM quite differently, via singletons, via static methods, via
compose(), etc.
A Container encapsulates what ECM provides, but allows you to
structure your application better at a higher level, either within a
single container, or a mix of them (in a hierarchical sense).
When you think of a typical application, it's probably broken down
into areas of sizable functionality, and eventually down into objects
that perform certain tasks. I tend to think of the area's as boxes if
you like 'containing' a complete set of functionality, with each box
containing objects (ie. components) that work together to provide it.
The Container concept allows you to stucture your application like
that, hierarchically organising your system depending on it's
size of course. But it's also flexible enough to simply provide a
ComponentManager and operate like ECM did too.
Since Containers provide a set of operations/functionality they're
tied to a particular use, hence the requirement to subclass
AbstractContainer.
Saying this, whether your particular concrete container class simply
provides a getComponentManager() method which is then used just like
ECM, or a set of business operations for a particular piece of
functionality, that works with another set of other containers, etc,
is totally up to you and how you want to structure your application.
That's my interpretation (which could be wrong! :) ), but I hope that
it provides some insight/ideas. Perhaps the others developers might
want to add their thoughts too ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
