On 8/15/06, Joern Nettingsmeier <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> [sharing joy without the slightest bit of condescension] Cool! I'm
> impressed. Cocoon is very powerful; sometimes you just need an extra
> pipeline to make it work.
is that irony? ;)
No. Pipelines are now made of steel. But grandpa can tell you about
irony. He remembers the Iron Age when everything was uphill both
ways, and spending time in Cocoon changed you into something beautiful
that could fly.
> map:mount often requires one because the
> url must be changed for the uri-prefix. And the lightning strike will
> go through me first; 1.3's Modules use that algorithm everywhere.
i'd love to hear more about that - can you post sitemap snippets?
I knew I used the algorithm of an extra match for a map:mount, but I
could not find it in the current code. It was in an early version of
the cache Module:
<map:match pattern="cache/mount/**">
<map:mount uri-prefix="cache/mount/"
src="module:///readcache.xmap"/>
<map:serialize type="html"/>
</map:match>
This was an attempt to work around the problem that map:read cannot be
used if map:generate has been called. It also required an extra XMAP.
The current code is much better.
[map:read would be really cool as a method for breaking out of the
current processing when the page is already cached, or if an error
page needs to be displayed, but the Cocoon devs decided it was easier
to throw an error than make it functional.]
You can see the current interaction between the "live" module and the
"cache" module:
http://svn.apache.org/repos/asf/lenya/branches/revolution/1.3.x/src/webapp/lenya/modules/live/module.xmap
http://svn.apache.org/repos/asf/lenya/branches/revolution/1.3.x/src/webapp/lenya/modules/cache/module.xmap
The "live" Module uses map:mount to switch to the "cache" Module. The
"cache" Module uses map:generate to call a special pipeline in the
"live" Module. That pipeline is used by the "live" Module if the
"cache" Module is not included in the pub.
i'm not sure about my solution - it does look ugly syntactically. but
it's nice from a conceptual pov, and i'd like to know whether it would
be worth it to document such "design patterns" for lenya sitemaps in
order to make them more generic, more orthogonal and easier to grasp in
the future.
Yeah. I dread trying to explain 1.3's processing. It bounces between
Modules using several algorithms. It helps if you add comments to
document each pipeline: "Allows URL to be changed for map:mount"
currently, the default publication sitemap is still irritating, since it
must know about bxe and lucene, as well as svg. not nice, but hard to
fix without changes to those modules and also to the global sitemaps.
That issue was removed for 1.3. "Live" just decides adds navigation,
with all document processing in other Modules. Caching was moved to
its own Module. Each Doctype has its own Module. I am working on
integrating Kupu in its own Module. I have no plans to integrate BXE;
someone else can do it later if it is still needed, but other
improvements may make alternate editors obsolete. Lucene will have
its own Modules: A generic "search" Module that checks which engine is
included in the pub, and a "lucene" Module with all configuration,
administration, and other code for Lucene; those are early on the TODO
list.
The goal is for each Module to be very focused on one function, while
calling other Modules (such as "live" calling "cache", "homepage", and
various Doctype Modules) if they are enabled in the Publication's
configuration.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
