PGDN and Bricolage. - Mailing list pgsql-www
From | Gevik babakhani |
---|---|
Subject | PGDN and Bricolage. |
Date | |
Msg-id | 200506212107.j5LL75na080606@smtp-vbr2.xs4all.nl Whole thread Raw |
In response to | Re: Volunteer wanted for PostgreSQL Techdocs ("Dave Page" <dpage@vale-housing.co.uk>) |
Responses |
Re: PGDN and Bricolage.
(Rod Taylor <pg@rbt.ca>)
Re: PGDN and Bricolage. ("Marc G. Fournier" <scrappy@postgresql.org>) Re: PGDN and Bricolage. (Kenneth Marshall <ktm@it.is.rice.edu>) |
List | 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@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