Stephen McConnell wrote:
>
>From the Cocoon CVS:
>
> <xroles xpath="/role-list"
> unless="[EMAIL PROTECTED]'org.apache.cocoon.webapps.portal.component
> s.PortalManager']">
> <role
> name="org.apache.cocoon.webapps.portal.components.PortalManager"
> shorthand="portal-manager"
> default-class="org.apache.cocoon.webapps.portal.components.Por
talManagerImpl"/>
> </xroles>
>
> Some questions:
>
> 1. is there a formal specification of the <xroles> element somewhere?
> 2. presumably the "xpath" attribute combined with the
> "unless" attribute represent a precondition to service
> selection - it that correct?
The above is not the cocoon roles file but a "patch" file that is merged
into the cocoon roles file. The format of the roles file is:
<?xml version="1.0"?>
<!DOCTYPE role-list [
<!ELEMENT role-list (role+)>
<!ELEMENT role (hint*)>
<!ELEMENT hint EMPTY>
<!ATTLIST role name CDATA #REQUIRED
shorthand CDATA #REQUIRED
default-class CDATA #IMPLIED
>
<!ATTLIST hint shorthand CDATA #REQUIRED
class CDATA #REQUIRED
>
]>
You find this file in src/java/org/apache/cocoon with the name cocoon.roles.
So the above is a file that is picked up by the build system and merged
into the cocoon.roles. It first tests if the fragment has already been
inserted etc.
> 3. the <role> element represents a request for a service and
> the service interface is declared under the name attribute
Yes.
> 4. the <role> shorthand attribute is a pointer into a config
> file for the component configuration
Yes, you can use either the role name or the shorthand to configure
the service.
> 5. default-class
> attribute identifies a class, but it's name implies that is
> not necessarily what is returned
>
Yes, this is the default implementation and can be overwritten
in the central configuration file (using the shorthand again)
> Some observations:
>
> The above looks to me like the declaration of two things
> mixed together.
>
> 1. Firstly there is the expression of a requirement for
> a service using a model that enables conditional
> expressions.
>
> 2. Secondly the role element appears to be mapping a
> candidate service to a candidate implementation class
> together with a configuration reference
>
> Some initial thoughts:
>
> The above approach simply does not translate to the logic
> used in Merlin. Under Merlin you would do something like:
>
> <component name="portal-manager"
> class="org.apache.cocoon....PortalManagerImpl">
> <configuration>
> <!-- whatever is in the config file with an
> element named shorthand -->
> </configuration>
> </component>
>
> But this is kind of academic because in Merlin is you request
> a service Merlin will auto-locate it for you using meta info.
> So what we can do is go back to the original declaration and
> try to separate the request and solution information. I've
> left out the "unless" clause because (a) I don't know what
> the expression means, and (b) it smells of implementation
> specifics (but we can revisit that). Here is a configuration
> fragment that seems to me to reflect the same thing:
>
> <xroles xpath="/role-list">
> <select>portal-manager</select>
> </xroles>
>
> So moving on - how does the above fragment relate to merlin.
> Currently in merlin you can select a component that will
> provide a service by referencing its address. The address is
> simply a sequence of container names ending with the
> component name - e.g. /xxx/yyy/my-component.
> However, that is not sufficient for what you want to to here.
> You need to be able to establish a component that is doing
> query resolution based on a supplied configuration argument
> (assuming I'm interpreting this correctly).
>
> For example:
>
> <component name="xpath"
> class="org.apache.cocoon....XPathProcessor"/>
>
> The XpathProcessor component would be responsible for
> evaluating the xpath expression and interacting with the
> container model to select the appropriate component model and
> return a service instance from that model.
>
> Am I on the right track here?
I think: no :) Actually, I see no real difference (but perhaps
I'm wrong as well).
With ECM
you split the configuration into two parts: the roles definition
in a separate file: this defines all the available components
or services.
And the configuration of each component (using the shorthand)
in another file.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
