This is crazy, everything can be done with xalan. I voluenteer to help if
needed. Here is how I do it:
I have pregenerated large sites with xalan (redirect extension) and haven't
really had need to take notice of the time it took. Have a
'site-config.xml' that describes the folder structure and the pages inside
along with any other info that should not be included in the (pure,
licenseable, etc) CONTENT. This config file (actually in a database and
maintained with a gui by editors/designers & producers) can be used for a
number of things and one of those is to pre-generate the html using xsl and
xml. It takes so little time that I don't even notice and it is done with
(docbook) content heavy sites. It's simple!
Here is something similar to a recent post to the XSL list that illustrates
the method (there is more to it, namely the page wrapper wrapping all the
content for things like the nav - which is built from the config):
_______________________________
config.xml -- some sample XML
-----------------------
<folder name="" id="root">
<page id="index_en_us">
<xml filref="boo_en_us.xml"/>
</page>
<page id="index_en_uk">
<xml filref="boo_en_us.xml"/>
</page>
<page id="index_es_la">>
<xml filref="boo_en_us.xml"/>
</page>
<folder name="docs" id="etc...>
<folder name="doc1">
etc...
</folder>
</folder
</folder>
--------------------------------------------------
wrapper.xsl -- transform the above XML with the below XSL:
<xsl:template match="//*">
<xsl:for-each select="page">
<xsl:apply-templates />
</xsl:for-each>
</xsl:template>
<xsl:template match="page">
<xsl:variable name="path">
<xsl:call-template
name="get-path-to-file-from-ancestor-folder-names-or-however">
<xsl:with-param name="page-id" select="@page-id"/>
</xsl:call-template>
</xsl:variable>
<!-- xalan redirect to file concat($path,@id,'.html') or something like
that -->
<xsl:apply-templates select="document(concat($path,xsml/@fileref)"/>
<!-- end redirect -->
</xsl:template>
<xsl:template match="root-of-pulled-page">
<html>
blah blah
</html>
</xsl:template>
--------------------------------
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 13, 2001 12:02 PM
Subject: -1 to Anakia
>
> Hi Kids. I hate to rain on the parade, but I think it would look pretty
> funny to use Anakia instead of XSLT for the Xalan project. Further, I
> think the use of JDOM in Anakia is moving the opposite direction of a high
> performance for dynamic transformations.
>
> I don't usually take a non-moveable stand on things, but at least the
Xalan
> project will be using Anakia over my dead, bloodied body. Nor do I think
> the rest of apache should adapt it... I've had arguments Jon before about
> why I think XSLT & JAXP 1.1 is better.
>
> If someone pulls out the ". Anakia seems to perform much faster than
> Xalan's XSL processor at creating pages. (23 pages are generated in 7-8
> seconds on a PIII 500mhz running Win98 and JDK 1.3 with client Hotspot. A
> similar system using Ant's <style> task took 14-15 seconds -- nearly a 2x
> speed improvement.) " I'll scream. Like all benchmarks, claims are easily
> made, but details sometimes not so fourth coming. And, no, I don't want
to
> get into a benchmark war with these guys. I will say the problems with
> Stylebook have very little to do with XSLT or Xalan... it is much more a
> factor of the stylebook code itself (and sometimes how it is using Xalan
> and the DOM).
>
> I would simply ask you all to double-check your logic about adapting
> Anakia, and whether or not it's really the direction you want to go.
>
> BTW, the Anakia page is at:
http://jakarta.apache.org/velocity/anakia.html.
> I obviously have very strong objections to it's claims.
>
> -1.
>
> -scott
>
>
>
>
>
> "Ted Leung"
> <twleung@saur To: <[EMAIL PROTECTED]>
> ia.com> cc: (bcc: Scott
Boag/CAM/Lotus)
> Subject: Re: [RFC] Re: Helma
XML-RPC @ Jakarta
> 07/12/01
> 12:23 PM
> Please
> respond to
> general
>
>
>
>
>
>
> The plan for the site has always been to use C2 when it stabilized.
>
> We are getting closer and closer to that, right Dims? I don't know
> anything
> about Anakia, but if it is using XML as input, then it seems that
> stylesheet
> magic could be used to go between C2 and Anakia and InDesign.
>
> If we could get off of stylebook and onto C2 I'd be very happy.
>
> Ted
>
> ----- Original Message -----
> From: "Jason van Zyl" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, July 12, 2001 7:13 AM
> Subject: Re: [RFC] Re: Helma XML-RPC @ Jakarta
>
>
> On 7/12/01 9:12 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>
> > Davanum Srinivas wrote:
> >>
> >> Is there any way you could use Stylebook? Site generation for
> xml.apache.org
> >> is already in a bit
> >> of mess. Take a look at the xml-site module in CVS. Using anakia now
> will
> >> increase the problems
> >> later when all of us decide to revamp the system for generating the
> >> xml.apache.org site.
> >
> > Aren't we planning on replacing stylebook "real soon now"?
>
> I sent a message Davanum about Anakia. I would like to use Anakia
> because it's working well at Jakarta and I think it's going to
> be used for the main apache site.
>
> I am also working on an XML import filter for Adobe's InDesign which
> will allow me to take an Anakia formatted document and produce
> professional grade PDFs for all the apache documentation. I'm using
> InDesign to layout a book I'm working on so I figured I'd kill a
> few birds. This will take a while but thatıs the eventual goal.
>
> I really don't want to use Stylebook, it's slow and what it produces
> right now must account for half the traffic on apache with all those
> itty bitty images :-)
>
> > - Sam Ruby
> >
> >
> > ---------------------------------------------------------------------
> > In case of troubles, e-mail: [EMAIL PROTECTED]
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: [EMAIL PROTECTED]
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: [EMAIL PROTECTED]
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: [EMAIL PROTECTED]
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
