cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <>
Subject Re: [midgard-dev] Formatting engine for Midgard
Date Thu, 15 Jun 2000 10:42:21 GMT
Hi all,

I think I should perhaps clarify the idea about combining Midgard with Cocoon.
The issue has popped up at both Midgard's and Cocoon's developer lists in
response to a mail message that Henri Bergius sent to midgard-dev and later to
cocoon-dev. The original message was inspired by a discussion I had with Henri a
couple of weeks ago.

[For background you can check for Midgard, and for Cocoon. I was the original author of Midgard,
but no longer an active developer.]

I had been studying Cocoon for a while and told Henri about the great ideas and
possibilities that Cocoon has to offer. I hadn't really thought about combining
Midgard and Cocoon as they store and process data in very different ways. Henri
however suggested the idea of combining the two methods. There was a short
discussion about the possibility of using Midgard as a Cocoon Producer and
possibly as a kind of a Formatter. This would wastly expand the different
processing and output possibilities of Midgard content.

After thinking more about this I've come to the conclusion that the benefits
would not overweight the problems associated with a such a solution. Rather I'd
like to see a solution of using Midgard-like database abstractions as a Cocoon

[The following is mostly of interest as a possible database access layer for

For example, instead of using direct SQL like in the example:

  <query connection="foo_connection">
    select name,number,message from foo_table order by name

you could use a more high-level construct like:

  <list what="messages" order="name" connection="foo_connection"/>

This way the database is handled only as an abstract repository of objects. It
would be quite a lot easier to change the details of the underlying database

I know this is quite easy to do with XSP in individual cases, but a more generic
solution would be nicer. You could have an XML file that contains a description
of the database structure. The Processor would read this file, generate and
execute the required SQL commands, and present the output embedded in semantic
tags without references to low-level database fields.


View raw message