Paulo Gaspar wrote:
> Answer inline:
>
>>Can I ask a couple questions? How do you propose to handle the difference
>>between a Component that is ThreadSafe (i.e. can be used simultaneously
>>by multiple clients) and one that is SingleThreaded (i.e. must have a
>>unique instance for each client)?
>>
>
> What I do in my framework is to ALWAYS have a factory which takes care of
> reading and holding the component configuration, creating it, initializing,
> disposing, etc. It works a bit like a component factory for a pool.
Which is exactly what ExcaliburComponentManager does. There are necessary
improvements, but they will come.
> That factory only implements enough functionality to "make the bridge"
> between the framework and the specifics of each component and the factory
> interface has a function to describe what is the component's lifestyle.
>
> Another object takes care of managing the components depending on that
> lifestyle (I do not rely on the factory for that, of course).
>
>
>
>>They do have purpose. If all you deal with are ThreadSafe Components,
>>then the DefaultComponentManager would be enough for you. Unfortunately,
>>not all projects have that luxury. Creating a new instance for every
>>client is wasteful and causes more work for the server than is necessary.
>>
>
> I understand that.
>
> At the moment, the only components I use that are not ThreadSafe are those
> that are pooled - like database Connections - and some special cases that
> do not match Avalon current scope (like sql queries and other stuff
> specific to my framework).
>
> I do NOT, however, mark (trough their factory) those components as
> Poolable. I just mark them as SingleThreaded and hide the specifics of the
> pool behind the component factory.
Which was the point of this thread.
>
> This way, using a third party component or pool is trivial.
True.
>>The next question is why make everything more "bean" like. JavaBeans,
>>while usable, do have a distinct disadvantage in that they are not
>>clearly marked.
>>
>
> I do not see much use for most pure (no methods) markers. I ended up
> deleting them some 3 months ago and I do not miss them a bit.
The Idea of a Component being marked explicitly as a Component does
have some value to me. It forces you to think in terms of what a Component
is supposed to do. That way you don't run into the JavaBeans antipattern
of everything (data objects included) being a Bean. You encapsulate
data accessor logic apart from the data itself. It is not a correct
pattern to implement Data as a Component.
>
> Of course that for many objects (including the above mentioned
> Component factories) I do use interfaces like:
> Initializable
> Disposable
> Startable
> Contextualizable
> Configurable
> Loggable (like your LogEnabled)
> etc.
That's good. I'd hate to see it all merged together into one large
monolithic interface. That way you only use what you need.
>>A Role defines the logical use of the Component in the system. If
>>the Role interface extends the Component interface, all the hard
>>work is done for you and you don't have to recast the Component
>>to release it.
>>
>
> I understand and I do not have to recast any component since my
> component manager returns Object instead of Component.
And if your Role interface extends Component, you have the same
convenience--while maintaining the protection that forces you to
separate data and the interface to get the data.
> Since I focus on building components that are as independent from
> the framework as possible (which makes them more reusable) I always
> use a component factory. Even if only to take care of configuration.
That's fine. I just would have a hard time with a ComponentManager
that is really simply an ObjectManager. That would be bad.
>>>If you change this one I will only miss having an easy to use
>>>component manager that can manage several components for the same
>>>role (naming them). If one day you want to do this one, I would
>>>like to contribute.
>>>
>>
>>We had explored this in the past. We had big, very impassioned
>>discussions. The result of that is the ComponentSelector interface.
>>You use a ComponentManager to get the ComponentSelector for a role
>>that will have many implementations. The ComponentSelector will
>>select your exact implementation of the Role based on an arbitrary
>>Object as a hint (the most common being a string name).
>>
>
> I also understand that. I tried to use that mechanism as it is but,
> in the end, I found it simpler to change it since my needs are quite
> different.
>
> I know the Avalon Framework (and some other bits) quite well (at
> least last Summer's version) since it was my starting code base for
> the component management and other parts of my framework and I
> rewrote or rearranged most of it to suite my needs.
>
> I am only focusing on the parts of what I have that can be done in
> Avalon since what I have is quite a bit different.
How much so?
> To give you a slight idea, I am building something like Cocoon with
> much less XML and I use my standard ComponentManager to build a kind
> of SiteMap. (Obviously I also studied quite a bit of Cocoon.)
And this forces differences how?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
