From: "Vadim Gritsenko" <[EMAIL PROTECTED]>
> > From: Konstantin Piroumian [mailto:[EMAIL PROTECTED]]
> >
> > Hi, Cocooners!
> >
> > A simple question: why in a sub sitemap we need to add <map:components
> /> if
> > we add anything to the list?
>
> From the sub sitemap:
> <map:generators default="file"/>
>
> From the sitemap.xsl:
> <xsl:with-param name="default-component"
> select="/map:sitemap/map:components/map:generators/@default"/>
>
>
> If you know better way how in XSLT get default component, you could
> modify compiled sitemap engine so it does not requires <map:components
> /> section.
A guess:
<xsl:variable name="$default">
<xsl:choose>...check if we have declared default, set to 'file', if
no</xsl:choose>
</xsl:variable>
...
<xsl:with-param name="default-component"
select="{$default}"/> ?
But are we going to support compiled sitemap in 2.1 branch? I think no.
>
> Interpreted engine (IMHO) already should work without this section.
> Evidence of this found in DefaultTreeBuilder:
>
> if (type == null && selector instanceof ExtendedComponentSelector) {
> type = ((ExtendedComponentSelector)selector).getDefaultHint();
> }
>
> And because this engine going to be default in 2.1 series, I'm Ok just
> to wait a bit, so issue will dissolve by itself as people move to
> interpreted engine.
I was going to create this sample only for 2.1, so it won't be problem.
>
> (Also I'm still not convinced that interpreted engine is faster then
> compiled one ;)
One thing I am sure of is that interpreted one is much better in error
reporting and thus much better to work with.
>
>
> > Isn't it possible to inherit components implicitly?
>
> They are inherited. But you want to know the default.
Why I have to know it? I have to be able to change the default or declare it
explicitely to be sure, but if I am Ok with the inherited one then I'd like
to omit that part of the sitemap.
>
>
> > I ask this, because in response to multiple user requests for having
> > something simple to start with in Cocoon and also for my colleagues
> I'd like
> > to create a very simple application template that can be easily used
> for
> > playing with Cocoon.
> >
> > Sample's directory is this:
> > /root <-- suggest a better name for the root
>
> "myapp"?
Bingo! ;)
>
>
> > /xml
> > /xsl
> > /xsp
> >
> > Without that declaration a Cocoon Newbie's sub-sitemap can look like
> below
> > (mounted to samples/):
> >
> > <?xml version="1.0"?>
> > <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0";>
>
> <map:components>
> <map:generators default="file"/>
> <map:transformers default="xslt"/>
> <map:readers default="resource"/>
> <map:serializers default="html"/>
> <map:selectors default="browser"/>
> <map:matchers default="wildcard"/>
> </map:components>
>
> It's not *that* much more complex :)
It's not much complex for your experienced eye ;)
But it's a little confusing for newbies - I tell you this on real
experience.
>
...
>
> > - what is the best place for such a template/sample
>
> samples directory?
Samples directory is for samples (that are rarely changed by user). I want
this app to be some template where a new user can start making his own
application. Maybe just a 'myapp' in the webapp directory?
>
>
> > - is it worth making a special target for building a minimal
> Cocoon
> > containing a very minimal set of features?
>
> May be better documenting the process will help. It boils down to just
> couple of steps:
> 1. build clean
This means that the user has sources. What about a distribution of just a
cocoon-myapp.war? (Just like Struts' struts-blank.war)
> 2. rm all optional libs
Some jars from core also can be succesfully removed for the first time.
> 3. build -D....
See 1.
Konstantin
>
> Vadim
>
>
> > Regards,
> > Konstantin Piroumian
> > _________________________________________
> > Konstantin Piroumian
> > Lead Developer
> > ICQ#: 2297575
> > ( Work Tel#: +7 095 795 0520 * 1288
> > + More ways to contact me
> > i See more about me
> > _________________________________________
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
