PGDN and Bricolage.

From: "Gevik babakhani" <gevik(at)xs4all(dot)nl>
To: "'Dave Page'" <dpage(at)vale-housing(dot)co(dot)uk>, "'Rod Taylor'" <pg(at)rbt(dot)ca>
Cc: <pgsql-www(at)postgresql(dot)org>
Subject: PGDN and Bricolage.
Date: 2005-06-21 21:07:08
Message-ID: 200506212107.j5LL75na080606@smtp-vbr2.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www


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(at)postgresql(dot)org [mailto:pgsql-www-
> owner(at)postgresql(dot)org] On Behalf Of Dave Page
> Sent: Tuesday, June 21, 2005 6:08 PM
> To: Rod Taylor
> Cc: pgsql-www(at)postgresql(dot)org
> Subject: Re: [pgsql-www] Volunteer wanted for PostgreSQL Techdocs
>
>
>
> > -----Original Message-----
> > From: Rod Taylor [mailto:pg(at)rbt(dot)ca]
> > Sent: 21 June 2005 14:03
> > To: Dave Page
> > Cc: pgsql-www(at)postgresql(dot)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(at)postgresql(dot)org

In response to

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Rod Taylor 2005-06-21 21:23:24 Re: PGDN and Bricolage.
Previous Message Dave Page 2005-06-21 16:07:37 Re: Volunteer wanted for PostgreSQL Techdocs