Hello David!
1.
If I'm not mistake 'prototype' design pattern is about having
a prototype object and cloning it when necessary?
If yes, then I beleive inside Avalon contianers we won't be
able to use that. After all the components are always looked
up and it does not make sense to clone them.
The closest we could get would be to have a custom configuration
builder (or a configuration preprocessor that would rewrite
configuration) that would understand something like the follwoing
format
<stage patternid='aaa'>
<!-- very cool aaa config -->
</stage>
<stage id='foo1'>
<stage id='bar1' refid='aaa'>
<!-- foo1 config -->
</stage>
<stage id='foo2'>
<stage id='bar2' refid='aaa'>
<!-- foo2 config -->
</stage>
(it's Fortress-style config, the only one I now :-)
and the preprocessor would cut out all the components with 'petternid'
attribute but clone them to where it finds 'refid' attribute. The
preporocessor would naturally catch cyclic dependencies of _this_
sort. The result of preprocessing will be
<stage id='foo1'>
<stage id='bar1'>
<!-- very cool aaa config -->
</stage>
</stage>
<stage id='foo2'>
<stage id='bar2'>
<!-- very cool aaa config -->
</stage>
</stage>
2.
But even this does not look good to me.
If we have two identically configured Avalon components it looks
preferable to have only one instead. In case its a singletone
component this will allow the same instance to be reused.
If it is a poolable component a common pool would be used.
2.1
So I would imagine the above shoud better be
<stage id='aaa' private='true'>
<!-- very cool config -->
</stage>
<stage id='foo1'>
<stage refid='aaa'/>
<!-- foo1 config -->
</stage>
<stage id='foo2'>
<stage refid='aaa'/>
<!-- foo2 config -->
</stage>
Of course this implies that <stage> understands a <stage>
child element in the configuration with a refid attribute
and interprets the value of the attribute as a hint for
dynamic lookup. Oh, I'm sorry, I'm afraid I'm again
speaking Fortress. In Fortress you can do that right
away. (The only potential trouble is that you won't
probably get the correct shutdown order, but that
won't kill you, will it? And you will always be able
to "bug" Fortress developers to solve that for you -
your application will serve as a good example for pushing
Fortress closer to an idea ;-)
2.2
Further, if we drop 'foo2' from the example above you may
want to completely hide 'aaa' stage from being accessible
by anyone but 'foo1'. In that case we could think about
rewriting the configuration like
<stage id='foo1'>
<stage id='aaa'>
<!-- very cool config -->
</stage>
<!-- foo1 config -->
</stage>
This again gives us two options: (again I will speak Fortress,
Merlin is only in my to-study list)
2.2.1
We can again have a special configuration preprocessor,
either stand-alone or built-in into a custom container
(a derivative of DefaultContainer if we're in Fortress)
that does somethin really cool about the configuration:
It does inspect the configuration of every component to the
very bottom. If it recognizes somehow some element as a 'nested'
element (this may be done for examply by the 'id' attribute -
let's consider that all that has 'id' is a component definition,
why not? or we may use some other attribute or smth else)
like 'aaa' in the 2.2 config example it does the following:
The <stage id='aaa'> element is completely taken out of config for
'foo1'. This section is pooled to the topmost level and given
an autogenerated unique id. In its place <stage refid='$private.id.aaa'>
is put into configuration for 'foo1'.
In short a 2.2 style configuration is rewritten to be 2.1 style:
<stage id='$private.id.aaa'>
<!-- very cool config -->
</stage>
<stage id='foo1'>
<stage refid='$private.id.aaa'>
<!-- foo1 config -->
</stage>
2.2.2
We can try to do without configuration rewriting.
But then we shall have to make every stage a container itself.
In fortress-speak that is to derive it from DefaultContainer.
(Maybe its easier in Merlin.)
This container would recognize that part of its configuration
are nested components and process them as such. The rest
of configuration it would process like normal configuration.
It's living on 2.2 style config directly
3. Conclusion
Section 1 described that the only application of 'decorator'
pattern in avalon that I see is a configuration preprocessing
stage.
However as section 2 says I see little or no point to
duplicate component configuration, it looks better to me to have
one component and lookup multiple instances of it.
Then secion 2 proseeded to give two variants for the
<stage> application configuration that I can imagine:
variants 2.1 and 2.2. (2.2 actually expands 2.1)
Variant 2.1 actually looks simpler to me and something that
might easily be implemented.
2.2 adds syntactic beautification and can either be preprocessed
to 2.1 (the easy way, 2.2.1) or used directly (the hard way, 2.2.2)
============
David, did I think along your lines, or did I get completely aside?
DB> // generate sub-queue by clone a prototype (design pattern) queue
DB> public class QueueCompositeM implements Queue {
DB> ...
DB> }
DB> <stage>
DB> <queue class="QueueCompositeM">
DB> <prototype class="QueueImplA"/>
DB> </queue>
DB> </stage>
DB> or
DB> <stage>
DB> <queue class="QueueCompositeM">
DB> <prototype class="QueueDecoratorX">
DB> <queue class="QueueImplA"/>
DB> </prototype>
DB> </queue>
DB> </stage>
DB> or ...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
