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]>
