All the Perl that's Practical to Extract and Report

Bricolage Content-Management and Publishing System

Simon on 2002-01-12T12:55:10

Sam Tregar writes "Bricolage is a 100% pure Perl content-management and publishing system which features intuitive and highly-configurable administration, workflow, permissions, templating, server-neutral output, distribution, and document management.

The newly released 1.2.0 adds support for HTML::Template (in addition to the existing HTML::Mason support), context-sensitive online help, an FTP interface for editing templates, support for template searches across output channels, improved media previewing behavior, and many bugfixes."

Ooh. I've been looking for one of these.

looks good.

drowsy on 2002-01-15T01:51:49

Looks like the bricolage team did a great job building on Mason, and I'm glad they chose pgsql. I'm going to use start using it now.

It reminds me a little of Roxen Platform, (http://www.roxen.com/) which uses Pike as a language. Roxen's CVS-based solution does diffs, etc... Its pretty sweet.

slash plugin?

tf23 on 2002-01-15T16:04:52

Is there a slash plugin of this? :)

pgsql

phineas0 on 2002-01-15T19:57:38

Is this postgres database? Couldn't they have just used DBI and then allow the user to choose which database they would like to use? Maybe DBI is not as "database independent" as I thought it was.

Kudos to the team for choosing HTML::Mason and mod_perl. I have found it to be a very flexible combination.

Re:pgsql

samtregar on 2002-01-15T20:18:31

Bricolage does use DBI and includes a driver interface to allow porting to other databases. That said, the only currently implemented and tested driver is for Postgres (docs). .There is a driver for Oracle included (docs) but it hasn't been tested in a long time and probably hasn't aged well.

-sam

Re:pgsql

autarch on 2002-01-15T20:27:32

DBI's interface does not change (or changes _very_ little) from one driver to another. However, SQL and the ways you can achieve certain things change quite a bit from one RDBMS to another. For example, how does one map MySQL's auto_increment column's to Postgres's serial type (or sequences in general).

Actually, that question is rhetorical. See Alzabo::Driver and its subclasses for a (partial) answer.

Anyway, these things are hard to deal with and DBI does not do all that much to mask these differences.

Re:pgsql

lachoy on 2002-01-15T22:48:41

Or see SPOPS::DBI and how it handles auto_increment/sequence/IDENTITY fields ;-)

Re:pgsql

Theory on 2002-01-18T17:06:20

Autarch is right about the portability of SQL. However, here's a little background for any dedicated hacker(s) who might want to port Bricolage to another database.

  • Initial Bricolage development was done with Oracle. That's why there is a plugin for Oracle in the sources. But Sam is right that it likely hasn't aged well. I wrote all the database interface code for Bricolage, however, and I welcome questions about how to use the subclasses to work with other databases on the Bricolage Developer's List.
  • The DTDs were written in in pretty standard SQL syntax. There are of course some PostgreSQL-specific bits, but they were written to be as standard as possible. All the PKs, for example, are standard NUMBER columns -- we steered clear of the SERIAL data type. However, porting to MySQL or SQL Server will likely be annoying, since Bricolage does use sequences.
  • There are a few (not many!) PostgreSQL functions built in. Those would have to be ported to stored procedures or your database's equivalent.
  • Most of the SQL was written in pretty standard SQL syntax. There are a few exceptions, but they could be ferreted out pretty easily by someone working on a port. There are only a few outer joins, for example.

HTH!

David