forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [POLL] Full vs. truncated menus
Date Sat, 08 Feb 2003 09:12:17 GMT
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 }



Mime
View raw message