You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Bert Van Kets <be...@vankets.com> on 2002/06/05 16:46:45 UTC
Forrest new style
Done!
I have done the following:
- add selected item to the menu
- added external tag support in the menu
- make the tabs functional
+ add tabs.xml
+ add tab2xhtml.xsl)
+ add tab-cocoon-v10.dtd
+ add tab-cocoon-v10.dtd to entity catalog
+ add pipeline to sitemap and add aggregation part to *.html and **/*.html
- sorted out most of the CSS problems (text resizing remains)
- add a label image to the menu since these are not dynamic
- replaced : with > in the path at the top
- move the "created with Cocoon" and "built with Krisalis Centipede" images
to first page
- replaced h2 with h1 for the title (Diana do I still need to add some
white space??)
What needs to be added/changed:
- make the links on the tabs independent of the build target (TMHO we need
some code here :( )
- make the top path depending on a site.xml file or some other source
- make paging work
- make the "selected item" function in sub menus (Cocoon has the same problem)
- Make the fonts scalable in CSS
- add and incorporate a CSS class to the section titles to add some white
space above them
- make the menu dynamic (least important to me and not voted yet AFAIK)
- create a PURE html version of all stylesheets without any use of CSS
- create a "build skin howto"
Don't shoot me if I forgot something, just let me know. ;-)
I think the current version is usable for the Forrest site. If we sort out
the top path and the menu selection in the sub menus it's usable for the
whole site.
Take a look a it at www.dream-models.com/xml-forrest. The zip and tar.gz
files are updated but not complete yet.
I will sort out all the files that need to be added/updated asap and commit
this evening.
Bert
This mail is written in 100% recycled electrons.
Re: Paginating Content
Posted by Robert Koberg <ro...@koberg.com>.
Here is another way to do it using javascript. It is pretty cool. (resize
the page to notice that content only shows in the viewable area)
http://iht.com/articles/60387.html
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Paginating Content
Posted by Diana Shannon <sh...@apache.org>.
*Thanks* Stefano. Coming soon to a How-To near you...
Diana
On Thursday, June 6, 2002, at 08:51 AM, Stefano Mazzocchi wrote:
> Konstantin Piroumian wrote:
>
>> Hm... Does anybody have an idea on how to paginate the content?
>
> Ok, damn it, I don't have time to make mark this up, but since it's the
> content that is useful, here's a small tutorial for the Paginator.
>
> - 0 -
>
> Paginator Transformer
> =====================
>
> classname: org.apache.cocoon.transformation.paginatation.Paginator
> location: scratchpad (available in both cocoon 2.1-dev and 2.0.3-dev)
>
> Design idea
> -----------
>
> The paginator is a 'FilterTransformer' on pagination steroids. It works
> filtering SAX events things out and counting page.
>
> The design isn't very efficient since it has to process the entire file
> to extract a single page. It works nicely with few tens of pages, but I
> would seriously suggest *against* using it for books or very big
> documents.
>
> The good news is that its cacheable, so if the document doesn't change
> and the same page is requested, there is no need to reprocess the
> document.
>
> Anyway, for static generation, all this doesn't really matter.
>
> A simple example of use
> -----------------------
>
> Suppose you have an XML file like this
>
> <a>
> <b/>
> <b/>
> <b/>
> <b/>
> <b/>
> <b/>
> <b/>
> </a>
>
> and you want to paginate this having 3 <b> elements per page. In order
> to achieve this, you write a simple "pagesheet" (which contains the
> instructions for the filter, much like a stylesheet gives instructions
> to an xslt processor) like this:
>
> <?xml version="1.0"?>
> <pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
> <rules>
> <count type="element" name="b" num="3"/>
> </rules>
> </pagesheet>
>
> then you connect the two with a sitemap snippet like this:
>
> <map:match pattern="page(*)">
> <map:generate src="document.xml"/>
> <map:transform type="paginate" src="pagesheets/images.xml">
> <map:parameter name="page" value="{2}"/>
> </map:transform>
> <map:serialize type="xml"/>
> </map:match>
>
> and accessing the URI page(1) yields
>
> <a>
> <b>
> <b>
> <b>
> <page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
> current="1"
> total="3"
> current-uri="page(1)"
> clean-uri="page"
> />
> </a>
>
> which can be easily transformed into something more meaningful.
>
> Note that the transformer processes all the pages to obtain the 'total'.
> There is no way around this.
>
> Adding navigation
> -----------------
>
> The problem with XSLT-based pagination is that the logic is very complex
> to define in XSLT and is rarely reusable across different pagination
> needs. This was the main reason for the creation of a custom components
> for this.
>
> But since we have a full blown pagesheet language, there are a few other
> things that we can make the Paginator do, most important, navigation.
>
> For example, with this other pagesheet
>
> <?xml version="1.0"?>
> <pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
> <rules>
> <count type="element" name="b" num="3"/>
> <link type="unit" num="1"/>
> </rules>
> </pagesheet>
>
> indicates that the transformer must understand how the page was encoded
> in the given URI and provide a link to the pages +/- 1 position, if they
> are available.
>
> So, using the same environment as before we get
>
> <a>
> <b>
> <b>
> <b>
> <page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
> current="1"
> total="3"
> current-uri="page(1)"
> clean-uri="page">
> <page:link page="2" type="next" uri="page(2)"/>
> </page:page>
> </a>
>
> which indicates
>
> 1) there is no page 0, so no link is created.
> 2) the link goes to page 2, the type is 'next' (useful for
> visualization) and the URI is page(2) (useful for linking without
> XSLT-specific logic).
>
> NOTE: the URI is re-encoded using the same pattern, this paginator
> assumes that the 'round brakets' are used to identify page numbering.
>
> Now, without changing anything, requesting page(2) would yield
>
> <a>
> <b>
> <b>
> <b>
> <page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
> current="2"
> total="3"
> current-uri="page(2)"
> clean-uri="page">
> <page:link page="1" type="prev" uri="page(1)"/>
> <page:link page="3" type="next" uri="page(3)"/>
> </page:page>
> </a>
>
> while page(3) would yield:
>
> <a>
> <b>
> <page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
> current="3"
> total="3"
> current-uri="page(3)"
> clean-uri="page">
> <page:link page="2" type="prev" uri="page(2)"/>
> </page:page>
> </a>
>
> NOTE: here there is only one <b> because the original document doesn't
> contain enough elements to fill the page entirely. It's the modulo of
> the division.
>
> A real-life example
> -------------------
>
> Here are a few pagesheets which are a little more complex:
>
> Paginating the results from DirectoryGenerator:
>
> <?xml version="1.0"?>
> <pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
> <rules>
> <count type="element" name="file"
> namespace="http://apache.org/cocoon/directory/2.0" num="16"/>
> <link type="unit" num="2"/>
> <link type="range" value="5"/>
> </rules>
> </pagesheet>
>
> This says:
>
> 1) paginate 16 files per page
> 2) provide me with links to +/- 1 and +/- 2 pages (when available)
> 3) provide me with linkts to +/- 5 (when available)
>
> So, suppose we have a directory with 300 files and we request page 10,
> the generated page will be
>
> <dir:directory>
> <dir:file ...>
>
> [other 15 dir:file]
>
> <page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
> current="10"
> total="19"
> current-uri="dir(10)"
> clean-uri="dir">
> <page:range-link page="5" type="prev" uri="page(5)"/>
> <page:link page="8" type="prev" uri="page(8)"/>
> <page:link page="9" type="prev" uri="page(9)"/>
> <page:link page="11" type="next" uri="page(11)"/>
> <page:link page="12" type="next" uri="page(12)"/>
> <page:range-link page="15" type="next" uri="page(15)"/>
> </page:page>
> </dir:directory>
>
> Asymmetric pagination
> ---------------------
>
> We have also the ability to indicate different rules for each page, so:
>
> <pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
> <rules page="1">
> <count type="element" name="b" num="5"/>
> <link type="unit" num="1"/>
> </rules>
> <rules>
> <count type="element" name="b" num="10"/>
> <link type="unit" num="2"/>
> </rules>
> </pagesheet>
>
> Count types
> -----------
>
> The paginator works by counting stuff. It's up to you to define what you
> want to use for counting and you do so with the attributes of the
> <count> element in the pagesheet.
>
> This element supports 2 required attributes:
>
> num="" -> a number indicating how many times the thing to count must be
> present in this page.
>
> type="" -> the type of counting that the paginator must perform. Only
> one type is currently implemented and two are currently supported.
>
> type="element" -> makes the paginator counts the startElement() SAX
> events
>
> type="chars" -> (not currently implemented!) makes the paginator
> count the chars inclued in the page.
>
> In case type="element" is used, two other attributes become useful:
>
> name="" -> the name of the element (without namespace prefix!)
>
> namespace="" -> the URI of the namespace (if not specified, the default
> NS is used)
>
> - o -
>
> Ok, from now on some RT on the future of this transformer:
>
> Using the paginator for docs
> ----------------------------
>
> I originally wrote the paginator to paginate a directory listing and it
> works great for paginating counting elements. For docs, it could be
> possible to paginate by counting sections or subsections, but this
> doesn't necessarely yield visually balanced pages (which is the reason
> for web pagination).
>
> This is why I assumed a way to count by chars, even if I didn't go as
> far as implementing it because while paginating by counting elements is
> ok (sounds trivial, but it's not! think of nesting!) paginating by
> counting chars is a real pain, due to the algorithms that must perform
> 'chunking'.
>
> I mean, assume you have a document like this:
>
> <p>this is some <strong>text</strong> that happens
> to be <em>chuncked</em></p>
> ^
> |
>
> and suppose that counting the chars leads you to the chunking point
> indicated by the arrow above. Cutting the page there results in XML
> which is not well-formed. Providing a way to 're-well-form' the XML
> truncates words. So, we must provide a way to 're-well-form' the XML
> until the first 'block-level' element is encountered (p in this case).
> But this means that the pagesheet must contain at least the list of
> 'block-delimiting' elements (and the current Pagesheet parser parser and
> object model doesn't support this notion).
>
> Result: pagination at the char-level is not trivial and requires a
> little bit of work on the transformer
>
> Nesting behavior
> ----------------
>
> If counting by chars is a pain, even counting elements is not easy.
> Assume you have this:
>
> <a>
> <b>
> <a>
> <b>
> <a>
> <b/>
> </a>
> </b>
> </a>
> </b>
> </a>
>
> and you want to paginate using one <b> per page, what do the pages look
> like? ok, I'll give you some space to think about it.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Ok, here is my solution (but I'm not sure it's the best):
>
> page 1:
>
> <a>
> <b>
> <a>
> <a/>
> </a>
> </b>
> </a>
>
> page 2:
>
> <a>
> <a>
> <b>
> <a/>
> </b>
> </a>
> </a>
>
> page 3:
>
> <a>
> <a>
> <a>
> <b/>
> </a>
> </a>
> </a>
>
> I'm pretty sure the current code is buggy someplace because for deep
> nesting like this one, it looses some SAX events someplace and ends up
> making the SAX stream non-well-formed and chocking the subsequent
> transformers which are sensible to well-formness (such as XSLT).
>
> Note: the above might look like a mental exercise to many, but if you
> think about our Document DTD 1.1, you'll find nested <section> and
> paginating those results in very similar problems. But I'm not sure if
> the solution adopted above is meaningful for a real-case pagination. I'm
> up to suggestions in on this.
>
> Improving the concept
> ---------------------
>
> One possible way to improve the concept is to count by XPath results,
> that is you might want to count by 'sections included in sections'.
>
> Also, another way to improve the system is providing booleans: you might
> want to count 'sessions AND chapters' (probably, XPath helps here as
> well).
>
> Ok, anyway, hope this helps and sorry for taking so long to write this.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> 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
Paginating Content
Posted by Stefano Mazzocchi <st...@apache.org>.
Konstantin Piroumian wrote:
> Hm... Does anybody have an idea on how to paginate the content?
Ok, damn it, I don't have time to make mark this up, but since it's the
content that is useful, here's a small tutorial for the Paginator.
- 0 -
Paginator Transformer
=====================
classname: org.apache.cocoon.transformation.paginatation.Paginator
location: scratchpad (available in both cocoon 2.1-dev and 2.0.3-dev)
Design idea
-----------
The paginator is a 'FilterTransformer' on pagination steroids. It works
filtering SAX events things out and counting page.
The design isn't very efficient since it has to process the entire file
to extract a single page. It works nicely with few tens of pages, but I
would seriously suggest *against* using it for books or very big
documents.
The good news is that its cacheable, so if the document doesn't change
and the same page is requested, there is no need to reprocess the
document.
Anyway, for static generation, all this doesn't really matter.
A simple example of use
-----------------------
Suppose you have an XML file like this
<a>
<b/>
<b/>
<b/>
<b/>
<b/>
<b/>
<b/>
</a>
and you want to paginate this having 3 <b> elements per page. In order
to achieve this, you write a simple "pagesheet" (which contains the
instructions for the filter, much like a stylesheet gives instructions
to an xslt processor) like this:
<?xml version="1.0"?>
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
<rules>
<count type="element" name="b" num="3"/>
</rules>
</pagesheet>
then you connect the two with a sitemap snippet like this:
<map:match pattern="page(*)">
<map:generate src="document.xml"/>
<map:transform type="paginate" src="pagesheets/images.xml">
<map:parameter name="page" value="{2}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
and accessing the URI page(1) yields
<a>
<b>
<b>
<b>
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="1"
total="3"
current-uri="page(1)"
clean-uri="page"
/>
</a>
which can be easily transformed into something more meaningful.
Note that the transformer processes all the pages to obtain the 'total'.
There is no way around this.
Adding navigation
-----------------
The problem with XSLT-based pagination is that the logic is very complex
to define in XSLT and is rarely reusable across different pagination
needs. This was the main reason for the creation of a custom components
for this.
But since we have a full blown pagesheet language, there are a few other
things that we can make the Paginator do, most important, navigation.
For example, with this other pagesheet
<?xml version="1.0"?>
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
<rules>
<count type="element" name="b" num="3"/>
<link type="unit" num="1"/>
</rules>
</pagesheet>
indicates that the transformer must understand how the page was encoded
in the given URI and provide a link to the pages +/- 1 position, if they
are available.
So, using the same environment as before we get
<a>
<b>
<b>
<b>
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="1"
total="3"
current-uri="page(1)"
clean-uri="page">
<page:link page="2" type="next" uri="page(2)"/>
</page:page>
</a>
which indicates
1) there is no page 0, so no link is created.
2) the link goes to page 2, the type is 'next' (useful for
visualization) and the URI is page(2) (useful for linking without
XSLT-specific logic).
NOTE: the URI is re-encoded using the same pattern, this paginator
assumes that the 'round brakets' are used to identify page numbering.
Now, without changing anything, requesting page(2) would yield
<a>
<b>
<b>
<b>
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="2"
total="3"
current-uri="page(2)"
clean-uri="page">
<page:link page="1" type="prev" uri="page(1)"/>
<page:link page="3" type="next" uri="page(3)"/>
</page:page>
</a>
while page(3) would yield:
<a>
<b>
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="3"
total="3"
current-uri="page(3)"
clean-uri="page">
<page:link page="2" type="prev" uri="page(2)"/>
</page:page>
</a>
NOTE: here there is only one <b> because the original document doesn't
contain enough elements to fill the page entirely. It's the modulo of
the division.
A real-life example
-------------------
Here are a few pagesheets which are a little more complex:
Paginating the results from DirectoryGenerator:
<?xml version="1.0"?>
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
<rules>
<count type="element" name="file"
namespace="http://apache.org/cocoon/directory/2.0" num="16"/>
<link type="unit" num="2"/>
<link type="range" value="5"/>
</rules>
</pagesheet>
This says:
1) paginate 16 files per page
2) provide me with links to +/- 1 and +/- 2 pages (when available)
3) provide me with linkts to +/- 5 (when available)
So, suppose we have a directory with 300 files and we request page 10,
the generated page will be
<dir:directory>
<dir:file ...>
[other 15 dir:file]
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="10"
total="19"
current-uri="dir(10)"
clean-uri="dir">
<page:range-link page="5" type="prev" uri="page(5)"/>
<page:link page="8" type="prev" uri="page(8)"/>
<page:link page="9" type="prev" uri="page(9)"/>
<page:link page="11" type="next" uri="page(11)"/>
<page:link page="12" type="next" uri="page(12)"/>
<page:range-link page="15" type="next" uri="page(15)"/>
</page:page>
</dir:directory>
Asymmetric pagination
---------------------
We have also the ability to indicate different rules for each page, so:
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
<rules page="1">
<count type="element" name="b" num="5"/>
<link type="unit" num="1"/>
</rules>
<rules>
<count type="element" name="b" num="10"/>
<link type="unit" num="2"/>
</rules>
</pagesheet>
Count types
-----------
The paginator works by counting stuff. It's up to you to define what you
want to use for counting and you do so with the attributes of the
<count> element in the pagesheet.
This element supports 2 required attributes:
num="" -> a number indicating how many times the thing to count must be
present in this page.
type="" -> the type of counting that the paginator must perform. Only
one type is currently implemented and two are currently supported.
type="element" -> makes the paginator counts the startElement() SAX
events
type="chars" -> (not currently implemented!) makes the paginator
count the chars inclued in the page.
In case type="element" is used, two other attributes become useful:
name="" -> the name of the element (without namespace prefix!)
namespace="" -> the URI of the namespace (if not specified, the default
NS is used)
- o -
Ok, from now on some RT on the future of this transformer:
Using the paginator for docs
----------------------------
I originally wrote the paginator to paginate a directory listing and it
works great for paginating counting elements. For docs, it could be
possible to paginate by counting sections or subsections, but this
doesn't necessarely yield visually balanced pages (which is the reason
for web pagination).
This is why I assumed a way to count by chars, even if I didn't go as
far as implementing it because while paginating by counting elements is
ok (sounds trivial, but it's not! think of nesting!) paginating by
counting chars is a real pain, due to the algorithms that must perform
'chunking'.
I mean, assume you have a document like this:
<p>this is some <strong>text</strong> that happens
to be <em>chuncked</em></p>
^
|
and suppose that counting the chars leads you to the chunking point
indicated by the arrow above. Cutting the page there results in XML
which is not well-formed. Providing a way to 're-well-form' the XML
truncates words. So, we must provide a way to 're-well-form' the XML
until the first 'block-level' element is encountered (p in this case).
But this means that the pagesheet must contain at least the list of
'block-delimiting' elements (and the current Pagesheet parser parser and
object model doesn't support this notion).
Result: pagination at the char-level is not trivial and requires a
little bit of work on the transformer
Nesting behavior
----------------
If counting by chars is a pain, even counting elements is not easy.
Assume you have this:
<a>
<b>
<a>
<b>
<a>
<b/>
</a>
</b>
</a>
</b>
</a>
and you want to paginate using one <b> per page, what do the pages look
like? ok, I'll give you some space to think about it.
Ok, here is my solution (but I'm not sure it's the best):
page 1:
<a>
<b>
<a>
<a/>
</a>
</b>
</a>
page 2:
<a>
<a>
<b>
<a/>
</b>
</a>
</a>
page 3:
<a>
<a>
<a>
<b/>
</a>
</a>
</a>
I'm pretty sure the current code is buggy someplace because for deep
nesting like this one, it looses some SAX events someplace and ends up
making the SAX stream non-well-formed and chocking the subsequent
transformers which are sensible to well-formness (such as XSLT).
Note: the above might look like a mental exercise to many, but if you
think about our Document DTD 1.1, you'll find nested <section> and
paginating those results in very similar problems. But I'm not sure if
the solution adopted above is meaningful for a real-case pagination. I'm
up to suggestions in on this.
Improving the concept
---------------------
One possible way to improve the concept is to count by XPath results,
that is you might want to count by 'sections included in sections'.
Also, another way to improve the system is providing booleans: you might
want to count 'sessions AND chapters' (probably, XPath helps here as
well).
Ok, anyway, hope this helps and sorry for taking so long to write this.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Paginating Content
Posted by Stefano Mazzocchi <st...@apache.org>.
Konstantin Piroumian wrote:
> Hm... Does anybody have an idea on how to paginate the content?
Ok, damn it, I don't have time to make mark this up, but since it's the
content that is useful, here's a small tutorial for the Paginator.
- 0 -
Paginator Transformer
=====================
classname: org.apache.cocoon.transformation.paginatation.Paginator
location: scratchpad (available in both cocoon 2.1-dev and 2.0.3-dev)
Design idea
-----------
The paginator is a 'FilterTransformer' on pagination steroids. It works
filtering SAX events things out and counting page.
The design isn't very efficient since it has to process the entire file
to extract a single page. It works nicely with few tens of pages, but I
would seriously suggest *against* using it for books or very big
documents.
The good news is that its cacheable, so if the document doesn't change
and the same page is requested, there is no need to reprocess the
document.
Anyway, for static generation, all this doesn't really matter.
A simple example of use
-----------------------
Suppose you have an XML file like this
<a>
<b/>
<b/>
<b/>
<b/>
<b/>
<b/>
<b/>
</a>
and you want to paginate this having 3 <b> elements per page. In order
to achieve this, you write a simple "pagesheet" (which contains the
instructions for the filter, much like a stylesheet gives instructions
to an xslt processor) like this:
<?xml version="1.0"?>
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
<rules>
<count type="element" name="b" num="3"/>
</rules>
</pagesheet>
then you connect the two with a sitemap snippet like this:
<map:match pattern="page(*)">
<map:generate src="document.xml"/>
<map:transform type="paginate" src="pagesheets/images.xml">
<map:parameter name="page" value="{2}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
and accessing the URI page(1) yields
<a>
<b>
<b>
<b>
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="1"
total="3"
current-uri="page(1)"
clean-uri="page"
/>
</a>
which can be easily transformed into something more meaningful.
Note that the transformer processes all the pages to obtain the 'total'.
There is no way around this.
Adding navigation
-----------------
The problem with XSLT-based pagination is that the logic is very complex
to define in XSLT and is rarely reusable across different pagination
needs. This was the main reason for the creation of a custom components
for this.
But since we have a full blown pagesheet language, there are a few other
things that we can make the Paginator do, most important, navigation.
For example, with this other pagesheet
<?xml version="1.0"?>
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
<rules>
<count type="element" name="b" num="3"/>
<link type="unit" num="1"/>
</rules>
</pagesheet>
indicates that the transformer must understand how the page was encoded
in the given URI and provide a link to the pages +/- 1 position, if they
are available.
So, using the same environment as before we get
<a>
<b>
<b>
<b>
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="1"
total="3"
current-uri="page(1)"
clean-uri="page">
<page:link page="2" type="next" uri="page(2)"/>
</page:page>
</a>
which indicates
1) there is no page 0, so no link is created.
2) the link goes to page 2, the type is 'next' (useful for
visualization) and the URI is page(2) (useful for linking without
XSLT-specific logic).
NOTE: the URI is re-encoded using the same pattern, this paginator
assumes that the 'round brakets' are used to identify page numbering.
Now, without changing anything, requesting page(2) would yield
<a>
<b>
<b>
<b>
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="2"
total="3"
current-uri="page(2)"
clean-uri="page">
<page:link page="1" type="prev" uri="page(1)"/>
<page:link page="3" type="next" uri="page(3)"/>
</page:page>
</a>
while page(3) would yield:
<a>
<b>
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="3"
total="3"
current-uri="page(3)"
clean-uri="page">
<page:link page="2" type="prev" uri="page(2)"/>
</page:page>
</a>
NOTE: here there is only one <b> because the original document doesn't
contain enough elements to fill the page entirely. It's the modulo of
the division.
A real-life example
-------------------
Here are a few pagesheets which are a little more complex:
Paginating the results from DirectoryGenerator:
<?xml version="1.0"?>
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
<rules>
<count type="element" name="file"
namespace="http://apache.org/cocoon/directory/2.0" num="16"/>
<link type="unit" num="2"/>
<link type="range" value="5"/>
</rules>
</pagesheet>
This says:
1) paginate 16 files per page
2) provide me with links to +/- 1 and +/- 2 pages (when available)
3) provide me with linkts to +/- 5 (when available)
So, suppose we have a directory with 300 files and we request page 10,
the generated page will be
<dir:directory>
<dir:file ...>
[other 15 dir:file]
<page:page xmlns:page="http://apache.org/cocoon/paginate/1.0"
current="10"
total="19"
current-uri="dir(10)"
clean-uri="dir">
<page:range-link page="5" type="prev" uri="page(5)"/>
<page:link page="8" type="prev" uri="page(8)"/>
<page:link page="9" type="prev" uri="page(9)"/>
<page:link page="11" type="next" uri="page(11)"/>
<page:link page="12" type="next" uri="page(12)"/>
<page:range-link page="15" type="next" uri="page(15)"/>
</page:page>
</dir:directory>
Asymmetric pagination
---------------------
We have also the ability to indicate different rules for each page, so:
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0">
<rules page="1">
<count type="element" name="b" num="5"/>
<link type="unit" num="1"/>
</rules>
<rules>
<count type="element" name="b" num="10"/>
<link type="unit" num="2"/>
</rules>
</pagesheet>
Count types
-----------
The paginator works by counting stuff. It's up to you to define what you
want to use for counting and you do so with the attributes of the
<count> element in the pagesheet.
This element supports 2 required attributes:
num="" -> a number indicating how many times the thing to count must be
present in this page.
type="" -> the type of counting that the paginator must perform. Only
one type is currently implemented and two are currently supported.
type="element" -> makes the paginator counts the startElement() SAX
events
type="chars" -> (not currently implemented!) makes the paginator
count the chars inclued in the page.
In case type="element" is used, two other attributes become useful:
name="" -> the name of the element (without namespace prefix!)
namespace="" -> the URI of the namespace (if not specified, the default
NS is used)
- o -
Ok, from now on some RT on the future of this transformer:
Using the paginator for docs
----------------------------
I originally wrote the paginator to paginate a directory listing and it
works great for paginating counting elements. For docs, it could be
possible to paginate by counting sections or subsections, but this
doesn't necessarely yield visually balanced pages (which is the reason
for web pagination).
This is why I assumed a way to count by chars, even if I didn't go as
far as implementing it because while paginating by counting elements is
ok (sounds trivial, but it's not! think of nesting!) paginating by
counting chars is a real pain, due to the algorithms that must perform
'chunking'.
I mean, assume you have a document like this:
<p>this is some <strong>text</strong> that happens
to be <em>chuncked</em></p>
^
|
and suppose that counting the chars leads you to the chunking point
indicated by the arrow above. Cutting the page there results in XML
which is not well-formed. Providing a way to 're-well-form' the XML
truncates words. So, we must provide a way to 're-well-form' the XML
until the first 'block-level' element is encountered (p in this case).
But this means that the pagesheet must contain at least the list of
'block-delimiting' elements (and the current Pagesheet parser parser and
object model doesn't support this notion).
Result: pagination at the char-level is not trivial and requires a
little bit of work on the transformer
Nesting behavior
----------------
If counting by chars is a pain, even counting elements is not easy.
Assume you have this:
<a>
<b>
<a>
<b>
<a>
<b/>
</a>
</b>
</a>
</b>
</a>
and you want to paginate using one <b> per page, what do the pages look
like? ok, I'll give you some space to think about it.
Ok, here is my solution (but I'm not sure it's the best):
page 1:
<a>
<b>
<a>
<a/>
</a>
</b>
</a>
page 2:
<a>
<a>
<b>
<a/>
</b>
</a>
</a>
page 3:
<a>
<a>
<a>
<b/>
</a>
</a>
</a>
I'm pretty sure the current code is buggy someplace because for deep
nesting like this one, it looses some SAX events someplace and ends up
making the SAX stream non-well-formed and chocking the subsequent
transformers which are sensible to well-formness (such as XSLT).
Note: the above might look like a mental exercise to many, but if you
think about our Document DTD 1.1, you'll find nested <section> and
paginating those results in very similar problems. But I'm not sure if
the solution adopted above is meaningful for a real-case pagination. I'm
up to suggestions in on this.
Improving the concept
---------------------
One possible way to improve the concept is to count by XPath results,
that is you might want to count by 'sections included in sections'.
Also, another way to improve the system is providing booleans: you might
want to count 'sessions AND chapters' (probably, XPath helps here as
well).
Ok, anyway, hope this helps and sorry for taking so long to write this.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Forrest new style
Posted by Robert Koberg <ro...@koberg.com>.
Hi guys,
I have been switching around my network - so very sorry if emails bounced!
----- Original Message -----
From: "Konstantin Piroumian" <KP...@protek.com>
> From: "Bert Van Kets" <be...@vankets.com>
> > > What needs to be added/changed:
> > - make the links on the tabs independent of the build target (TMHO we
need
> > some code here :( )
> > - make the top path depending on a site.xml file or some other source
> > - make paging work
>
> Hm... Does anybody have an idea on how to paginate the content? I know how
> to do it when pages are placed in separate files, but how to split an XML
> file into pages and keep it well-formed? It's definitely time to have a
look
> at Stefano's paginating transformer.
>
If you can use a true site map you could do something like:
<xsl:template match="page" mode="snailtrail">
<xsl:apply-templates select="parent::folder" mode="snailtrail"/>
<xsl:value-of select="@label"/>
</xsl:template>
<xsl:template match="folder" mode="snailtrail">
<xsl:variable name="index_id" select="@index_page"/>
<xsl:variable name="index_page" select="page[@id=$index_id]"/>
<xsl:variable name="style_fileref">
<xsl:choose>
<xsl:when test="$index_page/@xsl_fileref='default' or
not(boolean($index_page/@id))">
<xsl:value-of select="@xsl_fileref"/>
</xsl:when>
<xsl:when test="$index_id='empty'">
<xsl:text>body_empty-folder.xsl</xsl:text>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$index_page/@xsl_fileref"/>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:variable name="_href">
<xsl:apply-templates select="parent::folder"
mode="snailtrail_path"/>
<xsl:text>/</xsl:text>
<xsl:value-of select="translate(@name, ' ', '_')"/>
<xsl:text>/</xsl:text>
<xsl:value-of select="translate($index_page/@label, ' ', '_')"/>
<xsl:value-of select="$index_page/@file_ext"/>
</xsl:variable>
<xsl:apply-templates select="parent::folder" mode="snailtrail"/>
<a href="{$_href}">
<xsl:value-of select="@label"/>
</a>
<xsl:text> : </xsl:text>
</xsl:template>
<xsl:template match="folder" mode="snailtrail_path">
<xsl:apply-templates select="parent::folder" mode="snailtrail_path"/>
<xsl:text>/</xsl:text>
<xsl:value-of select="translate(@name, ' ', '_')"/>
</xsl:template>
Re: Forrest new style
Posted by Bert Van Kets <be...@vankets.com>.
At 00:41 6/06/2002 +0400, you wrote:
>From: "Bert Van Kets" <be...@vankets.com>
>
>
> > Done!
>
>Well done, Bert!
>
>Again a little buzz from me:
> - the top level 'forrest' link has some 's' letter after the link
> - another mysterious 'S' appears above the first tab
Darn, My left Ctrl key is acting up, so I guess I must have tried to save
twice there. I'll remove them asap. Sorry.
> - I don't much like the new colors for visited and active links - the
>first is a little out of the all color theme of the site, the second is too
>dark and don't differ much from the content black text (this one is a matter
>of taste, so feel free to ignore)
No, please give me an alternative. I was inpired by the page.html (you
know where)
>Now we definitely need a better book.xml and some cleanup in current books
> - do we need 'HowTos' in menu when we have a HowTos tab?
> - the same for 'xml.apache.org'
My thoughts exactly, I just didn't want to remove them just yet.
> - using the current HowTo directory structure we should duplicate the
>same book.xml for all howto entries, otherwise menu will be of not much use,
>e.g. :
>http://www.dream-models.com/xml-forrest/community/howto/cvs-ssh/howto-cvs-ss
>h.html (here I'd prefer to see the parent menu with highlighted current
>HowTo menu item).
How about 1 book.xml for all current how-to's? There's too much
separation. Doesn't do much good to the usability of the site.
> > I have done the following:
> >
> > - add selected item to the menu
> > - added external tag support in the menu
> > - make the tabs functional
> > + add tabs.xml
> > + add tab2xhtml.xsl)
> > + add tab-cocoon-v10.dtd
> > + add tab-cocoon-v10.dtd to entity catalog
> > + add pipeline to sitemap and add aggregation part to *.html and
>**/*.html
> > - sorted out most of the CSS problems (text resizing remains)
> > - add a label image to the menu since these are not dynamic
> > - replaced : with > in the path at the top
> > - move the "created with Cocoon" and "built with Krisalis Centipede"
>images
> > to first page
> > - replaced h2 with h1 for the title (Diana do I still need to add some
> > white space??)
> >
> > What needs to be added/changed:
> > - make the links on the tabs independent of the build target (TMHO we need
> > some code here :( )
> > - make the top path depending on a site.xml file or some other source
> > - make paging work
>
>Hm... Does anybody have an idea on how to paginate the content? I know how
>to do it when pages are placed in separate files, but how to split an XML
>file into pages and keep it well-formed? It's definitely time to have a look
>at Stefano's paginating transformer.
yep, just soo little time at the moment. Any takers, pllllleaeaeaeaese??
> > - make the "selected item" function in sub menus (Cocoon has the same
>problem)
>
>Having a consolidated book.xml should solve this problem, isn't it?
I don't know, haven't considered this solution. Got to take a look at it
and try.
> > - Make the fonts scalable in CSS
> > - add and incorporate a CSS class to the section titles to add some white
> > space above them
>
>I'd also make them bold.
We can try that.
> > - make the menu dynamic (least important to me and not voted yet AFAIK)
>
>AFAIR, I was the only seconder of dynamic menu (if you mean JS-dynamic). My
>proposal was aimed at lengthy documents with multiple
>chapters/sections/pages. Currently, I don't see a need for dynamic menu:
>menus are too short and has only two levels and it'll be useless to make
>them show/hide-able.
Indeed, but if you look at what was intended in the original design, there
are a LOT of levels. Is this a real life sample.
I was thinking about creating dynamic book2html stylesheet that creates a
dynamic DHTML menu. The main problem is I would have to use div and span
layers and there are a LOT of browsers out there that won't be too happy
about that (Opera for one).
Let's put the dynamic menu on hold for now.
> > - create a PURE html version of all stylesheets without any use of CSS
> > - create a "build skin howto"
> >
> > Don't shoot me if I forgot something, just let me know. ;-)
>
>We don't shoot anybody here, don't be afraid ;) and seems that you haven't
>forgotten anything that is relevant for the first time.
>
>Thanks for the good work!
>
>Konstantin
>
> >
> > I think the current version is usable for the Forrest site. If we sort
>out
> > the top path and the menu selection in the sub menus it's usable for the
> > whole site.
> >
> > Take a look a it at www.dream-models.com/xml-forrest. The zip and tar.gz
> > files are updated but not complete yet.
> > I will sort out all the files that need to be added/updated asap and
>commit
> > this evening.
> >
> > Bert
> >
> >
> > This mail is written in 100% recycled electrons.
> >
Re: Forrest new style
Posted by Konstantin Piroumian <KP...@protek.com>.
From: "Bert Van Kets" <be...@vankets.com>
> Done!
Well done, Bert!
Again a little buzz from me:
- the top level 'forrest' link has some 's' letter after the link
- another mysterious 'S' appears above the first tab
- I don't much like the new colors for visited and active links - the
first is a little out of the all color theme of the site, the second is too
dark and don't differ much from the content black text (this one is a matter
of taste, so feel free to ignore)
Now we definitely need a better book.xml and some cleanup in current books
- do we need 'HowTos' in menu when we have a HowTos tab?
- the same for 'xml.apache.org'
- using the current HowTo directory structure we should duplicate the
same book.xml for all howto entries, otherwise menu will be of not much use,
e.g. :
http://www.dream-models.com/xml-forrest/community/howto/cvs-ssh/howto-cvs-ss
h.html (here I'd prefer to see the parent menu with highlighted current
HowTo menu item).
> I have done the following:
>
> - add selected item to the menu
> - added external tag support in the menu
> - make the tabs functional
> + add tabs.xml
> + add tab2xhtml.xsl)
> + add tab-cocoon-v10.dtd
> + add tab-cocoon-v10.dtd to entity catalog
> + add pipeline to sitemap and add aggregation part to *.html and
**/*.html
> - sorted out most of the CSS problems (text resizing remains)
> - add a label image to the menu since these are not dynamic
> - replaced : with > in the path at the top
> - move the "created with Cocoon" and "built with Krisalis Centipede"
images
> to first page
> - replaced h2 with h1 for the title (Diana do I still need to add some
> white space??)
>
> What needs to be added/changed:
> - make the links on the tabs independent of the build target (TMHO we need
> some code here :( )
> - make the top path depending on a site.xml file or some other source
> - make paging work
Hm... Does anybody have an idea on how to paginate the content? I know how
to do it when pages are placed in separate files, but how to split an XML
file into pages and keep it well-formed? It's definitely time to have a look
at Stefano's paginating transformer.
> - make the "selected item" function in sub menus (Cocoon has the same
problem)
Having a consolidated book.xml should solve this problem, isn't it?
> - Make the fonts scalable in CSS
> - add and incorporate a CSS class to the section titles to add some white
> space above them
I'd also make them bold.
> - make the menu dynamic (least important to me and not voted yet AFAIK)
AFAIR, I was the only seconder of dynamic menu (if you mean JS-dynamic). My
proposal was aimed at lengthy documents with multiple
chapters/sections/pages. Currently, I don't see a need for dynamic menu:
menus are too short and has only two levels and it'll be useless to make
them show/hide-able.
> - create a PURE html version of all stylesheets without any use of CSS
> - create a "build skin howto"
>
> Don't shoot me if I forgot something, just let me know. ;-)
We don't shoot anybody here, don't be afraid ;) and seems that you haven't
forgotten anything that is relevant for the first time.
Thanks for the good work!
Konstantin
>
> I think the current version is usable for the Forrest site. If we sort
out
> the top path and the menu selection in the sub menus it's usable for the
> whole site.
>
> Take a look a it at www.dream-models.com/xml-forrest. The zip and tar.gz
> files are updated but not complete yet.
> I will sort out all the files that need to be added/updated asap and
commit
> this evening.
>
> Bert
>
>
> This mail is written in 100% recycled electrons.
>