cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Moving towards a new documentation system
Date Sat, 11 Oct 2003 21:34:55 GMT
Robert Koberg wrote:
<about forrest's site.xml:>

>>The question is: why validate?
> More than a few reasons:
> - ensure unique identifiers with the xs:ID datatype

good point

> - ensure valid id references with xs:IDREF for things like:
> <site id="" index_page=" p1234">
>   <page id="p1234"/>
>   <page id="p1235"/>
>   <folder id="f1234" index_page="p1236">
>     <page id="p1236"/>
>     <page id="p1237"/>
>   </
> </

hmmm, interesting...

> - use schematron or simply an XSLT (with document()) to ensure all internal
> links are valid (<link idref="p1234">a link</link>)
> - use simple types to do things like:
>   <xs:simpleType name="">
>     <xs:restriction base="xs:NMTOKEN">
>       <xs:maxLength value="255"/>
>     </xs:restriction>
>   </xs:simpleType>

not really needed ATM I think...

> - transform the schema to user interface forms, form elements and validating
> javascript. For example, something like the following could have it's
> pgstatus attribute transformed to a select dropdown and the generate attr to
> a radio button yes/no pair:
>   <xs:complexType name="FileNode">
>     <xs:complexContent>
>       <xs:extension base="lsb:SiteNode">
>         <xs:attribute name="generate" type="xs:boolean" use="required"/>
>         <xs:attributeGroup ref="lsb:name.attr"/>
>         <xs:attribute name="pgstatus" use="required">
>           <xs:simpleType>
>             <xs:restriction base="xs:NMTOKEN">
>               <xs:enumeration value="hold"/>
>               <xs:enumeration value="publish"/>
>               <xs:enumeration value="archive"/>
>               <xs:enumeration value="obsolete"/>
>             </xs:restriction>
>           </xs:simpleType>
>         </xs:attribute>
>       </xs:extension>
>     </xs:complexContent>
>   </xs:complexType>

Interesting, although it's more for future applications.

> Etc, etc...

Ok, it seems that there are very interesting points.

I would add mine: I found site.xml very ackward to edit lately, and had 
a hard time in defining the tab attributes in site.xml. I reckon that 
the use of elements as names is partly to blame.

In any case, as I told you, I really will add navigation.xml as a 
site.xml alternative, so that the above can be done with it.

Then we'll see what of the two gets more use.

>>Yes, this happens, but with a twist: the links in site.xml get
>>translated to the ones that are in the real content.
>>Hence I'm writing now a sourcemap, that makes it possible to decouple
>>Forrest from the sources, and build a virtual source space.
>>Oh well, there is a lot of work to do, and I've just begun (*)!
>>(*) getting off projects I went to the core, and finally I'm free to
>>think and code again! :-)
> I will try to give you something to chew on. Here is an example page (our
> homepage):
> <site css="default.css" id="wwwuser" index_page="p1395893912" onnav="0"
> xsl="default">
>   <label>Site</label>
>   <title>liveSTORYBOARD Content Management System: </title>
>   <page css="inherit" generate="1" id="p1395893912" name="Welcome.html"
> onnav="1" pgstatus="publish" print_friendly="0" xsl="homepage">
>     <label>Home</label>
>     <title>Simple, powerful and secure hosted Web Content Management</title>
>     <regions>
>       <region name="wide_col">
>         <item ref="a1095201465"></item>
>         <item ref="c404932357"></item>
>       </region>
>       <region name="narrow1_col">
>         <item ref="c1109515213"></item>
>         <item ref="c108879656"></item>
>       </region>
>     </regions>
>   </page>
> </
> Note the /site/page/regions/region elements. The region/@name reference a
> page layout identifier like div/@id. The //region/item/@ref references an
> XML document in a content repository.
> I currently call these in transformation using the document function.

Hmmm, wait a sec, you are basically using site.xml to drive the site 
generation... the current site.xml would eventually do the same till the 
page tag, but without the things you put in that tag.

What I would do instead, is to make a welcome.xml page and write inside 
it the xincludes I need... but wait, you say that the name is the page 
layout identifier... what's a page layout identifier?

What does the above thing in practice generate as a result?

> Recently, I have been playing around with a XincludeFilter that does this
> prior to transformation (I assume this is the route you would take :). It is
> just that it is proving to be slower and more memory intensive for some
> reason (I am probably doing wrong...).

IIRC cinclude is more appropriate for server-side includes, and is also 
cacheable (don't remember if they made xinclude cacheable yet).

> Use the site.xml in a ContentHandler or a class that traverses the site.xml
> as a JDOM Element (or whatever) to generate the static pages. Our site is
> approaching 500 pages (most with print friendly versions) and it takes 6-8
> seconds to generate everything.

Wait a sec, you generate the whole 500-page site with Cocoon (or just 
xslts?) in 8 seconds? I mean all the pages?

Gosh, it's not fair, I have to sleep now and you got my brain thinking! ;-P

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message