You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by go...@osmosis.gr on 2003/10/04 00:11:17 UTC
RE: html templates - best practise [ann] othello
hi people
in our plans was to announce this in few weeks when the project will
have a final state and a HowTo use Guide
but considering this thread we have to show you our approach
the idea was a project that can build small to medium web sites using
cocoon
the project must be template-based (so designing a different theme you can
change the look & feel of the site) and will be able to reused without to
touch (need to change) the sitemap.xmap
for the moment we have implement cocoon i18n and a mechanism that allow
you to create your pages writing xhtml or your own element and custom
transformations (xml/xslt)
some hits
---------
in root folder are 2 files
home.xhtm
main.xhtm
this files are the templates for the home (first) page and the content
pages
inside are some <osm:block-copy/> and <osm:copy/> (will be content-copy
soon) that select the content from spesific block (/bloks/blocks.xml) or
content files
the content files are in /c_en/*.xml, /c_el/*.xml, /c_yourLang/*.xml
the directory structure is designed this way to be ready for our virtual
hostin server, considering the usage of mod_proxy, mod_rewrite
installation
-----------
1. download the zip file
2. extract and put [othello.gr] dir somewhere in your disk
3. mount othello sitemap.xmap in cocoon main sitemap.xmap
othello.gr
|
+------conf
| +--sitemap.xmap
|
+------htdocs
+-- (all the stuff)
for example
<map:pipeline>
<map:match pattern="*.gr/**">
<map:mount check-reload="yes" src="file://c:/Server/xwww/{1}.gr/conf/sitemap.xmap" uri-prefix="{1}.gr"/>
</map:match>
</map:pipeline>
or
<map:pipeline>
<map:match pattern="othello.gr/**">
<map:mount check-reload="yes" src="file://c:/Server/xwww/othello.gr/conf/sitemap.xmap" uri-prefix="othello.gr"/>
</map:match>
</map:pipeline>
4. ask http://localhost:8080/cocoon/othello.gr/
*** please use cocoon 2.0.4 ***
note: in 2.1 some namespaces declaration have to change
we have test all this in both unix and win platform (winXP)
with tomcat 4.0.6 4.1.17 4.1.24
n'joy
please inform me for any comments or suggestion
soon will be a list for this purpose
for the momemnt contact me directly or using this list
(if this usage is ON-TOPIC)
we will make our best to see all this in the examples area of cocoon distribution
--- stavros
On Fri, 3 Oct 2003, Horsfield, Peter A. wrote:
> One thing I think nobody has mentioned yet is the use
> of the cocoon:/ internal pipeline call.
>
> Using that in conjunction with the XSLT document function means
> you get to take advantage of Cocoon pipelines for fragments of
> presentation or data XML, whatever format. You can also then
> feed in the particular fragments using XSLT parameters
> specified in the sitemap, and hence based on the request.
>
> The problem with using this indirection is that you may bypass a
> little bit of the Cocoon framework. In particular, I think one
> of the articles that someone linked too mentioned
> that Cocoon or XSLT blindly caches the document accessed by the
> document() function. This is obviously no good if the URI indicates
> a resource that might change ( anyone know for sure? )
>
> The other XSLT issue is the way it can implicitly fall back to a
> non-streamed approach. I suspect that carefully written XSLT will
> maintain the SAX streaming without caching it all first. However
> as soon as you use the document function to merge two inputs,
> you're caching the secondary input. In general I've seen that
> presentation XML is larger/longer than data XML which is why I
> access data through the document() function and not presentation.
>
> The alternative to XSLT I've seen around is STX, streaming
> transformations for xml, but I've not used it. Streaming/Merging
> two SAX event streams does seem like a thorny problem at first
> glance though.
>
> Also, bear in mind that as soon as you embed XHTML within your
> XSLT directly, you limit yourself to Altova products as the only
> IDE capable of understanding what you've done. The majority of
> IDEs out there still spend the majority of their time trying
> to understand the various finicky bits of HTML4 and less on
> understanding XML namespaces.
>
> Regards,
>
> Peter
>
> -----Original Message-----
> From: Alexander Schatten [mailto:alasan@gmx.at]
> Sent: Friday, October 03, 2003 12:30 PM
> To: users@cocoon.apache.org
> Subject: Re: html templates - best practise
>
>
> I developed a way of "callback" templates. Look at this:
>
> (0) consider a HTML design like this:
>
> +--------------------------------------------+
> | Page Title (each page different) |
> +--------------------------------------------+
> | Main Navigation (for all pages the same |
> +--------------------------------------------+
> | |
> | |
> | Content (each page different) |
> | |
> | |
> | |
> +--------------------------------------------+
> | Footer (each page different) |
> +--------------------------------------------+
>
>
> (1) first of all there is the default.xsl stylesheet it looks (very
> reduced version) like this:
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> encoding="iso-8859-1" version="1.0">
>
> <xsl:variable name="menu" select="document('../xml/menu.xml')"/>
>
> <xsl:template match="/">
> <html>
> <head>
> <title>Cocoon Day 2003</title>
> <link href="style.css" rel="stylesheet" type="text/css" />
> </head>
>
> <body>
> <!-- snip: here is the html part for the navigation header -->
> <xsl:call-template name="title"/>
> <!-- end of html navigation part -->
>
> <!-- / snip here is the html part surrounding the content -->
> <xsl:apply-templates /> oder <xsl:call-template
> name="content"/>
> <!-- end of html content part -->
>
> <!-- / snip here is the html part surrounding the footer -->
> <xsl:call-template name="footer"/>
> <!-- end of html content part -->
>
> </body>
> </html>
> </xsl:template>
>
> </xsl:stylesheet>
>
>
> (2) then there are the specific stylesheets for different parts of the
> website, looking like this:
>
> <xsl:stylesheet
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> encoding="iso-8859-1"
> version="1.0">
>
> <xsl:include href="default.xsl"/>
>
> <xsl:template name="title">
> Titel
> </xsl:template>
>
> <xsl:template name="content">
> <!-- add XSL and other code to generate content part -->
> </xsl:template>
>
> <xsl:template name="footer">
> <!-- add XSL and other code to generate footer part -->
> </xsl:template>
>
> </xsl:stylesheet>
>
>
> the include includes the default stylesheet, in which the root template
> it the first to be executed. then, this root template builds the HTML
> "frame" and calls the named templates to fill in the concrete content.
>
> The main advantage is this: in the default.xsl stylesheet inside the
> root template is xhtml that can be edited with any editor e.g.
> dreamweaver. the only xsl tags are the 2 or 3 call-templates and those
> are usually ignored by html editors like dreamweaver.
>
> I use this in many projects and it works excellent also offline (with
> normal XSLT transformation e.g. using ANT).
>
> alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: html templates - best practise [ann] othello
Posted by go...@osmosis.gr.
op sorry ..
the URL: http://tools.osmosis.gr/othello/othello.gr.zip
-- stavros
On Sat, 4 Oct 2003 gounis@osmosis.gr wrote:
> hi people
> in our plans was to announce this in few weeks when the project will
> have a final state and a HowTo use Guide
>
> but considering this thread we have to show you our approach
>
> the idea was a project that can build small to medium web sites using
> cocoon
>
> the project must be template-based (so designing a different theme you can
> change the look & feel of the site) and will be able to reused without to
> touch (need to change) the sitemap.xmap
>
> for the moment we have implement cocoon i18n and a mechanism that allow
> you to create your pages writing xhtml or your own element and custom
> transformations (xml/xslt)
>
> some hits
> ---------
> in root folder are 2 files
>
> home.xhtm
> main.xhtm
>
> this files are the templates for the home (first) page and the content
> pages
>
> inside are some <osm:block-copy/> and <osm:copy/> (will be content-copy
> soon) that select the content from spesific block (/bloks/blocks.xml) or
> content files
>
> the content files are in /c_en/*.xml, /c_el/*.xml, /c_yourLang/*.xml
>
> the directory structure is designed this way to be ready for our virtual
> hostin server, considering the usage of mod_proxy, mod_rewrite
>
> installation
> -----------
>
> 1. download the zip file
> 2. extract and put [othello.gr] dir somewhere in your disk
> 3. mount othello sitemap.xmap in cocoon main sitemap.xmap
>
> othello.gr
> |
> +------conf
> | +--sitemap.xmap
> |
> +------htdocs
> +-- (all the stuff)
>
> for example
> <map:pipeline>
> <map:match pattern="*.gr/**">
> <map:mount check-reload="yes" src="file://c:/Server/xwww/{1}.gr/conf/sitemap.xmap" uri-prefix="{1}.gr"/>
> </map:match>
> </map:pipeline>
>
> or
>
> <map:pipeline>
> <map:match pattern="othello.gr/**">
> <map:mount check-reload="yes" src="file://c:/Server/xwww/othello.gr/conf/sitemap.xmap" uri-prefix="othello.gr"/>
> </map:match>
> </map:pipeline>
>
> 4. ask http://localhost:8080/cocoon/othello.gr/
>
> *** please use cocoon 2.0.4 ***
> note: in 2.1 some namespaces declaration have to change
>
> we have test all this in both unix and win platform (winXP)
> with tomcat 4.0.6 4.1.17 4.1.24
>
>
> n'joy
>
>
> please inform me for any comments or suggestion
> soon will be a list for this purpose
> for the momemnt contact me directly or using this list
> (if this usage is ON-TOPIC)
>
>
> we will make our best to see all this in the examples area of cocoon distribution
>
> --- stavros
>
> On Fri, 3 Oct 2003, Horsfield, Peter A. wrote:
>
> > One thing I think nobody has mentioned yet is the use
> > of the cocoon:/ internal pipeline call.
> >
> > Using that in conjunction with the XSLT document function means
> > you get to take advantage of Cocoon pipelines for fragments of
> > presentation or data XML, whatever format. You can also then
> > feed in the particular fragments using XSLT parameters
> > specified in the sitemap, and hence based on the request.
> >
> > The problem with using this indirection is that you may bypass a
> > little bit of the Cocoon framework. In particular, I think one
> > of the articles that someone linked too mentioned
> > that Cocoon or XSLT blindly caches the document accessed by the
> > document() function. This is obviously no good if the URI indicates
> > a resource that might change ( anyone know for sure? )
> >
> > The other XSLT issue is the way it can implicitly fall back to a
> > non-streamed approach. I suspect that carefully written XSLT will
> > maintain the SAX streaming without caching it all first. However
> > as soon as you use the document function to merge two inputs,
> > you're caching the secondary input. In general I've seen that
> > presentation XML is larger/longer than data XML which is why I
> > access data through the document() function and not presentation.
> >
> > The alternative to XSLT I've seen around is STX, streaming
> > transformations for xml, but I've not used it. Streaming/Merging
> > two SAX event streams does seem like a thorny problem at first
> > glance though.
> >
> > Also, bear in mind that as soon as you embed XHTML within your
> > XSLT directly, you limit yourself to Altova products as the only
> > IDE capable of understanding what you've done. The majority of
> > IDEs out there still spend the majority of their time trying
> > to understand the various finicky bits of HTML4 and less on
> > understanding XML namespaces.
> >
> > Regards,
> >
> > Peter
> >
> > -----Original Message-----
> > From: Alexander Schatten [mailto:alasan@gmx.at]
> > Sent: Friday, October 03, 2003 12:30 PM
> > To: users@cocoon.apache.org
> > Subject: Re: html templates - best practise
> >
> >
> > I developed a way of "callback" templates. Look at this:
> >
> > (0) consider a HTML design like this:
> >
> > +--------------------------------------------+
> > | Page Title (each page different) |
> > +--------------------------------------------+
> > | Main Navigation (for all pages the same |
> > +--------------------------------------------+
> > | |
> > | |
> > | Content (each page different) |
> > | |
> > | |
> > | |
> > +--------------------------------------------+
> > | Footer (each page different) |
> > +--------------------------------------------+
> >
> >
> > (1) first of all there is the default.xsl stylesheet it looks (very
> > reduced version) like this:
> >
> > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > encoding="iso-8859-1" version="1.0">
> >
> > <xsl:variable name="menu" select="document('../xml/menu.xml')"/>
> >
> > <xsl:template match="/">
> > <html>
> > <head>
> > <title>Cocoon Day 2003</title>
> > <link href="style.css" rel="stylesheet" type="text/css" />
> > </head>
> >
> > <body>
> > <!-- snip: here is the html part for the navigation header -->
> > <xsl:call-template name="title"/>
> > <!-- end of html navigation part -->
> >
> > <!-- / snip here is the html part surrounding the content -->
> > <xsl:apply-templates /> oder <xsl:call-template
> > name="content"/>
> > <!-- end of html content part -->
> >
> > <!-- / snip here is the html part surrounding the footer -->
> > <xsl:call-template name="footer"/>
> > <!-- end of html content part -->
> >
> > </body>
> > </html>
> > </xsl:template>
> >
> > </xsl:stylesheet>
> >
> >
> > (2) then there are the specific stylesheets for different parts of the
> > website, looking like this:
> >
> > <xsl:stylesheet
> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > encoding="iso-8859-1"
> > version="1.0">
> >
> > <xsl:include href="default.xsl"/>
> >
> > <xsl:template name="title">
> > Titel
> > </xsl:template>
> >
> > <xsl:template name="content">
> > <!-- add XSL and other code to generate content part -->
> > </xsl:template>
> >
> > <xsl:template name="footer">
> > <!-- add XSL and other code to generate footer part -->
> > </xsl:template>
> >
> > </xsl:stylesheet>
> >
> >
> > the include includes the default stylesheet, in which the root template
> > it the first to be executed. then, this root template builds the HTML
> > "frame" and calls the named templates to fill in the concrete content.
> >
> > The main advantage is this: in the default.xsl stylesheet inside the
> > root template is xhtml that can be edited with any editor e.g.
> > dreamweaver. the only xsl tags are the 2 or 3 call-templates and those
> > are usually ignored by html editors like dreamweaver.
> >
> > I use this in many projects and it works excellent also offline (with
> > normal XSLT transformation e.g. using ANT).
> >
> > alex
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org