cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Burton" <>
Subject Re: Cocoon Offline mode and sitemap changes
Date Wed, 24 May 2000 11:10:02 GMT
> I'm not keen on the way CocoonOffline works, currently. At
> present, it extends Cocoon, and I think this is semantically
> dubious. I'd much rather it *used* Cocoon. Again, the reason
> it was done like this initially was (a) to get it out the door,
> and (b) to avoid having to change too much of Pier's code. Now
> Cocoon2 is a bit more open, I think we can move it over to what
> IMO makes more sense. Do you guys agree that content providers
> (servlets, offline, [something else?!]) should *use*, rather
> than extend Cocoon?

I agree.  "Use", not "extend".

>    "If it moves, abstract it; if it doesn't move, abstract
>     it anyway... Understand? Good, cos if you don't, I'm
>     gonna abstract ya."


> What do you guys think? Are the potential risks of letting
> people target whatever they want (and risking codebase bloat)
> worth it? I'm inclined to say abstract it, but don't include
> and targets other than FileSystemTarget in the base system,
> unless we're really really sure it's A Good Thing.

I'd say pluggable.  A DAV target would be very cool, then I could run the
offline gererator (can we call it OG for now?) and it would put the pages
directly on the web server.

> Again, I agree. (Stefano, could you kindly stop being right
> all the damned time? ;)

Let's summize most emails which reply to Stefano:

"Yes.  I agree"

> What I can't quite get my head around is how to actually get XLink
> into the equation. Linking one XML document to another is quite
> another thing to preserving those links through the XSLT translations
> that we're putting them through before they get to the client
> (which in the case of the offline code, happens to be a file)
> and working out what the request we need to give to the Cocoon
> object to generate the required result is.

I thnk the <source> and <view> tags which Stefano suggested are required.
We spider the source, then cache the view.  Very verbose, but I can't see
any other way of doing this.  For example, a page may begin as a file read
from fisk, then goes through XSP, then LDAP, then XSLT to XHTML then
serialized.  The source view would still need to go through the XSP and LDAP
filters, but not XHTML.

> The only answer I've come up with so far, is to 'Spider' or
> 'crawl' the site, in a similar way to my initial implemen-
> tation. If anyone can think of a better one, I'd love it,
> HintHint (any Wiki fans out there? ;).

I liked the Stylebook <book> idea for small sites, but I don't think it will
scale well at all.  I think crawling the site from a number of start points
(so that URLs which are not linked to but required are crawled too) is the
only solution.

> As Stefano has said, XLink is the answer. This would enable
> the offline processor (name please!!) to spider over the
> source XML relatively easily. The problem with this comes
> with pluggable matchers - what if one source XML file/
> generator produces a number of target documents? This might
> not seem like that likely an occourance, but Cocoon2 is
> designed to be a pretty damned serious piece of kit. I
> fully intend to be generating title images, SVG
> visualisations, and god knows what else. Some of this is
> likely to come from inline data (particularly the title
> images), and so we have to consider this

The code I was planning on writing (I was waiting for Pier's "recent"
commit) implemented the matchers, as a test I was writing IPAddressMatcher
and UserAgentMatcher.  Both are capable of turning a single request to a set
of responses.  Could be fun...


View raw message