Mailing List Archive

Firstly a big thanks for putting together Bricolage, I had just about
given up looking for a usable Perl based CMS.

Anyway, I've knocked together a prototype a system with Bricolage
providing the CMS functionality. During this process I have run into a
few questions + bugs that hopefully you can resolve (apologies if any of
these are documented on the todo list or as known bugs - I've only skip
read through these documents). In no particular order:

* The media publishing mechanism seems to break if you have a media item
with an unknown content type (I tried to publish a .gz file). It works
fine if you add the appropriate information to the media_type and
media_type_ext tables. Also, is there any reason why .gz files are
missing from the default entries (given that we have things such as
.tgz).

* There a a few typos in Bric::Biz::Asset::Business. Briefly, put
get_all_keywords() only returned the assets keywords and it's
get_source__id() no get_source_id(). I've attached a patch fixing this.
Also, the patch contains a modification to enable a slug to be specified
for a "fixed" page (I can't see any good reason as to why you can't
specify one - though I might be missing something).

* Why can't a subelement of an element be the element again. For
instance I want to define nested section containers recursively i.e

section
section
section

I've attached a patch that enables this.

* Why are elements tied to a specific burner? I can't quite see the
logic behind this. Surely, you should just assign a burner to an output
channel, thus enabling element reuse if you ever decide to use a
different burner (or want to mix and match).

* I'm not sure that the user/group authorisation mechanism is 100%
correct. At present, it isn't possible to give a user membership to the
user admin or group admin groups without also giving them the ability to
upgrade themselves to become global administrators.

I've also been playing around retrofitting an XML/XSLT burner into
Bricolage. At present, there are two parts to the burner. There is a
generator, that automatically converts an asset object into XML and
then, if any XSLT templates have been specified (via Bricolage's
templating mechanism), to apply them before outputing the results. At
present, it's build around LibXML/LibXSLT, but there is no reason why
this dependancy can't be abstracted out, so that other XSLT processors
can pluged in.

The generator simply iterates through the tree, creating XML nodes for
each element within the asset in turn. The node is generated using the
following rules:

* The node name is set to the element or field names converted to lower
case, spaces removed and anything in brackets stripped.

* Any element or field names beginning with @ are represented by
attributes.

* The story metadata is automatically inserted under the root node, with
the name info appended to the root name e.g:

<article>
<articleinfo>
<!-- story metadata here -->
</articleinfo>
</article>

* Related stories and media items are represented by xlinks

This is flexible enough for you to be able to model things such as
editing docbook documents within Bricolage (though, things such as
editing tables is a bit cumbersome).

Anyway, I've included a patch containing my progress so far. The main
thing that is currently missing is documentation and examples, which I
can easily knock together if requested. Debugging XSLT templates is/can
be painful under the current system (in part due to LibXML/LibXSLT being
particularly bad in this respect) and there is no provision for things
such as namespacing.

Also, I've had some thoughts as to how to retrofit namespacing and
greater flexibility in the auto generation of XML. Firstly, we can add
namespacing by just adding a new hidden custom field type to Bricolage.
In this we can squirrel away the namespace decalarations and any other
static data. Secondly, if we add a label property to an element (in a
similar way to a field), then we can use the name as a pseudo XPath
mapping to where the value should be inserted into the document tree,
e.g

@foo => insert as attribute of the current node
data/foo => insert <data><foo>[VALUE]</foo></data> under the
current node

Hopefully, the above makes some kind of sense... it doesn't help that
there is a real terminology problem with the use of the word element ;-)

Thanks...

Darren