avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: RoleManager et al
Date Tue, 17 Apr 2001 15:01:00 GMT
Peter Donald wrote:
> 
> 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 ;)

It's a pretty generic format.

<component role="rolename" class="classname">
  <!-- all elements here are passed to the component -->
</component>

Or for selected components:

<component role="roleSelector" class="Selector">
  <component-instance name="instancename" class="classname">
    <!-- all elements here are passed to the component -->
  </component-instance>
</component>

In order to customize it, you can either have a separate roles config file,
or embed it in the same file (I prefer separating):

<role shorthand="foo" role="rolename" class="classname"/>
<foo>
  <!-- all elements here are passed to the component -->
</foo>

Or for selected components:

<role shorthand="foo" role="roleSelector" default-class="Selector">
    <hint shorthand="bar" default-class="classname"/>
</role>

<foo>
  <bar name="instancename">
    <!-- all elements here are passed to the component -->
  </bar>
</foo>

Plus it automatically handles whether the components are Poolable,
etc.

> >Ok. Move it to Excalibur.
> 
> will do.

Cool Beans!

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

Ok.  Point taken.  Complexity is encapsulated, so it is less for the user
of the framework to explicitly handle--but it is overkill in many situations.

Both are valid approaches, so we should have them both.

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message