cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: info on my recent contributions in the scratchpad
Date Sat, 23 Feb 2002 10:36:47 GMT
Jeremy Quinn wrote:
> 
> At 7:22 pm +0100 22/2/02, Stefano Mazzocchi wrote:
> >I uploaded (with much problems for your compiler, sorry about that) a
> >few new components that I found very useful:
> >
> >1) ImageReader
> >2) DirectoryZipArchiver
> >3) Paginator
> 
> Great Ideas!

Thanks.

> I've been doing lots of Pagination stuff in XSLT, yea it's beastly.

Yes, it really sucks. I think that XSLT is a devil: it appears easy at
first, but then grows up as a beast. I decided to do all my non-trivial
logic back in java, where it belongs.

> I was beginning to turn to the extreme that I would store everything
> separately in the smallest size I'd ever want it (xlinked together via
> linkmaps), and pull things together rather than ever have to filter stuff
> apart.

well, might have a place, but how would you solve the issue of having
different paginating rules on the same resource based on the runtime
paramaters (say, a PDA user agent or a browser user-agent... or using
DELI CC/PP capabilities to find out screen size and so on? that's why I
think the concept of 'pagesheet' is intriguing... is uses the same
pattern as stylesheets, yet fully separates concerns between those who
decide pagination and those who decide style (even if the two have a
contract on that page space assigned to text, on the font size and so
on, even if this contract is made flexibly by the ability for
user-agents to scroll)
 
> >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
> 
> What an PaginatingGenerator, or PaginatingSource(?)

This is difficult to make abstract: generating a page out of a docbook
file 'forces' you to parse the whole thing and process it until the end
to know the number of pages. So there is no real gain.

> You need to use a Paginator on whatever source you use.

Exactly. This is why I implemented this as a transformer, in order to
allow 'decoration' of existing resources without messing with what
generated them.

At the same time, Paginator could be made cache friendly (didn't have
much time to do that) and do the same that your xlinked fragments, but
just done transparently thru the cache system.

Besides, I find the 'paginating transformer' a very simple and elegant
approach and since most of the times all the pages must be processed in
order to obtain the full page number (this is an old problem with all
paginated media, even ad-hoc DTP systems like XPress), inefficiency can
hardly be removed at this stage, but rather using caching
implementations (if the generated resource hasn't changed nor does the
pagesheet, the result of the paginator is guaranteed to be valid since
it doesn't increase the stream infoset!)

> 
> >Anyway, use them and improve on them at wish.
> 
> Will do.

kool

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message