Le 23 janv. 06, à 08:40, Peter Neu a écrit :
...Reading through the cocoon documentation and browsing for examples
I did not
find much reference on how to build the classic web app. Meaning: how
to
divide all content header, footer, etc into serate parts..
"parts" in Cocoon usually translate to pipelines - what I do in such
cases is to have one pipeline (=one matcher) for the menu, one for the
content, one for the footer, etc.
Then you aggregate the whole thing with map:aggregate, and you get a
"big" XML document which knows everything there is to know about your
page, its environment, who's requesting it, etc. Each part is cleanly
separated in its own pipeline, testable in isolation.
Something like
<map:match pattern="publicpages/**">
<map:aggregate element="page">
<map:part src="cocoon:/menu-part/{1}"/>
<map:part src="cocoon:/header-part/{1}"/>
<map:part src="cocoon:/footer-part/{1}"/>
<map:part src="cocoon:/content-part/{1}"/>
<map:part src="cocoon:/user-info-part/{1}"/>
<map:part src="cocoon:/site-config-part/{1}"/>
<map:part src="cocoon:/moon-phase-part/{1}"/>
etc...
</map:aggregate>
...transform etc.
</map:match>
I think you're right that we don't have such samples, and bricks-cms is
too basic in this area to be very interesting. For more substantial
examples you might want to look at what the Forrest, Lenya or Daisy
folks are doing - these guys have been using Cocoon for quite a while
now so they certainly have good real-world examples.
...Question II
I like the concept of event handlers you introduced in version 2 of the
Form.js. I realized though that the examples working with the version
1 of
Form.js are not working with version 2 and vice versa. So is version 2
meant
to be used for good or is it a toy which will disappear in future
releases? ..
I don't enough enough about this specific feature to comment on it, but
yes the idea is to keep v1 only. Dunno if anyone is planning to
backport this feature.
-Bertrand
