I uploaded (with much problems for your compiler, sorry about that) a
few new components that I found very useful:
1) ImageReader: this is a reader which is able to scale images depending
on parameters.
This is a sitemap fragment that works on it
<!--+
| Creates a thumbnail for the requested images, using a special
| extension of the form .(*x*), for example .(10x20) or .(0x80).
| When the 'zero' value is used, it indicates that this side
should
| be resized according to original aspect ratio of the images.
So,
| for example, if an image is originally 200x100, asking for
.(50x0)
| gives a picture of 50x25, while asking for .(0x50) gives
100x50.
| Asking for 0x0 or negative numbers is not meaningful.
|
| The parameter "expire-time" indicates how many (milliseconds)
the
| image is expected to live. The higher you set this value, the
least
| requests for images you'll get, since images will be cached by
proxies
| or local browser caches and will avoid asking you again for
recreating
| the image, which is a rather CPU and memory intense operation
(even
| if cocoon itself adds a caching layer on this). So, use a low
value
| if your images change frequently, a higher value if they do
not.
+-->
<map:match pattern="**.jpg.(*x*)">
<map:read type="image" src="{1}.jpg">
<map:parameter name="width" value="{2}"/>
<map:parameter name="height" value="{3}"/>
<map:parameter name="expire-time" value="1000000"/>
</map:read>
</map:match>
I've found this *extremely* easy to use and useful for creating
thumbnails or normalizing the site of uploaded images (yes, this is part
of my long-time-due image gallery)
2) DirectoryZipArchiver
This is another read that is able to generate a zip archive of the
content of a particular directory
<!--+
| Produces a zipped archive containing all the files in the
| requested folder (if any).
+-->
<map:match pattern="**/archive.zip">
<map:read type="archiver" src="{1}"/>
</map:match>
useful to generate archives without having to generate them on the disk
(not that this is very fast and light because doesn't store anything in
memory, so you can create archives or Gb without problems... I've tested
it up to 200Mb), useful to save space on your server disk.
3) Paginator
the paginator is a special filter transformer that 'paginates' your
input depending on a 'pagesheet' a sort of stylesheets for pages that
contains the paginating rules.
This is an example pagesheet
<?xml version="1.0"?>
<pagesheet xmlns="http://apache.org/cocoon/paginate/1.0";>
<items>
<group name="tables" element="table" namespace="..."/>
<group name="figures" element="figure" namespace="..."/>
</items>
<rules page="1">
<count type="element" name="section" namespace="..." num="3"/>
<link type="unit" num="1"/>
<link type="range" value="10"/>
</rules>
<rules>
<count type="element" name="section" namespace="..." num="4"/>
<link type="unit" num="1"/>
</rules>
</pagesheet>
it might paginate one item at a time (using the item groups you can have
more than one groups of items, say figures and tables on a book) or
paginate couting elements in a particular namespace.
The above pagesheet says:
1) there are two group items 'tables' and 'figures'
2) on the first page, count '3' section elements and stop
3) give a link to the next page
4) give link to the +10 page
5) on all the other page, count '4' sections elements
6) and give a link to the next and previous page (if available)
So given a sitemap like this
<map:match pattern="books/*(*)">
<map:generate src="{1}.xml"/>
<map:transform type="paginate" src="book.pagesheet">
<map:parameter name="page" value="{2}"/>
</map:transform>
<map:serialize type="xml"/>
</map:match>
where books/book.xml is
<book>
<section/>
<section/>
<section/>
<section/>
<section/>
<section/>
<section/>
<section/>
<section/>
<section/>
<section/>
</book>
if you asked for book/book(2) you would get
<book xmlns:page="http://apache.org/cocoon/paginate/1.0";>
<section/>
<section/>
<section/>
<section/>
<page:page current="2" total="3" current-uri="book(2)"
clean-uri="book">
<page:link type="prev" page="1" uri="book(1)/>
<page:link type="next" page="3" uri="book(3)/>
<page:page>
</book>
that you can later XSLT-transform for your paginating needs.
Note that I used the 'resource(page)' URI scheme which I find very
elegant and straightforward.
Note also that all the logic to know if the page is the last one and all
those checks are done by the paginator so you can free your XSLT
stylesheets from that stinky logic.
NOTE: the paginator concept is very powerful but I didn't have time to
improve on it so I donated it instead of leaving it on my harddisk to
collect digital dust. In theory, the pagesheet semantics is powerful
enough (and there are stubs in the code for that!) to do pagination
based on counting the characters included in particular elements, so
that better forms of pagination can be done for textual documents.
Unfortunately, the pagesheet.java code is *VERY* ugly and very badly
written, it is very likely that it looses some SAX events here and there
and you get weird NPE out of Xalan if you post-transform the pages.
At the same time, I think the concept is quite powerful, even if it is
somewhat inefficient since it filters out things instead of generating
them propertly
Anyway, use them and improve on them at wish.
Hope you'll find them useful.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
