cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject [C2] Ease of Use for cocoon.xconf (long)
Date Wed, 17 Jan 2001 17:16:14 GMT
I put code into Cocoon that allows us to use aliases for the component
element.  It also allows us to identify default classes.  This processing
is done in addition to the traditional format--and allows us to be
creative in how we implement it.

We have three ways of specifying the same thing (as long as the corresponding
entries are in Roles.java and RoleUtils.jave:

<component role="org.apache.cocoon.components.datasource.DataSourceComponentSelector"
            class="org.apache.cocoon.CocoonComponentSelector">
   <component-instance name="personnel" class="org.apache.cocoon.components.datasource.J2eeDataSource">
     <dbname>foo</dbname>
   </component-instance>
</component>

<component type="datasources" class="org.apache.cocoon.CocoonComponentSelector">
   <component-instance name="personnel" class="org.apache.cocoon.components.datasource.J2eeDataSource">
     <dbname>foo</dbname>
   </component-instance>
</component>

<datasources class="org.apache.cocoon.CocoonComponentSelector">
   <component-instance name="personnel" class="org.apache.cocoon.components.datasource.J2eeDataSource">
     <dbname>foo</dbname>
   </component-instance>
</datasources>

<datasources>
   <component-instance name="personnel" class="org.apache.cocoon.components.datasource.J2eeDataSource">
     <dbname>foo</dbname>
   </component-instance>
</datasources>

All of these things describe the same thing.  In fact, the class entry doesn't need to be
included
bacause there is a registered default class for the role--although if a different class were
defined
in the class attribute it will be used.

You have a choice of using the role attribute, the type attribute or the alias element.  The
role
attribute acts as it originally did.  (so you can create new components with new roles, and
use them
in XSP).  The type attribute and the alias element work the same way, and require you to register
them with RoleUtils.java (in the static initializer).  It just performs a RoleUtils.lookup(alias)
to get the role name.

The consequence of this is that there are some items that don't need to be specified in cocoon.xconf
and everything _still_works_.  For example, the PoolController has a registered default class.
 If
the DefaultComponentManager doesn't have an entry for the PoolController by its role, it checks
RoleUtils for a default class.  If there is a default class, then it will instantiate the
object
and return it.  Try it, it's fun.


Mime
View raw message