You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Konstantin Piroumian <kp...@apache.org> on 2002/04/27 12:13:33 UTC
[SITEMAP] Component declaration
Hi, Cocooners!
A simple question: why in a sub sitemap we need to add <map:components /> if
we add anything to the list? Isn't it possible to inherit components
implicitly?
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
/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">
<!-- Processing pipelines -->
<map:pipelines>
<map:pipeline>
<!-- Process static content -->
<map:match pattern="*.xml">
<map:generate src="xml/{1}.xml" />
<map:transform src="xsl/style.xsl" />
<map:serialize />
</map:match>
<!-- Process dynamic content -->
<map:match pattern="*.xsp">
<map:generate type="serverpages" src="xsp/{1}.xsp" />
<map:transform src="xsl/style.xsl" />
<map:serialize />
</map:match>
</map:pipeline>
</map:pipelines>
</map:sitemap>
<!-- end of file -->
And the instructions would be like this:
- create an XML file, then place it in /xml directory
- create a stylesheet, then place it in /xsl directory
[- create an XSP page, place it into /xsp directory]
Enter the URL of your page:
http://localhost:8080/cocoon/samples/root/page.xml
Quite easy and simple.
So, my questions are:
- how to remove <map:componenets />
- what is the best place for such a template/sample
- is it worth making a special target for building a minimal Cocoon
containing a very minimal set of features?
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SITEMAP] Component declaration
Posted by Diana Shannon <te...@mac.com>.
Konstantin:
Great idea!
> So, my questions are:
> - how to remove <map:componenets />
> - what is the best place for such a template/sample
Information about this could exist in different locations within
Cocoon's documentation. Several ideas, in order of increasing value to
users:
- as an Example: text description of template/sample with links to
resources within distro
- as a part of a How-To: How to build/work with a newbie version of
Cocoon
- as a Tutorial: Getting Started with Cocoon for Newbies
I hope to provide guidelines/templates/schema for these types of
contributions next week. I have drafts in the works: How-to Write
Example/How-To/Tutorial. Really, really sorry for any delay, but I'm
simply overwhelmed by how much there is to do/think through...
> - is it worth making a special target for building a minimal Cocoon
> containing a very minimal set of features?
Yes, I think so. I've *never* understand why a stripped down version of
Cocoon isn't part of an interactive build target -- or have I overlooked
this option?
Thanks.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [SITEMAP] Component declaration
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Konstantin Piroumian [mailto:kpiroumian@apache.org]
>
> From: "Vadim Gritsenko" <va...@verizon.net>
> > > From: Konstantin Piroumian [mailto:kpiroumian@apache.org]
> > >
> > > 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}"/> ?
Hardcoded? No joy... I would leave it alone unchanged (anyway, 2.0.3
branch is frozen for new features)
<snip/>
> > > 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 was talking about compiled engine.
<snip/>
> > > - 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?
Ok
> > > - 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)
Hm. Demand is high, I would say let's do this. If we add set of options
like "-Duse.batik=yes" to the build script and copy batik/compile
batik-related classes/add batik sitemap entries only if it is true, then
it will be easy to create target for "cocoon-blank.war".
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SITEMAP] Component declaration
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Vadim Gritsenko" <va...@verizon.net>
> > From: Konstantin Piroumian [mailto:kpiroumian@apache.org]
> >
> > 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SITEMAP] Component declaration
Posted by Diana Shannon <te...@mac.com>.
Konstantin:
> For new users I would prefer a separate distributions:
> - Minimal binary: with XML/XSP/XSLT/(maybe FOP) features enabled and
> myapp template in WAR format
> - Standart binary: all the core and optional features (without
> scratchpad) plus docs and samples in WAR format
> - Documentation & Samples: only documentation and samples in WAR
> format
> - Sources: CVS snapshot
>
> What do you think?
Why don't you query the users list about this?
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SITEMAP] Component declaration
Posted by Konstantin Piroumian <kp...@apache.org>.
> > From: Diana Shannon [mailto:terracare@mac.com]
<skip why="nothing to add:agree with Diana" />
>
> > 3. Building, even without optional jars, still leaves the sitemap
> > overwhelming for new users. I think Konstantin is addressing that
> issue
> > as well.
>
> New refactored samples IMHO will simplify main sitemap a lot.
Yes, I am cleaning up root sitemap, though a little slow, but the final goal
would be to clean it up from everything except component declarations and a
few mounts.
For new users I would prefer a separate distributions:
- Minimal binary: with XML/XSP/XSLT/(maybe FOP) features enabled and
myapp template in WAR format
- Standart binary: all the core and optional features (without
scratchpad) plus docs and samples in WAR format
- Documentation & Samples: only documentation and samples in WAR format
- Sources: CVS snapshot
What do you think?
Konstantin
>
> Vadim
>
> > Diana
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [SITEMAP] Component declaration
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Diana Shannon [mailto:terracare@mac.com]
>
> >> - 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
> > 2. rm all optional libs
> > 3. build -D....
>
> Of course, improved documentation helps, and it's coming, but...
>
> 1. I don't think it's a good idea to have new users rm jars. Even if
> designated optional, as in the head-release, it takes time to figure
out
> the features these jars provide. Also, some users will inevitably make
> mistakes (like deleting jars they may need later). It's just not
> intuitive to remove a feature by removing a jar. Most people would
> expect to make decisions like this in an interactive build session or
> config file.
> 2. This build experience makes an important first impression on those
> evaluating Cocoon. We should make it as simple as possible -- if
that's
> what a user needs. I'm not implying that advanced users need this.
These are valid points. I think Nicola "master of interactive build" Ken
able to help with it ;)
> 3. Building, even without optional jars, still leaves the sitemap
> overwhelming for new users. I think Konstantin is addressing that
issue
> as well.
New refactored samples IMHO will simplify main sitemap a lot.
Vadim
> Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SITEMAP] Component declaration
Posted by Diana Shannon <te...@mac.com>.
>> - 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
> 2. rm all optional libs
> 3. build -D....
Of course, improved documentation helps, and it's coming, but...
1. I don't think it's a good idea to have new users rm jars. Even if
designated optional, as in the head-release, it takes time to figure out
the features these jars provide. Also, some users will inevitably make
mistakes (like deleting jars they may need later). It's just not
intuitive to remove a feature by removing a jar. Most people would
expect to make decisions like this in an interactive build session or
config file.
2. This build experience makes an important first impression on those
evaluating Cocoon. We should make it as simple as possible -- if that's
what a user needs. I'm not implying that advanced users need this.
3. Building, even without optional jars, still leaves the sitemap
overwhelming for new users. I think Konstantin is addressing that issue
as well.
Diana
>
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [SITEMAP] Component declaration
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Konstantin Piroumian [mailto:kpiroumian@apache.org]
>
> 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.
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.
(Also I'm still not convinced that interpreted engine is faster then
compiled one ;)
> Isn't it possible to inherit components implicitly?
They are inherited. But you want to know the default.
> 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"?
> /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 :)
> <!-- Processing pipelines -->
> <map:pipelines>
> <map:pipeline>
>
> <!-- Process static content -->
> <map:match pattern="*.xml">
> <map:generate src="xml/{1}.xml" />
> <map:transform src="xsl/style.xsl" />
> <map:serialize />
> </map:match>
>
> <!-- Process dynamic content -->
> <map:match pattern="*.xsp">
> <map:generate type="serverpages" src="xsp/{1}.xsp" />
> <map:transform src="xsl/style.xsl" />
> <map:serialize />
> </map:match>
>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
> <!-- end of file -->
>
> And the instructions would be like this:
> - create an XML file, then place it in /xml directory
> - create a stylesheet, then place it in /xsl directory
> [- create an XSP page, place it into /xsp directory]
>
> Enter the URL of your page:
> http://localhost:8080/cocoon/samples/root/page.xml
>
> Quite easy and simple.
>
> So, my questions are:
> - how to remove <map:componenets />
See above.
> - what is the best place for such a template/sample
samples 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
2. rm all optional libs
3. build -D....
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org