Steven Noels wrote:
> Sylvain Wallez wrote:
>
>> Basically, the purpose was to produce navigation and decoration on a
>> hole site composed of a hierarchy of "content" HTML pages. By
>> content, I mean that the directory structure reflects the navigation
>> tree, and that HTML is not styled. No xdoc DTD, no book.xml to update
>> : just start Mozilla composer, write your stuff in wysiwyg mode, save
>> it a the right place and it automagically appears in the navigation.
>
>
> Yeah, exactly what I have done a long-long time ago for the
> Outerthought website. I went for XML, though, but the kind of XML
> which is basically very HTMLish, and the XSLT copying across all
> undeclared/unknown elements verbatim. So I ended up editing XHTML-like
> files. Wellformedness is a hard requirement in my book though.
>
>> The navigation tree is obtained by traversing the whole tree
>> (directory generator), and getting the<title> tag of every HTML file,
>> which becomes the menu entry for that page.
>
>
> Welcome to the origin of 'yer' which has been repackaged into a Cocoon
> generator called 'libre' (mind the pun on 'book'):
> http://forrestbot.cocoondev.org/sites/xml-forrest/libre-intro.html
>
> Yer traversed directory hierarchies and generates an XML tree
> representation out of it. No caching, though, or it must be that Marc
> has added this.
I tried Libre at the time I had to do this demo, but failed to have it
generate something and gave up because of lack of time. So I ended with
some document() in XSL (yeah, you may find it ugly, but it worked).
I guess some heavy simplification of Libre could be possible when the
new Source/TraversableSource are stabilized in Excalibur (will delegate
abstraction of filesystem to the SourceResolver).
>> This navigation tree is correlated with the requested URI so that
>> parent directories are marked as "in path" and the current page as
>> "requested". This allows to display in the tree only the ancestors of
>> the current page and their siblings, along with the immediate
>> children of the current page. This also allows to easily get the path
>> to the current page (breadcrumb ?).
>
>
> Hehe - how about this collection of URLs which are collated into one
> page:
>
> page: http://outerthought.org/cocoon/gettogether/speakers
> parts: http://outerthought.org/cocoon/catoc/gettogether/speakers
> http://outerthought.org/cocoon/cayahoo/gettogether/speakers
> http://outerthought.org/cocoon/cacontent/gettogether/speakers.xml
Well, looks strangley to what I have in my demo...
> All this with only some simple page aggregation (which I consider now
> to be deprecated:
> http://blogs.cocoondev.org/stevenn/archives/000496.html (didn't
> survive the Radio->MT conversion very well).) Node hightlighting and
> expanding/collapsing done in XSLT as you describe.
I'm not considering aggregation as a wrong thing : it has the important
benefit of showing in the sitemap what parts compose the final page.
That's mainly a matter of taste, IMO.
> How very nice (and comforting) to see the coincidences in our
> approach. These were my first (not nearly) serious experiments with
> Cocoon2, dated somewhere early 2001. We're getting old :-)
Well, my demo was in october last year. I'm not that old, after all ;-))
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
|