Thread: Re: 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
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
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 > > --
Rod, > The question is are people willing to use the Bricolage interface for > writing and maintaining articles? I am. And I think others will be to. If the templates are set up, submitting stuff as a writer is easy. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote: > Rod, > > >>The question is are people willing to use the Bricolage interface for >>writing and maintaining articles? > > > I am. And I think others will be to. If the templates are set up, > submitting stuff as a writer is easy. I would be willing. J > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Tue, 2005-06-21 at 15:23 -0700, Joshua D. Drake wrote: > Josh Berkus wrote: > > Rod, > > > > > >>The question is are people willing to use the Bricolage interface for > >>writing and maintaining articles? > > > > > > I am. And I think others will be to. If the templates are set up, > > submitting stuff as a writer is easy. > > I would be willing. Great. Please forward some content samples and directions on how to access this Bricolage installation so I can setup the element blocks and templates. We'll worry about Navigation later on once that structure has been decided upon.
On Tue, 21 Jun 2005, 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 > wondering if we need all this or is there any yet simpler CMS system that > meets our needs? IMHO ... just because we may not believe we "need" or "will use" all of the features today, long term we may find that we use more and more of the features as we have a better understanding of the overall system ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Gevik, I have just joined this mailing list but I have been following the development of Bricolage for a while. While Bricolage does have many many nice features that may be employed, a simple stripped down setup is extremely easy to provision and work with. Many local sites are developed using these "simpler CMS systems" and they work very well for small, constant communities of contributors. They do not scale well in general. They do not have the type of fine-grained access control in the account and workflow processes. The reduced view that normal (non-web developers) see makes generating standardized and compartmentalized content extremely easy. Yes, you can have the kitchen sink if you wish, but most users will be very happy with the pruned down view presented to normal contributors. The ability to provide a restricted set of choices can actually aid in the content production process. Ken Marshall On Tue, Jun 21, 2005 at 11:07:08PM +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 > 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 > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Tue, 2005-06-21 at 18:25, Rod Taylor wrote: > On Tue, 2005-06-21 at 15:23 -0700, Joshua D. Drake wrote: > > Josh Berkus wrote: > > > Rod, > > > > > > > > >>The question is are people willing to use the Bricolage interface for > > >>writing and maintaining articles? > > > > > > > > > I am. And I think others will be to. If the templates are set up, > > > submitting stuff as a writer is easy. > > > > I would be willing. > > Great. Please forward some content samples and directions on how to > access this Bricolage installation so I can setup the element blocks and > templates. > > We'll worry about Navigation later on once that structure has been > decided upon. Here is some example content, lmk if you need more: http://techdocs.postgresql.org/techdocs/interview-stosberg.php http://techdocs.postgresql.org/techdocs/usingpostgresqlwithdotnet.php http://techdocs.postgresql.org/guides/DiskTuningGuide http://techdocs.postgresql.org/guides/BriefGuideToNulls Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Tue, 2005-06-21 at 21:29 -0300, Marc G. Fournier wrote: > On Tue, 21 Jun 2005, 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 > > wondering if we need all this or is there any yet simpler CMS system that > > meets our needs? > > IMHO ... just because we may not believe we "need" or "will use" all of > the features today, long term we may find that we use more and more of the > features as we have a better understanding of the overall system ... Excellent. Now I just need access to Bricolage itself. Web URL, login and password with Bricolage administrative privileges.
Rod, > http://techdocs.postgresql.org/techdocs/interview-stosberg.php > http://techdocs.postgresql.org/techdocs/usingpostgresqlwithdotnet.php > http://techdocs.postgresql.org/guides/DiskTuningGuide > http://techdocs.postgresql.org/guides/BriefGuideToNulls Also, keep in mind that we're going to be pouring this into the PostgreSQL.org CSS template. So only very limited formatting needs to be done for the actual document. Here's an example of content for that template. The one other thing we'd need would be a "style" for fixed-width blocks of code. The more complex part will be building a TOC and index for these documents automatically, but that can be done after we start adding content, yes? --Josh -- Josh Berkus Aglio Database Solutions San Francisco
Attachment
Hi All, Parallel to Bricollage experimentation, I am also experimenting with drupal (http://www.drupal.org) From what I could find out up until now, it is a very powerful, easy to use and customize CMS both in front-end and back-end. The experiment is being done on http://pgdn.truesoftware.net Regrads, Gevik.
Gevik, > Parallel to Bricollage experimentation, I am also experimenting with > drupal (http://www.drupal.org) Unfortunately, Drupal isn't really designed to handle the load we're liable to place on it (right now I can't even connect ...) And it certainly can't mirror. However, I think we're getting into divergent goals. The rest of us on WWW got into replacing techdocs, which wasn't necessarily your original idea. What *are* you trying to do, again? -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Josh, > However, I think we're getting into divergent goals. The rest of us on > WWW > got into replacing techdocs, which wasn't necessarily your original idea. > What *are* you trying to do, again? No divergent goals at all, I was just investigating the possibilities. Regards, Gevik.
Gevik, In my review of open source CMS products, Drupal was also one of the products we evaluated. I concur with your assessment that it is powerful and easy to use. Its drawback with regards to our use and I suspect to its use in postgresql.org is that the CMS must run on the web presentation engine. This implies that much more horsepower and configuration expertise would be required to host the content and to mirror the content to other sites. Drupal is not alone in this regard but the ability of Bricolage to publish to any web site using any dynamic or static presentation engine is ideal for mirroring and documentation. In fact, one of my goals is to burn a static tree to DVD for DR using the multiple output channel capabilities of Bricolage (or to a Pdf...). Ken On Wed, Jun 22, 2005 at 09:12:32PM +0200, Gevik babakhani wrote: > Hi All, > > Parallel to Bricollage experimentation, I am also experimenting with drupal > (http://www.drupal.org) > > >From what I could find out up until now, it is a very powerful, easy to use > and customize CMS both in front-end and back-end. > > The experiment is being done on http://pgdn.truesoftware.net > > Regrads, > Gevik. > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)