You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/04/26 14:43:00 UTC
Configuration of TreeBuilder
Hi,
currently the TreeBuilderSelector is not a real Avalon Component,
it is configured in an XML file called "treeprocessor-builtins.xml".
Can we make a real avalon component out of this and move the
configuration into the cocoon.xconf?
I think this would reduce the code of the treeprocessor in some
areas and make the configuration more consistent with the
configuration of other components.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.s-und-n.de mailto: cziegeler@s-und-n.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Configuration of TreeBuilder
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Bert Van Kets" <be...@vankets.com>
> <snip/>
> But I hear very often complains about too many configuration files for
> >Cocoon (web.xml, logkit.xconf, cocoon.xconf, sitemap.xmap etc). By
> >segmenting
> >this further, we will get a smaller cocoon.xconf, but it will not get
> >less complicated, I fear.
>
> My thoughts exactly. The information needs to stored somewhere, no?
Well, yes.
But one thing is configuration for the core developers, another is for
users.
Why would a normal Cocoon user need to see and possibly muck with the
treeprocessor configuration?
I would keep user-editable config where it is, but put a link to an external
file for the Cocoon-dev related configuration.r
> >Using an XML editor (or a tool) for the cocoon.xconf makes the usage in
> >my eyes much easier than splitting it into many parts. With an XML editor
> >you can for example only display the top-level component nodes and simply
> >select the component you want to change. So, it's still very simple. If
> >you have several files, nearly all tools fail.
> <snip/>
>
> Why not add a cocoon.xconf editing tool. This way the user/developer
would
> not need an XML editor to configure Cocoon. There's almost a sitemap
> editing tool.
> Most applications have a configuration interface to set it up. I guess
> Cocoon has become so big that it is very much in need of this. I'd write
> it myself, but I don't have any free time for the coming months, sorry.
Gee, you shouldn't come up with these ideas, guys.
I love these GUI thingies ;-)
Ok, let's se what I can come up with for a Cocoon Console :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Configuration of TreeBuilder
Posted by Bert Van Kets <be...@vankets.com>.
<snip/>
But I hear very often complains about too many configuration files for
>Cocoon (web.xml, logkit.xconf, cocoon.xconf, sitemap.xmap etc). By
>segmenting
>this further, we will get a smaller cocoon.xconf, but it will not get
>less complicated, I fear.
My thoughts exactly. The information needs to stored somewhere, no?
>Using an XML editor (or a tool) for the cocoon.xconf makes the usage in
>my eyes much easier than splitting it into many parts. With an XML editor
>you can for example only display the top-level component nodes and simply
>select the component you want to change. So, it's still very simple. If
>you have several files, nearly all tools fail.
<snip/>
Why not add a cocoon.xconf editing tool. This way the user/developer would
not need an XML editor to configure Cocoon. There's almost a sitemap
editing tool.
Most applications have a configuration interface to set it up. I guess
Cocoon has become so big that it is very much in need of this. I'd write
it myself, but I don't have any free time for the coming months, sorry.
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Configuration of TreeBuilder
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> Sylvain Wallez wrote:
> >
> >
> > What about using XInclude, which, through XPointer, would allow to
> > insert in cocoon.xconf elements from an external file that would contain
> > only those parts that we allow the sysadmin to change ?
> >
> > I already used this in Cocoon1 days to insert configuration values from
> > a central application config file inside XSP pages, and it worked like a
> > charm !
> >
> I totally agree, that the cocoon.xconf is too big, no doubt.
>
> But I hear very often complains about too many configuration files for
> Cocoon (web.xml, logkit.xconf, cocoon.xconf, sitemap.xmap etc). By
> segmenting
> this further, we will get a smaller cocoon.xconf, but it will not get
> less complicated, I fear.
I agree. Look at what happened for Apache HTTPD: they started with
httpd.conf, then became too big and had other two files, then people
didn't understand where the directives went, so they allowed directives
to go everywhere, then they glued everything back into one big
httpd.conf
I don't think that cocoon.xconf is too big: it's just too messy. I mean,
there are several different level of configurations there and some (like
the default XSP taglibs) cannot be considered configurations if they are
a contract that people assume when they use XSP.
(the same could be said for the sitemap component configuration in the
root sitemap.xmap).
This is the problem with heavily component-based architectures:
programmability and configuration have a very thin line.
> Using an XML editor (or a tool) for the cocoon.xconf makes the usage in
> my eyes much easier than splitting it into many parts. With an XML editor
> you can for example only display the top-level component nodes and simply
> select the component you want to change. So, it's still very simple. If
> you have several files, nearly all tools fail.
>
> And the configuration is "maintained" by Avalon, so if we decide to build
> a solution this should rather happend in Avalon than in Cocoon.
If Cocoon Blocks contain their own configurations, wouldn't that solve
the issues?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Configuration of TreeBuilder
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
>
> What about using XInclude, which, through XPointer, would allow to
> insert in cocoon.xconf elements from an external file that would contain
> only those parts that we allow the sysadmin to change ?
>
> I already used this in Cocoon1 days to insert configuration values from
> a central application config file inside XSP pages, and it worked like a
> charm !
>
I totally agree, that the cocoon.xconf is too big, no doubt.
But I hear very often complains about too many configuration files for
Cocoon (web.xml, logkit.xconf, cocoon.xconf, sitemap.xmap etc). By
segmenting
this further, we will get a smaller cocoon.xconf, but it will not get
less complicated, I fear.
Using an XML editor (or a tool) for the cocoon.xconf makes the usage in
my eyes much easier than splitting it into many parts. With an XML editor
you can for example only display the top-level component nodes and simply
select the component you want to change. So, it's still very simple. If
you have several files, nearly all tools fail.
And the configuration is "maintained" by Avalon, so if we decide to build
a solution this should rather happend in Avalon than in Cocoon.
Cheers
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.s-und-n.de mailto: cziegeler@s-und-n.de
The new weblog homepage: http://ziegeler.bei.t-online.de
================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Configuration of TreeBuilder
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>From: "Carsten Ziegeler" <cz...@s-und-n.de>
>
>>Sylvain Wallez wrote:
>>
>>>Nevertheless, the treeprocessor allows to name an alternate
>>>configuration file using the "config" attribute recently added by
>>>Ovidiu. If you want to, we can also allow the full treeprocessor
>>>configuration to be present in cocoon.xconf.
>>>
>>Yes, I still feel that we should remove this attribute and put
>>everything in the cocoon.xconf as I want to have on single point
>>of configuration for components.
>>
>>What do others think?
>>
>
>I think that cocoon.xconf is becoming a bit too big to be easily managed.
>
Agree. And it contains lots of configuration items that the average user
should not have to change.
A lot of components have default configurations hard-coded in their
source files. For the treeprocessor, having this default written in Java
code would be a PITA, hence the "treeprocessor-builtins.xml" file.
I'm going to update TreeProcessor.configure() so it is more consitent
with the usual behaviour : if a configuration is given in cocoon.xconf,
use it, else use the defaults defined by treeprocessor-builtins.xml. But
I still want the possibility of naming a separate config file (see also
below).
>IMHO it should get separated in different config files, and to prevent
>single Components to devise their own Configuration scheme, there should be
>a standard way of doing it.
>
>Maybe a mount-config element or a standard config="" attribute could do the
>trick.
>
I like this.
What about using XInclude, which, through XPointer, would allow to
insert in cocoon.xconf elements from an external file that would contain
only those parts that we allow the sysadmin to change ?
I already used this in Cocoon1 days to insert configuration values from
a central application config file inside XSP pages, and it worked like a
charm !
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Configuration of TreeBuilder
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Carsten Ziegeler" <cz...@s-und-n.de>
>
> Sylvain Wallez wrote:
> >
> > Nevertheless, the treeprocessor allows to name an alternate
> > configuration file using the "config" attribute recently added by
> > Ovidiu. If you want to, we can also allow the full treeprocessor
> > configuration to be present in cocoon.xconf.
> >
>
> Yes, I still feel that we should remove this attribute and put
> everything in the cocoon.xconf as I want to have on single point
> of configuration for components.
>
> What do others think?
I think that cocoon.xconf is becoming a bit too big to be easily managed.
IMHO it should get separated in different config files, and to prevent
single Components to devise their own Configuration scheme, there should be
a standard way of doing it.
Maybe a mount-config element or a standard config="" attribute could do the
trick.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Configuration of TreeBuilder
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >Hi,
> >
> >currently the TreeBuilderSelector is not a real Avalon Component,
> >it is configured in an XML file called "treeprocessor-builtins.xml".
> >
>
> <picky-mode>
> What makes it not a real Avalon component that its class name is
> hardcoded in TreeProcessor, not that its configuration isn't in
> cocoon.xconf. Now is there a real need to have an alternate
> implementation for this basic selector ?
> </picky-mode>
>
Hm, I see one major difference: the TreeProcessor has to implement
all life-cycle interfaces to get all information only to instantiate
later on the selector. In my eyes this should not be the concern
of the TreeProcessor.
> >Can we make a real avalon component out of this and move the
> >configuration into the cocoon.xconf?
> >I think this would reduce the code of the treeprocessor in some
> >areas and make the configuration more consistent with the
> >configuration of other components.
> >
>
> The configuration of the pipeline languages is in a separate file
> because designing/modifying a pipeline language is not a common task and
> IMO doesn't belong to the usual system-assembly tasks handled by
> cocoon.xconf. Also, I think adding these 160 lines of declarations won't
> help frightened newbies to understand the big picture.
>
Ok, yes, this is right. But on the other hand there are many configurations
in the cocoon.xconf which are absolutely not relevant for newbies
and we don't want to create separate configurations files for these
components only to make the cocoon.xconf smaller/simpler.
> Nevertheless, the treeprocessor allows to name an alternate
> configuration file using the "config" attribute recently added by
> Ovidiu. If you want to, we can also allow the full treeprocessor
> configuration to be present in cocoon.xconf.
>
Yes, I still feel that we should remove this attribute and put
everything in the cocoon.xconf as I want to have on single point
of configuration for components.
What do others think?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Configuration of TreeBuilder
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Hi,
>
>currently the TreeBuilderSelector is not a real Avalon Component,
>it is configured in an XML file called "treeprocessor-builtins.xml".
>
<picky-mode>
What makes it not a real Avalon component that its class name is
hardcoded in TreeProcessor, not that its configuration isn't in
cocoon.xconf. Now is there a real need to have an alternate
implementation for this basic selector ?
</picky-mode>
>Can we make a real avalon component out of this and move the
>configuration into the cocoon.xconf?
>I think this would reduce the code of the treeprocessor in some
>areas and make the configuration more consistent with the
>configuration of other components.
>
The configuration of the pipeline languages is in a separate file
because designing/modifying a pipeline language is not a common task and
IMO doesn't belong to the usual system-assembly tasks handled by
cocoon.xconf. Also, I think adding these 160 lines of declarations won't
help frightened newbies to understand the big picture.
Nevertheless, the treeprocessor allows to name an alternate
configuration file using the "config" attribute recently added by
Ovidiu. If you want to, we can also allow the full treeprocessor
configuration to be present in cocoon.xconf.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org