Re: PGDN and Bricolage. - Mailing list pgsql-www

On Tue, 2005-06-21 at 23:07 +0200, Gevik babakhani wrote:
> 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

Very much so. Squeeze in Postgis and you can do some amazing things like
create a table of contents based on the physical proximity of other
storys to the one currently being read, or have "at this location on
this day in 1958 ..." type trivia auto-added to articles. Fun stuff.

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

The permissions management is certainly overkill, and you could drop all
of the desks except publish, but authors don't need to deal with any of
the templating or behind the scenes work.

The question is are people willing to use the Bricolage interface for
writing and maintaining articles?


If you are, just tell me what to do (how to access, samples of content,
etc.) so it can be configured into a usable fashion..


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