Re: Volunteer wanted for PostgreSQL Techdocs - Mailing list pgsql-www

> -----Original Message-----
> From: Rod Taylor [mailto:pg@rbt.ca]
> Sent: 21 June 2005 14:03
> To: Dave Page
> Cc: pgsql-www@postgresql.org
> Subject: RE: [pgsql-www] Volunteer wanted for PostgreSQL Techdocs
>
>
> Okay, keeping in mind that Bricolage stores structured
> content, this is
> what I need to get started:
>
>       * All of the different content data types to be stored. An email
>         address, and some text might form a paragraph. The
> paragraph is
>         within a page with an image.  Email Address, Text Block,
>         Paragraph, Image, Page are 5 different data types. You can get
>         as specific or as vague as you like, but templating is done on
>         an individual datatype.

I'm not entirely sure what you mean. As far as the required output is
concerned, the only real datatypes are the title and the content. The
title should be enclosed in markers, (and then repeated in H1 tags),
e.g.

<!-- BEGIN page_title_block -->
This is the title
<!-- END page_title_block -->
<h1>This is the title</h1>

And the rest of the content can be structured however is required using
as-simple-as-possible CSS-free XHTML. Off the top of my head, probably
the only tags that should be used are P, H1-6, BR, EM, B, PRE, CODE, UL,
OL, LI, TABLE, TH, TR, TD, TBODY, A and IMG.

>       * The template blocks themselves. I.e. What is the common HTML
>         styling that will be applied to all paragraphs. It
> appears to be
>         "<p>$paragraph</p>", but you can go as crazy or as
> simple as you
>         like.

"<p>$paragraph</p>" is fine. The more simple, the better in fact because
we can handle all the layout and styles etc within the main website
framework.

> Yes, you can certainly change things around later or make them more
> complex, but that may also mean backtracking and reediting content.

Yup. Simplicity is good here, as essentially we only want to use
Bricolage as the content management platform. All the real formatting
will be done in the main website framework.

> For example, if you allow people to store freeform text within a
> paragraph, including HTML tags, that may restrict your ability to
> generate an RSS feed or output plain text or a WAP interface
> along side
> the standard HTML, or even the possibility of including some of the
> output in the normal docbook documentation (XML Docbook tools can pull
> information from remote sources).
>
>
> The other item is generated content. A Bricolage template has
> access to
> all of the content stored in the datastore at all times. Summaries,
> indexes, and other fully generated data segments can be created and
> outputted in any format that you can provide me with a
> template for.  So
> you need to decide if you intend to use this capability for anything.

Only really the index that Gevik is looking at - though John Hansen may
be interested in an XML feed for the search engine.

> For publishing, you've already hinted at storing the resulting data
> within CVS. This is possible, but also keep in mind that Bricolage can
> publish to remote servers (note the plural) via FTP should you wish to
> use it.

The entire site is generated from CVS and replicated to frontend servers
already. Having Bricolage's output applied to CVS allows us to keep the
entire site working that way within the existing configuration. It also
means we are effectively completely independent of Bricolage, and even
if it is unavailable for some time, we can still add frontend servers,
or update the design of the main site with ease if required.

Regards, Dave