On Mon, 26 Nov 2001 01:32, Uli Mayring wrote: > I was planning something like that for a long time, too. When I asked on > cocoon-dev about the way to go the relevant people said that I should > take care to not violate IoC and to not deconstruct Cocoon in a way that > would make it unrecognizable as a project of its own.
I don't think that was it. I think the idea was don't change Cocoon into something it is currently not and still call it Cocoon. I don't think there would be too much hubub if you created a new product that fit with your goals but didn't call it cocoon. You could call it something like "Butterfly, grown out of Cocoon" or something if you really wanted ;) > The majority of people, who spoke out on this issue, thought that I should > not call a Cocoon component from my other components, but that I should > have Cocoon call my other components. This is to preserve IoC, a > "Cocoon block" would violate it, as it can be called from outside. A Cocoon block would not necessarily break IOC. Essentially Cocoon is architectured with a single container which contains a master controller. The master controller being the Sitemap. If you wanted alternative control mechanisms then I suspect you could replace the sitemap object. I am not sure how feasible this is at this stage (oe even if it is possible) but that is one way you could write your own control portion of the app. The cocoon people may even be receptive to that ;) -- Cheers, Pete -------------------------------------------------- Logic: The art of being wrong with confidence... -------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
