cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Koberg" <...@koberg.com>
Subject RE: [RT] Moving towards a new documentation system
Date Sat, 11 Oct 2003 18:53:14 GMT
Hi,

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Nicola Ken Barozzi
> Sent: Saturday, October 11, 2003 11:01 AM
> To: dev@cocoon.apache.org
> 
> 
> Robert Koberg wrote:
> 
> > First, forrest's site.xml should change the element names to something
> > generic, like:
> >
> > <site label="My Site">
> >   <page id="p34568656" label="Nico Page" url="newnicepage.html"/>
> > </site>
> >
> > So the site.xml can be validated. In its current state a custom schema
> would
> > be required for each site.xml instance -- just doesn't make sense. The
> > element names are currently being used as identifiers. Why not simply
> make
> > them valid IDs?
> 
> The question is: why validate?

More than a few reasons:

- ensure unique identifiers with the xs:ID datatype

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

- 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="file.name.length">
    <xs:restriction base="xs:NMTOKEN">
      <xs:maxLength value="255"/>
    </xs:restriction>
  </xs:simpleType>

- 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>

Etc, etc...

> 
> The schema would simply say that there are nodes and leaves. Hey, that's
> xml!
> 
> Ok, I'm partly serious and partly joking, but what I want to do is to
> make a version of site.xml that can be validated. And - hold to your
> seats - I will take Anakia's navigation.xml for this purpose. So I can
> make us render their sites *and* get validation, all in one go :-)
> 
> > Also, much more site/folder/page metadata can be applied to nodes to
> trigger
> > certain things in a transformation.
> 
> Yes, in fact what we would like to do is say if Forrest should treat
> that doc as a resource or as content to render.
> 
> > Next, why wouldn't you recommend using the site.xml as the site
> structure?
> > The site.xml should be a *virtual* representation of the site. This way
> > (with a validatable site.xml) it is easy to build a tool (in javascript)
> > that can manipulate it.
> 
> It's already the navigational structure. The left-havd navigation is
> *all* done from site.xml.
> 
> > The static site gets generated from the site.xml using the site.xml as a
> > main Source xml for a transformation. This way all nav and content links
> can
> > *always* be valid base on the virtual representation.
> 
> 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.
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...).

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.

Best,
-Rob

> 
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------


Mime
View raw message