avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Date Mon, 24 Jun 2002 19:30:49 GMT
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:stefano@apache.org] 
> 
> 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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message