At 08:31 17/4/01 -0400, Berin Loritsch wrote:
>I could have sworn I got rid of the Cocoon specificity. You have a role
>manager that takes care of the named configurations, etc.
Right but it still uses Cocoons config format ;)
>Ok. Move it to Excalibur. The Component framework that is there now in
Avalon,
>shouldn't even mention Cocoon, and it takes care of alot of lifecycle issues
>for you. Personally, I'd like to see more of you using it. They were moved
>into Avalon, because they were written in a manner where they could be used
>in any project. The move was to give people a more pleasant experience in
>programming for Avalon--not just Cocoon.
will do.
>Besides, What's wrong with using the new framework? You can add regular
>components and it acts like the previous ComponentManager, or it can
>create Components on demand. It depends on what you want to do with it.
>It's flexible enough to let it be dumb or smart.
It is about 10 times more complex than the previous Map based
implementations. It required the presence of the Pooling code (ie a
component and not part of framework). It was overkill for most simple
cases. For bigger systems (ie Cocoon2 and possible Phoenix in future) it
makes sense to use it but lets keep it simple to start with.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
