forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: new community section
Date Sat, 25 May 2002 09:26:30 GMT
Diana Shannon wrote:
> Konstantin Piroumian wrote:
> > Is this intended to be a new 'Community' tab in the tabbed menu
> > (near the 'Home')?
> Could be, no thoughts on that.

At the moment it is just hooked up from the "Document Samples"
part of the front menu. The current intention is to show
work-in-progress on developing the howto-v10.dtd and that
stylesheet. I gather that later this could turn into actual 
documentation that applies to all projects in common.

> >>       - tutorial
> >>       - snippet
> >>       - howto
> >>          - book.xml
> >>          - index.xml
> >
> > What's the conceptual difference between index.xml and book.xml? One of
> > these can be generated automatically from the other, isn't it? Or both 
> > can be generated using the same source.
> Yes, this would be ideal. I didn't want to do too much, in anticipation 
> of Steven's DirectoryGenerator-on-steroids.

The index.xml is an overview-type page for the section,
whereas the book.xml is the actual menu items. They do not
have anything to do with each other.

> >
> >>           - bugzilla-patch
> >>               - book.xml
> >>               - howto-bugzilla-patch.xml
> >>               - revision-howto-bugzilla-patch-2002-10-1.xml
> >
> > I don't much like the idea of directory-like file names, isn't
> > it better to have a 'revsions' directory and place all the
> > revisions there.
> I've had it both ways. I don't care, either way. However, the revisions 
> directory should go in the individual howto diretory, IMO.

To get started, i have done it the way Diana has it.

> >  It's also
> > possible that there be more then one revision in one day and some other
> > identifier will be needed to identify the file.
> It can handle multiple revisions for a single page. They just need to 
> start with revision-<filename>-<unique trailer>.xml. I use "starts-with"

> in the stylesheet directory2revisions to grab revisions per page.
> >>              - my-images
> >
> > Why not simply 'images'?
> If you keep it images, then there's a conflict with other sitemap 
> pipelines for skin-related images. In other words, if you change it to 
> images, then you get broken links for header and other graphics. Try it. 
> You'll see what I mean.

Perhaps some clever person can tweak the sitemap. There are
various matches for images, that may be able to be consolidated.
It would be nice to be able to allow images in the same level
as the documents themselves. This was discussed in another thread.

> > HowTos can be quite short and simple documents without additional 
> > images or
> > so and having a separate directory for every case is a little 
> > superflous.
> > Can there be several HowTos in the same directory?
> I don't think this is a good idea. I'm trying to keep it modular, to 
> ease future additions and revisions for both authors and committers. I 
> really want the check for revisions to be automatic. If you have loose 
> individual howto files, then their associated revisions files will 
> really clutter up the howto directory.

This "feedback revisions" method is an interesting approach.
Clever sitemap work Diana. I gather that it will allow a place
to put feedback snippets until they are attended to. This does
not prohibit the normal method of simply sending patches to the
actual documents. Some patches will be applied directly, whereas
others are added as "revision-*.xml" files. Is that how you see
it working?

I noticed something strange with the generated date for each
revisions links ... they always have the actual date from when the
document was built, rather than the date that the revision-*.xml
was edited. I presume that the date is produced by the
directory-generator which gets the filesystem date of when the
file was copied into the build space. Maybe the build process
needs to preserve the filesystem permissions when it copies
the files.

Also, the generated date should be YYYY-MM-DD rather than the
confusing DD/MM/YY or is it MM/DD/YY


View raw message