Unico Hommes wrote: > > This means we need to overide Fortress' default way of configuring the > container. Because by default it looks for an 'id' attribute as you > mention below. If a component is not declared in the containter > configuration with an id attribute it is not configured with an id > attribute it isn't available. > > > This issue is something I encountered today while trying to > > get the global input module running. Adding the > > global-variables component in the cocoon.roles file wasn't > > enough. I also had to add a <global-variables > > id="global-variables"/> to the cocoon.xconf as well which > > imho is not very good. > > > > No I don't like this either. If you only intend to have one component of > a certain type you shouldn't have to give it an id. As for not declaring > a component in cocoon.xconf at all, that would be more difficult. > Because there is currently no way in Fortress to ask for component meta > info given a role string. I guess because there could be multiple > choices. > > > In general, I think we should stick to the 2.1 syntax of > > cocoon.xconf for compatibility reasons and not introduce more > > complexity. I personally don't know what this line > > <global-variables id="global-variables"/> actually does and > > why the entry in the cocoon.roles is not sufficient. > > Take a look at AbstractContainer.configure() . That's where the > container configuration gets parsed and the components are added > accordingly. > Thanks for the info, Unico.
Now, I'm a little bit disappointed as I thought that Fortress is compatible to ECM - it seems that there is a lot more work to do then we suspected :( Carsten
