cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hargreaves>
Subject Re: Merging Static Source Documents
Date Thu, 10 May 2001 13:02:46 GMT
Hi Sandor,

Sandor Spruit wrote:

> Peter,
> On Wednesday, May 09, 2001, 4:52:10 PM, you wrote:
> Peter> My reasoning is this. My website has a structure which has to
> Peter> be navigated by the user. This file structure is a collection
> Peter> of xspages. But why not store that site structure as xml
> Peter> instead of as a file structure? So, I find myself wanting to
> Peter> put all my xspages into one big xml structure.
> I've the same feeling Ulrich expressed: doesn't this turn into an
> awfully large document ? Why not, for example, create an XML document
> to reflect the structure of the site, with *pointers* to the pages
> themselves. Can you say: Cocoon 2 sitemap ?

But, but, but - isn't Cocoon2 supposed to be brilliant at handling large 
Yes I am using pointers, that is why I needed to tame the xslt 
document() function.
When extracting the page from my static structure, I'm trying to process 
only the nodes that I need - i.e. avoid processing the whole structure.

Yes, I think so "Cocoon 2 sitemap", there I've said it again, and what a 
brilliant site map it is too! But seriously, I suppose you are 
suggesting that the sitemap already structures the site, so why am I 
trying to do it again? A very good question! I wonder whether it might 
be possible to extract menu information from the sitemap? Or use the 
sitemap in some way to help build the menu system? Dunno!

> Peter> This is beginning to work very well. When I request a page
> Peter> using a path into my static structure. Some logic (currently
> Peter> xslt) extracts the page from the structure. But also, very
> Peter> importantly, extracts all the choices from each node in that
> Peter> path.
> Exactly what do you mean by 'choices' ? Alternatives for a particular
> page ? A representation of the interactive UI controls to be
> associated with a node ?

The nodes that lead to my pages correspond to menu choices. I want to 
display a menu system that shows the menu choice made at each step down 
the hierarchy (e.g. about->technology->cocoon) and also shows the 
alternatives (that were not selected) at each step.

> Peter> Those choices form a sort of xml wrapper around my
> Peter> requested page. I then just simply present this wrapper of
> Peter> choices as my site navigation system. It gives me a very
> Peter> powerful and versatile menu/navigation system with minimal
> Peter> overhead.
> Hmmm. This sure sounds like option (b) from the suggestions above :)

Can't figure which is option (b) from what suggestion by whom, sorry :-( !

> Peter> I am worried that I'm missing out on some brilliant
> Peter> alternative. Your templates built from dynamic content sound
> Peter> very interesting. Maybe I can use them to prototype my pages
> Peter> before I put them into my static xml/xsp structure.
> The main issue here is, that there are many pages (say, a student's
> homepage marked-up in XML) that just need XML and stylesheets. No
> fancy XSP stuff at all.

So far, my menu system only handles static content as xml then follows 
it with xsl transformations to the target browser.  So it will already 
do the above.

> However, once lots of these pages are on a
> single site, you need some navigational or meta-data stuff added to
> it. That's an ideal XSP application, because that stuff often depends
> on the remote user, request parameters etc. Just think of a community
> site or student portal presenting our students' homepages. Those pages
> need headers showing your ID after login, maybe news headlines etc. A
> perfect match for XSP.

Yes, I too need that dynamic stuff in my menu system, so my menu nodes 
will probably include xsp tags in some way. I was intending to xsp 
process the who static page when it comes back wrapped in my menu tags. 
If there are xsp tags in the page they will get processed with the menu 
tags. If there are no xsp tags in the page then that is fine. I would 
like my menu system to be able to pick up xml or xsp files which were 
designed to stand alone with their own stylesheets.

> I use URL's like:
> <myhost>/template/homepage.xml?content=/students/peter.xml
> Where 'homepage.xml' is an XSP page creating fancy headers on the fly,
> and 'peter.xml' is some random student's personal homepage. My main
> reasons for doing this are:
> - The extra complexity of XSP pages over standard XML. I do not want
>   to ask folks to code XSP;
> - I don't want the extra overhead of XSP compilation for each and
>   every page on our site. An XSP-style template per document type
>   suffices;

Why do you consider XSP compilation to be an overhead for docs without 
xsp tags? Is it just storage costs? I wasn't going to worry about this! 
How do you avoid it when you have an xsp header? Are you using Frames? 
Do you merge documents after xsp processing?

> Peter> There is another reason I like to put all my static content
> Peter> into one structure.
> You forgot to tell, earlier on, that it's only your *static* content
> that's being stored in a single structure.
> Peter> I can put it into an xml database and treat it as dynamic
> Peter> content for my administrative web site!
> Yup. My idea too.

Great, now we're really on the same wavelength!

> Peter> In other words my admin web site will edit the static content
> Peter> of my initial web site. This of course means that my admin
> Peter> website will need its own structure of static pages!! So, the
> Peter> possibility emerges for an operational levelled structure for
> Peter> managing content!!!
> First off: where to you think I get the student's homepages from ? An
> XML database ! :)

The pages don't need to be in an XML database to be treated this way - 
could be file storage.

Why not treat your student pages as dynamic, in other words use xsp tags 
to insert them into your xsp header page? I assume that you do not edit 
them, but just pick them up from somewhere. Don't know what would happen 
if you wanted to make them xsp at a later date!

> Peter> Any comments on the above approach would be appreciated.
> Peter> If you are extracting your xspages from your dynamic data,
> Peter> surely all you get out is an empty framework in which to add
> Peter> your static content. Is this the case?
> Yeah.
> Peter> I've worked round the document() functions weaknesses quite
> Peter> successfully at last. You are probably right - it should be
> Peter> done in an xsp tag. I've tried the utils:import tag but no joy
> Peter> yet!
> The DOM level 2 API with its 'document.importNode' methods works like
> a charm for me...
> Document selectedDocument = library.get(Long.parseLong(selectedId));
> Node importedNode = document.importNode(selectedDocument.getDocumentElement(),true);
> document.getDocumentElement().appendChild(importedNode);
> (the first call retrieves a document from my XML database)
> Sandor
I'm hoping to use Prowler with Ozone <> to do my 
user management, dynamic storage and possibly static storage.


Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message