I have a use case (from previous work I did in a non-avalon framework)
that I'm not sure how to reconcile with the current metadata/lookup()
proposal...
basically there are two issues:
1. multiple components coming from the same class (with different configuration).
2. passing role names into a component via configuration.
The situation is that I have a controller, that controls multiple units
(so that they can work together) -- the number of units it controls (and
how they work) is specified in the controller's configuration. The units
are generally all going to be of the same class but with different
configuration (e.g. different ports).
so I will have something like:
<component id="unit1" class="UnitImpl">
<!-- unit1 configuration -->
</component>
<component id="unit2" class"UnitImpl">
<!-- unit2 configuration -->
</component>
<!-- ... -->
<component id="controller" class="UnitController">
<!--
...
<unit name="unit1"/>
<unit name="unit2"/>
...
-->
</component>
(This is perhaps not too dissimilar in concept to a cocoon sitemap).
In an ideal situation I'd like the controller to be able to do something
like:
unit[i] = (Unit) lookup( unitNames[i] );
where unitNames[] comes from the configuration and is something like
{ "unit1", "unit2" /* ... */ }
It is impossible for the controller to declare these dependencies in
metadata - since they aren't known until assemble time.
Now I don't fully understand how the current metadata proposal governs
component resolution, but I get the impression that I can't write the
above in a container independent way (and hence not in a reusable way)...
I could probably use a Selector (e.g. lookup("unit-selector")), but then
the Selector would have to be container specific for the same reasons.
The reason I'm not sure that this will work is that when I look over the
emails regarding metadata/lookup() it seems that the job of the assembler,
as far as determining a mapping from role names to components, is absent
-- maybe it was just assumed (and not explicitly mentioned).
What I'm looking for is some assurance the the job of the assembler isn't
going to be replaced by metadata.
Am I misunderstanding something about the metadata/lookup() proposal? is
it possible to write such a beast in a container independent way?
- or -
is 'controller' really a block (or the controller+units a single big
component)? And it should embed Fortress (or another container), and take
in all the configuration for the units as well as it's own configuration?
Robert.
On Mon, 24 Jun 2002, Berin Loritsch wrote:
> Date: Mon, 24 Jun 2002 15:30:49 -0400
> From: Berin Loritsch <[EMAIL PROTECTED]>
> Reply-To: Avalon Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: 'Avalon Developers List' <[EMAIL PROTECTED]>
> Subject: Fresh Outlook: (was RE: [desperate plea] RE: The need for
> 'hints')
>
> While Stefano has some important points, we do have to bring practice
> into view. An abstraction without foundation in reality is doomed to
> failure. So let's look at this pragmatically.
>
> > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> >
> > Ok, this said, let's move on. I see two different ways of
> > looking for a
> > component:
> >
> > 1) I need something that does this.
> >
> > 2) I need something that does this, and should work in this context
> >
> > Two real life examples:
> >
> > 1)
> > composer: I need a component that implements 'screwdriver'
> > componentManager: here it is
> >
> > 2)
> > composer: I need a component that implements 'screwdriver'
> > and I'll use it on screws of 3 mm of diameter.
> > componentManager: here it is
> >
> > It has been suggested that the working context is just
> > another information you pass in the role, so, in our
> > examples, we would have an inflation of roles for each
> > screwdriver and each possible screw size or size ranges.
> >
> > Please, tell me, am I the only one who doesn't get a good
> > feeling out of this?
>
> In the hardware realm for ordinary household projects, you
> only have to worry about three basic sizes of screwdrivers
> and two different types. There are Philips head and Flat
> head screwdrivers. They come in three sizes (#1, #2, #3).
> For 90% of woodworking projects you use a Philips #2. For 90%
> of electrical projects you use a Flathead #2 (or #1).
>
> The bottom line is that while there are many different
> possibilities of roles, only a couple are really necessary in
> a system.
>
> For projects like Cocoon where the Sitemap is not only the
> container for its components, but it also chooses the
> component necessary for the job, it is really better for the
> Sitemap container to choose the component in a Cocoon specific
> way.
>
> What you are accusing Peter and company of doing is not really
> any different than what Cocoon does. The lookup might change
> from Generator.ROLE, "hint" to Generator.ROLE + "/constraint",
> but the general outcome is the same. There is *essentially*
> ten different roles if we are being true to what it conceptually
> is.
>
> To the pipeline, A generator is a generator is a generator.
> To the sitemap, we may have ten different implementations that
> we choose from. The *sitemap* chooses which of those 10
> generators are used depending on context. Because it is a
> container in and of itself, it can do so in any way it chooses.
> Effectively each individual Generator performs a different role.
> One pulls info from the filesystem, another pulls it from an
> external site, and yet another will pull it from a database.
> The pipeline doesn't care, but the pipeline doesn't (or shouldn't)
> directly request the generator. The sitemap sets the generator.
>
> So for real practicality's sake, we either have a distinct
> role for each of the Generators or we have a smart container.
>
> Think of it in terms of the Chorus in a theatrical play. They
> act as one, but they have their own part to play in the harmony
> or narration of the play. There might be three distinct people
> on the stage at one time that perform the same general function.
> It is the same with the concept of generators in Cocoon.
>
> Please tell me if I have confused you more than I have clarified
> things.
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
