You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/12/29 21:51:22 UTC
Splitting cocoon.xconf: done
Hi all,
I just committed the new feature that allows cocoon.xconf to be split
into small parts. There is a new <include src=""/> statement that
includes either a roles file or a xconf file. A minimal sourceresolver
is setup at cocoon boot time that provides the "resource:" and
"context:" protocols to fetch files (relative files are equivalent to
"context:").
This allow the main cocoon.xconf file to be a list of includes of the
main core components and block-provided xconf files, each including its
specific roles when needed.
For this to be really useful, I refactored ECM++ so that a component
selector can be declared several times. Each block can then easily
provide its own source factories, input modules, taglibs, etc.
The only remaining problem is XSP because some blocks provide
logicsheets that aren't handled by a selector and therefore require the
use of xpatch to inject the logicsheet declaration at the right place.
This new feature allows to very easily activate/deactivate blocks (just
comment or remove the corresponding <include>) and add user-provided
components without having to mix them with the cocoon-provided ones.
This may also allow us to provide again binary distributions, which will
make it easier for newcomers.
The include feature is also available in the sitemap, but more work is
needed there as labels and mime-types are ignored in included files.
Enjoy,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Yep: have each xconf include its dependencies.
> CocoonServiceManager.doConfigure() takes care of not including a file
> more than once, so this allows the order to define itself naturally.
>
Yes, that would work. It's not the best solution as you have to
specify the dependencies in the conf file, but I think we can live with
that as it's a very easy implementation.
Thanks,
Carsten
Re: Splitting cocoon.xconf: done
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> I just started with the initial implementation for including all
> files in a directory and ..ahem.. it's not that easy :(
> Sure, including all files in a directory *is* easy, but we
> have dependencies between blocks and therefore between
> the configuration files.
> This means they have to be included in the right order.
> I fear the best way would be to do a lazy configuration, which
> means starting with the actual configuration after all
> files have been included and resolve dependencies...
>
> Any ideas?
Yep: have each xconf include its dependencies.
CocoonServiceManager.doConfigure() takes care of not including a file
more than once, so this allows the order to define itself naturally.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Carsten Ziegeler <cz...@apache.org>.
I just started with the initial implementation for including all
files in a directory and ..ahem.. it's not that easy :(
Sure, including all files in a directory *is* easy, but we
have dependencies between blocks and therefore between
the configuration files.
This means they have to be included in the right order.
I fear the best way would be to do a lazy configuration, which
means starting with the actual configuration after all
files have been included and resolve dependencies...
Any ideas?
Carsten
Re: Splitting cocoon.xconf: done
Posted by Carsten Ziegeler <cz...@apache.org>.
Marc Portier wrote:
>>>
>> I think it's possible (but perhaps I'm wrong); I read the spec last week
>> and I found something that should work in a war file as well. I will
>> look into it and try to add this new feature in the next days.
>>
>
> sounds like a sure way to earn another beer!
>
:) I hear your!
Carsten
Re: Splitting cocoon.xconf: done
Posted by Marc Portier <mp...@outerthought.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Marc Portier wrote:
>>
>>> way to go, mate!
>>>
>>> just one question: from memory I recall the suggestion during the
>>> discussion for doing the automagical xconf/*.xconf include
>>>
>>> I'm guessing this is not in there as of now?
>>
>>
>>
>>
>> No, it's not there currently.
>>
>> It could be done of course, but I'm not sure this is such a good idea,
>> as it prevents packaging Cocoon as a war file (AFAIK, we cannot
>> explore the contents of "directories" in a war file).
>>
> I think it's possible (but perhaps I'm wrong); I read the spec last week
> and I found something that should work in a war file as well. I will
> look into it and try to add this new feature in the next days.
>
sounds like a sure way to earn another beer!
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: Splitting cocoon.xconf: done
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> I think it's possible (but perhaps I'm wrong); I read the spec last week
>> and I found something that should work in a war file as well. I will
>> look into it and try to add this new feature in the next days.
>
>
>
> Are you talking about ServletContext.getResourcePaths() [1]? That could
> do the job, but maybe requires the implementation of a new special
> SourceFactory (producing TraversableSources). That would be very useful
> for using the TraversableGenerator within war files!
>
Yes, that was it, thanks - I couldn't remember anymore (you know,
christmas was inbetween...) and yes, I planned to make a TraversableSource.
Carsten
Re: Splitting cocoon.xconf: done
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Marc Portier wrote:
>>
>>> way to go, mate!
>>>
>>> just one question: from memory I recall the suggestion during the
>>> discussion for doing the automagical xconf/*.xconf include
>>>
>>> I'm guessing this is not in there as of now?
>>
>>
>>
>> No, it's not there currently.
>>
>> It could be done of course, but I'm not sure this is such a good
>> idea, as it prevents packaging Cocoon as a war file (AFAIK, we cannot
>> explore the contents of "directories" in a war file).
>
>
> I think it's possible (but perhaps I'm wrong); I read the spec last week
> and I found something that should work in a war file as well. I will
> look into it and try to add this new feature in the next days.
Are you talking about ServletContext.getResourcePaths() [1]? That could
do the job, but maybe requires the implementation of a new special
SourceFactory (producing TraversableSources). That would be very useful
for using the TraversableGenerator within war files!
Sylvain
[1]
http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletContext.html#getResourcePaths(java.lang.String)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Marc Portier wrote:
>
>> way to go, mate!
>>
>> just one question: from memory I recall the suggestion during the
>> discussion for doing the automagical xconf/*.xconf include
>>
>> I'm guessing this is not in there as of now?
>
>
>
> No, it's not there currently.
>
> It could be done of course, but I'm not sure this is such a good idea,
> as it prevents packaging Cocoon as a war file (AFAIK, we cannot explore
> the contents of "directories" in a war file).
>
I think it's possible (but perhaps I'm wrong); I read the spec last week
and I found something that should work in a war file as well. I will
look into it and try to add this new feature in the next days.
Carsten
Re: Splitting cocoon.xconf: done
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
> way to go, mate!
>
> just one question: from memory I recall the suggestion during the
> discussion for doing the automagical xconf/*.xconf include
>
> I'm guessing this is not in there as of now?
No, it's not there currently.
It could be done of course, but I'm not sure this is such a good idea,
as it prevents packaging Cocoon as a war file (AFAIK, we cannot explore
the contents of "directories" in a war file).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Marc Portier <mp...@outerthought.org>.
way to go, mate!
just one question: from memory I recall the suggestion during the
discussion for doing the automagical xconf/*.xconf include
I'm guessing this is not in there as of now?
regards,
-marc=
Sylvain Wallez wrote:
> Hi all,
>
> I just committed the new feature that allows cocoon.xconf to be split
> into small parts. There is a new <include src=""/> statement that
> includes either a roles file or a xconf file. A minimal sourceresolver
> is setup at cocoon boot time that provides the "resource:" and
> "context:" protocols to fetch files (relative files are equivalent to
> "context:").
>
> This allow the main cocoon.xconf file to be a list of includes of the
> main core components and block-provided xconf files, each including its
> specific roles when needed.
>
> For this to be really useful, I refactored ECM++ so that a component
> selector can be declared several times. Each block can then easily
> provide its own source factories, input modules, taglibs, etc.
>
> The only remaining problem is XSP because some blocks provide
> logicsheets that aren't handled by a selector and therefore require the
> use of xpatch to inject the logicsheet declaration at the right place.
>
> This new feature allows to very easily activate/deactivate blocks (just
> comment or remove the corresponding <include>) and add user-provided
> components without having to mix them with the cocoon-provided ones.
> This may also allow us to provide again binary distributions, which will
> make it easier for newcomers.
>
> The include feature is also available in the sitemap, but more work is
> needed there as labels and mime-types are ignored in included files.
>
> Enjoy,
> Sylvain
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: Splitting cocoon.xconf: done
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
>
> Now I never changed the default setting for the root sitemap... Does it
> affect relative sources in the root sitemap also?
Now this question will torture you for a while :-)
I don't know - but if it is configurable, it should work - if it does not, it is
bug...
Vadim
Re: Splitting cocoon.xconf: done
Posted by Sylvain Wallez <sy...@apache.org>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>>
>> I see a misunderstanding: "context" (or "local context") is not to be
>> confused with "root context". When loading the root cocoon.xconf, the
>> local context is the root context. When loading a sitemap, the local
>> context is the sitemap location and any <include> in <map:component>
>> will use that local context.
>>
>> So, to summarize, <include> uses the local context (either root
>> context or sitemap location), but not the configuration file's location.
>>
>> How does that sound to a dumb user? ;-)
>
>
> Is "root context" here is a webapp context root ('/'), or is it
> location of the root sitemap (<sitemap
> file="/path/to/my/root/sitemap.xmap" logger="sitemap"/>)?
>
> So does it resolve relative to "/" or relative to root sitemap?
The root service manager resolves relatively to the webapp context root,
and not to the location of the root sitemap (because the root SM loads
the component that defines this sitemap).
Now I never changed the default setting for the root sitemap... Does it
affect relative sources in the root sitemap also?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
>
> I see a misunderstanding: "context" (or "local context") is not to be
> confused with "root context". When loading the root cocoon.xconf, the
> local context is the root context. When loading a sitemap, the local
> context is the sitemap location and any <include> in <map:component>
> will use that local context.
>
> So, to summarize, <include> uses the local context (either root context
> or sitemap location), but not the configuration file's location.
>
> How does that sound to a dumb user? ;-)
Is "root context" here is a webapp context root ('/'), or is it location of the
root sitemap (<sitemap file="/path/to/my/root/sitemap.xmap" logger="sitemap"/>)?
So does it resolve relative to "/" or relative to root sitemap?
Vadim
Re: Changed relative context in xconf includes (was Re: Splitting
cocoon.xconf: done)
Posted by Carsten Ziegeler <cz...@apache.org>.
>
> Ok, according all this feedback, I changed the resolving of relative
> URIs: they are now resolved relatively to the file that does the import.
> And I admit this definitely looks more natural ;-)
>
Thanks!
Carsten
Changed relative context in xconf includes (was Re: Splitting cocoon.xconf:
done)
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
> Reinhard Poetz wrote:
>
>> Sylvain Wallez wrote:
>>
>>> I understand this. Maybe my "overall consistency" point of view is
>>> too much and we should handle it more "naturally"? What do people
>>> think?
>>
>>
>> Without thinking to much and too long, I agree with Carsten. I expect
>> imported files relativ to where I import them.
>
>
> Me too.
Ok, according all this feedback, I changed the resolving of relative
URIs: they are now resolved relatively to the file that does the import.
And I admit this definitely looks more natural ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>> I understand this. Maybe my "overall consistency" point of view is
>> too much and we should handle it more "naturally"? What do people think?
>
>
> Without thinking to much and too long, I agree with Carsten. I expect
> imported files relativ to where I import them.
>
Me too.
Ralph
Re: Splitting cocoon.xconf: done
Posted by Reinhard Poetz <re...@yahoo.de>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>> I see a misunderstanding: "context" (or "local context") is not to be
>>> confused with "root context". When loading the root cocoon.xconf, the
>>> local context is the root context. When loading a sitemap, the local
>>> context is the sitemap location and any <include> in <map:component>
>>> will use that local context.
>>>
>>> So, to summarize, <include> uses the local context (either root
>>> context or sitemap location), but not the configuration file's location.
>>>
>>> How does that sound to a dumb user? ;-)
>>>
>> Hmmm, I'm too dumb to find a good answer :)
>> Seriously, I think we can go with this - although it would be easier to
>> understand if the include in the xconf would be relative to the xconf;
>> Your argumentation is correct, but I guess we will have to explain
>> this to users several times.
>
>
>
> I understand this. Maybe my "overall consistency" point of view is too
> much and we should handle it more "naturally"? What do people think?
Without thinking to much and too long, I agree with Carsten. I expect imported
files relativ to where I import them.
--
Reinhard
Re: Splitting cocoon.xconf: done
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> I see a misunderstanding: "context" (or "local context") is not to be
>> confused with "root context". When loading the root cocoon.xconf, the
>> local context is the root context. When loading a sitemap, the local
>> context is the sitemap location and any <include> in <map:component>
>> will use that local context.
>>
>> So, to summarize, <include> uses the local context (either root
>> context or sitemap location), but not the configuration file's location.
>>
>> How does that sound to a dumb user? ;-)
>>
> Hmmm, I'm too dumb to find a good answer :)
> Seriously, I think we can go with this - although it would be easier to
> understand if the include in the xconf would be relative to the xconf;
> Your argumentation is correct, but I guess we will have to explain
> this to users several times.
I understand this. Maybe my "overall consistency" point of view is too
much and we should handle it more "naturally"? What do people think?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> I see a misunderstanding: "context" (or "local context") is not to be
> confused with "root context". When loading the root cocoon.xconf, the
> local context is the root context. When loading a sitemap, the local
> context is the sitemap location and any <include> in <map:component>
> will use that local context.
>
> So, to summarize, <include> uses the local context (either root context
> or sitemap location), but not the configuration file's location.
>
> How does that sound to a dumb user? ;-)
>
Hmmm, I'm too dumb to find a good answer :)
Seriously, I think we can go with this - although it would be easier to
understand if the include in the xconf would be relative to the xconf;
Your argumentation is correct, but I guess we will have to explain
this to users several times.
Anyways, we should "support" this behaviour by always using the
context: protocol in the cocoon.xconf as you already did.
Carsten
Re: Splitting cocoon.xconf: done
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>> Why are relative files resolved relative to the context and not to
>>> the location of the cocoon.xconf?
>>
>>
>> Good question :-)
>>
>> At first, I thought relative URIs should be relative to the current
>> file,
>
> Yepp, that was my thought as well.
>
> > but then looked at how sourceresolving is done everywhere else in
>
>> Cocoon: URIs are relative to the current sitemap (i.e. the context in
>> case of the root sitemap): "src" attributes in the sitemap, includes
>> in CInclude and XInclude, etc. AFAIK, only XSLT's includes and
>> imports are handled differently because it's mandated by the XSLT spec.
>>
>> So, I decided to use the standard sourceresolving mechanism in xconf
>> also.
>>
>> How does that sound?
>>
> Confusing :) It's not a big deal, but without thinking - as a dumb
> user (and I'm very good in acting like someone who can't think at all)
> - I
> would expect that a relative path in the cocoon.xconf is resolved
> relative to the cocoon.xconf like it happens with paths in the sitemap.
Not exactly: paths in the sitemap are relative to the sitemap location
because this is the location that defines the local context. Now if you
consider e.g. a file in "subdir/blah.xml" that has a <cinclude:include
src="foo.xml"/>, then that "foo.xml" will be resolved relative to the
sitemap location (i.e. the local context) and not relative to "subdir".
That's why I chose this way or resolving relative URIs.
> The cocoon.xconf is the core configuration for cocoon, so when it is
> consulted there is no sitemap.
Yes, but there is a context, which is the same than the one used for the
root sitemap ;-)
> If you use the include (of components) in a sitemap, then I assume
> that it is resolved relative to the location of this sitemap and not
> to the context.
I see a misunderstanding: "context" (or "local context") is not to be
confused with "root context". When loading the root cocoon.xconf, the
local context is the root context. When loading a sitemap, the local
context is the sitemap location and any <include> in <map:component>
will use that local context.
So, to summarize, <include> uses the local context (either root context
or sitemap location), but not the configuration file's location.
How does that sound to a dumb user? ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>> Why are relative files resolved relative to the context and not to the
>> location of the cocoon.xconf?
>
> Good question :-)
>
> At first, I thought relative URIs should be relative to the current
> file,
Yepp, that was my thought as well.
> but then looked at how sourceresolving is done everywhere else in
> Cocoon: URIs are relative to the current sitemap (i.e. the context in
> case of the root sitemap): "src" attributes in the sitemap, includes in
> CInclude and XInclude, etc. AFAIK, only XSLT's includes and imports are
> handled differently because it's mandated by the XSLT spec.
>
> So, I decided to use the standard sourceresolving mechanism in xconf also.
>
> How does that sound?
>
Confusing :) It's not a big deal, but without thinking - as a dumb user
(and I'm very good in acting like someone who can't think at all) - I
would expect that a relative path in the cocoon.xconf is resolved
relative to the cocoon.xconf like it happens with paths in the sitemap.
The cocoon.xconf is the core configuration for cocoon, so when it
is consulted there is no sitemap.
If you use the include (of components) in a sitemap, then I assume that
it is resolved relative to the location of this sitemap and not to the
context.
Carsten
Re: Splitting cocoon.xconf: done
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Great work, Sylvain!
Thanks!
> Just one questions below:
>
> Sylvain Wallez wrote:
>
>> Hi all,
>>
>> I just committed the new feature that allows cocoon.xconf to be split
>> into small parts. There is a new <include src=""/> statement that
>> includes either a roles file or a xconf file. A minimal
>> sourceresolver is setup at cocoon boot time that provides the
>> "resource:" and "context:" protocols to fetch files (relative files
>> are equivalent to "context:").
>
>
> Why are relative files resolved relative to the context and not to the
> location of the cocoon.xconf?
Good question :-)
At first, I thought relative URIs should be relative to the current
file, but then looked at how sourceresolving is done everywhere else in
Cocoon: URIs are relative to the current sitemap (i.e. the context in
case of the root sitemap): "src" attributes in the sitemap, includes in
CInclude and XInclude, etc. AFAIK, only XSLT's includes and imports are
handled differently because it's mandated by the XSLT spec.
So, I decided to use the standard sourceresolving mechanism in xconf also.
How does that sound?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf: done
Posted by Carsten Ziegeler <cz...@apache.org>.
Great work, Sylvain!
Just one questions below:
Sylvain Wallez wrote:
> Hi all,
>
> I just committed the new feature that allows cocoon.xconf to be split
> into small parts. There is a new <include src=""/> statement that
> includes either a roles file or a xconf file. A minimal sourceresolver
> is setup at cocoon boot time that provides the "resource:" and
> "context:" protocols to fetch files (relative files are equivalent to
> "context:").
>
Why are relative files resolved relative to the context and not to
the location of the cocoon.xconf?
Carsten