PGDN and Bricolage.

Hi All,

Having spent a couple of hours playing with Bricolage and read the docs, I
find it to be a very powerful backed system for a CMS. However I was
wondering if we need all this or is there any yet simpler CMS system that
meets our needs? Bricolage being so huge I find it to be overkill.
But this is my humble opinion. My knowledge stops where perl comes in
really.

What do you think?

Regards,
Gevik.




> -----Original Message-----
> From: pgsql-www-owner@postgresql.org [mailto:pgsql-www-
> owner@postgresql.org] On Behalf Of Dave Page
> Sent: Tuesday, June 21, 2005 6:08 PM
> To: Rod Taylor
> Cc: pgsql-www@postgresql.org
> Subject: Re: [pgsql-www] Volunteer wanted for PostgreSQL Techdocs
>
>
>
> > -----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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org