You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/07/10 17:23:47 UTC
[RT] Merging ServerPages and File Generators
In my never ending quest to perfect Cocoon, I have a proposal
that will make some problems easier to solve. It is the
merging of ServerPagesGenerator and FileGenerator Components.
The reason is that the only real difference between them is
that the ServerPages Generator compiles an XML file with the
root "xsp:page".
By merging the two, we use automatic discovery of the type of
file we are dealing with, and act accordingly. I can't tell
you the number of times I have either had to declare all pages
in a URL space as ServerPages, or do some crazy Sitemap
workarounds for a page or two just because I needed XSP in
a couple of locations.
For example, If I have a general pipeline declaration that
works like this:
<map:generate src="docs/{1}.xml"/>
<map:transform src="stylesheets/1.xsl"/>
<map:transform src="stylesheets/2.xsl"/>
<map:transform src="stylesheets/3.xsl"/>
<map:serialize>
Then I would have to add another entry like this:
<map:generate type="serverpages" src="docs/{1}.xml"/>
<map:transform src="stylesheets/1.xsl"/>
<map:transform src="stylesheets/2.xsl"/>
<map:transform src="stylesheets/3.xsl"/>
<map:serialize>
for XSP pages in the same general URL space. The only
difference is the generator type. So I either use
fancy selector logic, an additional matcher entry, or
make all my pages in a URL space XSP pages. It depends
on the cost.
The merging of ServerPagesGenerator and FileGenerator will
allow automatic discovery of the two scenarios without
complex logic--easing administration duties.
This also eases development as pages are migrated to/from
XSP depending on business needs.
Another side benefit is that the FileGenerator already has
logic that determines if a file has been modified--we can
leverage that to determine whether we want our XSP regenerated.
Thoughts, Comments?
RE: [RT] Merging ServerPages and File Generators
Posted by Torsten Curdt <tc...@dff.st>.
> > Thoughts, Comments?
>
> I like the idea because I think it's a very common use
> case. Especially if it doesn't cost much or is almost free to get.
Yepp! Would be nice to have...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Merging ServerPages and File Generators
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 10.Jul.2001 -- 11:23 AM, Berin Loritsch wrote:
> For example, If I have a general pipeline declaration that
> works like this:
>
> <map:generate src="docs/{1}.xml"/>
> <map:transform src="stylesheets/1.xsl"/>
> <map:transform src="stylesheets/2.xsl"/>
> <map:transform src="stylesheets/3.xsl"/>
> <map:serialize>
>
> Then I would have to add another entry like this:
>
> <map:generate type="serverpages" src="docs/{1}.xml"/>
> <map:transform src="stylesheets/1.xsl"/>
> <map:transform src="stylesheets/2.xsl"/>
> <map:transform src="stylesheets/3.xsl"/>
> <map:serialize>
>
Berin, you could use resources to make this a little less cumbersome:
<map:resource name="1-2-3">
<map:transform src="stylesheets/1.xsl"/>
<map:transform src="stylesheets/2.xsl"/>
<map:transform src="stylesheets/3.xsl"/>
<map:serialize>
</map:resource/>
<map:generate src="docs/{1}.xml"/>
<redirect-to resource="1-2-3"/>
<map:generate type="serverpages" src="docs/{1}.xml"/>
<redirect-to resource="1-2-3"/>
Or -- like you said -- another matcher / selector within your
pipeline.
> Thoughts, Comments?
I like the idea because I think it's a very common use
case. Especially if it doesn't cost much or is almost free to get.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [RT] Merging ServerPages and File Generators
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> What if there is no <xsp:page>, i.e. you have a clean page where all XSP
> markup is inserted by logicsheets ?
You can't have XSP without the <xsp:page> element. You can't use logicsheets
without XSP. It's that simple.
Also, I do not see how your suffix selector can a) know how to test for the
filesystem extension quicly and b) be easier to use....
I am trying to get away from selectors altogether.
> IMO, having separate extensions for passive content (.xml files) and
> active content (.xsp files) is a good thing. Too much magic kills the
> confidence users have in the tool. I speak by experience, because we are
> currently redesigning some of our logicsheets so they offer a lower
> level of abstraction to their users : they were afraid to use features
> that did too much work automagically.
Yup. I don't know why, but I gues we have to live with people making
their own lives more difficult than it needs to be.
Re: AW: [RT] Merging ServerPages and File Generators
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
> Carsten Ziegeler wrote:
> >
> > How would this new component detect if is an xml document
> > or an xsp page?
>
> On first access, it would catch the very first startElement()
> event. If it is not:
>
> // raw parameter may vary
> startElement("http://apache.org/xsp", "page", "xsp:page", a);
>
> then execution happens as normal. If it is, it loads the XSP,
> caches the information that it is an XSP page, and fires the
> rest of the page through the IncludeXMLConsumer. All subsequent
> requests use the XSP page directly because we have that
> information cached.
>
> FileGenerator ProgramGenerator IncludeXMLConsumer
> ------------- ---------------- ------------------
> |
> +--| isXSP() |
> | +-------------------->|
> |<-| |
> |
> +--|
> | | startElement()
> | |
> | +--| isXSP() |
> | | +----------------->|
> | | | | |
> | | +-------------------------------------->|
> |<-+--| (yes) |
> | |
> | | (no)
> | |
> | +--------->startElement()
> |<-|
> |
>
<snip/>
What if there is no <xsp:page>, i.e. you have a clean page where all XSP
markup is inserted by logicsheets ?
IMO, having separate extensions for passive content (.xml files) and
active content (.xsp files) is a good thing. Too much magic kills the
confidence users have in the tool. I speak by experience, because we are
currently redesigning some of our logicsheets so they offer a lower
level of abstraction to their users : they were afraid to use features
that did too much work automagically.
In order to have a single transformation pipeline for both active and
passive sources, a SuffixSelector could do the job :
<map:match pattern="*.html">
<map:select type="suffix">
<!-- base name of the file to search for -->
<map:parameter name="base" value="{1}"/>
<!-- ordered list of suffixes to search for -->
<map:parameter name="suffixes" value="xsp, xml"/>
<map:when test="xsp">
<map:generate type="serverpages" src="{1}.xsp/>
</map:when>
<map:when test="xml">
<map:generate src="{1}.xml"/>
</map:when>
</map:select>
<map:transform ...
Using this, just change the file extension from xml to xsp to change it
from static to dynamic while keeping the same transformation process.
My .02 euro...
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [RT] Merging ServerPages and File Generators
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> How would this new component detect if is an xml document
> or an xsp page?
On first access, it would catch the very first startElement()
event. If it is not:
// raw parameter may vary
startElement("http://apache.org/xsp", "page", "xsp:page", a);
then execution happens as normal. If it is, it loads the XSP,
caches the information that it is an XSP page, and fires the
rest of the page through the IncludeXMLConsumer. All subsequent
requests use the XSP page directly because we have that
information cached.
FileGenerator ProgramGenerator IncludeXMLConsumer
------------- ---------------- ------------------
|
+--| isXSP() |
| +-------------------->|
|<-| |
|
+--|
| | startElement()
| |
| +--| isXSP() |
| | +----------------->|
| | | | |
| | +-------------------------------------->|
|<-+--| (yes) |
| |
| | (no)
| |
| +--------->startElement()
|<-|
|
>
> Carsten
>
> > -----Ursprungliche Nachricht-----
> > Von: Berin Loritsch [mailto:bloritsch@apache.org]
> > Gesendet: Dienstag, 10. Juli 2001 17:24
> > An: cocoon-dev@xml.apache.org
> > Betreff: [RT] Merging ServerPages and File Generators
> >
> >
> > In my never ending quest to perfect Cocoon, I have a proposal
> > that will make some problems easier to solve. It is the
> > merging of ServerPagesGenerator and FileGenerator Components.
> > The reason is that the only real difference between them is
> > that the ServerPages Generator compiles an XML file with the
> > root "xsp:page".
> >
> > By merging the two, we use automatic discovery of the type of
> > file we are dealing with, and act accordingly. I can't tell
> > you the number of times I have either had to declare all pages
> > in a URL space as ServerPages, or do some crazy Sitemap
> > workarounds for a page or two just because I needed XSP in
> > a couple of locations.
> >
> > For example, If I have a general pipeline declaration that
> > works like this:
> >
> > <map:generate src="docs/{1}.xml"/>
> > <map:transform src="stylesheets/1.xsl"/>
> > <map:transform src="stylesheets/2.xsl"/>
> > <map:transform src="stylesheets/3.xsl"/>
> > <map:serialize>
> >
> > Then I would have to add another entry like this:
> >
> > <map:generate type="serverpages" src="docs/{1}.xml"/>
> > <map:transform src="stylesheets/1.xsl"/>
> > <map:transform src="stylesheets/2.xsl"/>
> > <map:transform src="stylesheets/3.xsl"/>
> > <map:serialize>
> >
> > for XSP pages in the same general URL space. The only
> > difference is the generator type. So I either use
> > fancy selector logic, an additional matcher entry, or
> > make all my pages in a URL space XSP pages. It depends
> > on the cost.
> >
> > The merging of ServerPagesGenerator and FileGenerator will
> > allow automatic discovery of the two scenarios without
> > complex logic--easing administration duties.
> >
> > This also eases development as pages are migrated to/from
> > XSP depending on business needs.
> >
> > Another side benefit is that the FileGenerator already has
> > logic that determines if a file has been modified--we can
> > leverage that to determine whether we want our XSP regenerated.
> >
> > Thoughts, Comments?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [RT] Merging ServerPages and File Generators
Posted by Carsten Ziegeler <cz...@sundn.de>.
How would this new component detect if is an xml document
or an xsp page?
Carsten
> -----Ursprungliche Nachricht-----
> Von: Berin Loritsch [mailto:bloritsch@apache.org]
> Gesendet: Dienstag, 10. Juli 2001 17:24
> An: cocoon-dev@xml.apache.org
> Betreff: [RT] Merging ServerPages and File Generators
>
>
> In my never ending quest to perfect Cocoon, I have a proposal
> that will make some problems easier to solve. It is the
> merging of ServerPagesGenerator and FileGenerator Components.
> The reason is that the only real difference between them is
> that the ServerPages Generator compiles an XML file with the
> root "xsp:page".
>
> By merging the two, we use automatic discovery of the type of
> file we are dealing with, and act accordingly. I can't tell
> you the number of times I have either had to declare all pages
> in a URL space as ServerPages, or do some crazy Sitemap
> workarounds for a page or two just because I needed XSP in
> a couple of locations.
>
> For example, If I have a general pipeline declaration that
> works like this:
>
> <map:generate src="docs/{1}.xml"/>
> <map:transform src="stylesheets/1.xsl"/>
> <map:transform src="stylesheets/2.xsl"/>
> <map:transform src="stylesheets/3.xsl"/>
> <map:serialize>
>
> Then I would have to add another entry like this:
>
> <map:generate type="serverpages" src="docs/{1}.xml"/>
> <map:transform src="stylesheets/1.xsl"/>
> <map:transform src="stylesheets/2.xsl"/>
> <map:transform src="stylesheets/3.xsl"/>
> <map:serialize>
>
> for XSP pages in the same general URL space. The only
> difference is the generator type. So I either use
> fancy selector logic, an additional matcher entry, or
> make all my pages in a URL space XSP pages. It depends
> on the cost.
>
> The merging of ServerPagesGenerator and FileGenerator will
> allow automatic discovery of the two scenarios without
> complex logic--easing administration duties.
>
> This also eases development as pages are migrated to/from
> XSP depending on business needs.
>
> Another side benefit is that the FileGenerator already has
> logic that determines if a file has been modified--we can
> leverage that to determine whether we want our XSP regenerated.
>
> Thoughts, Comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org