Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 73003 invoked by uid 500); 7 Apr 2003 06:42:39 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 72990 invoked from network); 7 Apr 2003 06:42:37 -0000 Received: from mx-2.csir.co.za (HELO wabe.csir.co.za) (146.64.10.166) by daedalus.apache.org with SMTP; 7 Apr 2003 06:42:37 -0000 Received: from CS-IMO.CSIR.CO.ZA ([146.64.10.94]) by wabe.csir.co.za (8.11.6/8.11.6) with ESMTP id h376f7608059 for ; Mon, 7 Apr 2003 08:41:08 +0200 Received: from GW-IMO-MTA by CS-IMO.CSIR.CO.ZA with Novell_GroupWise; Mon, 07 Apr 2003 08:41:07 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.2 Date: Mon, 07 Apr 2003 08:40:55 +0200 From: "Derek Hohls" To: Subject: RE: seperating content structure and style Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_4916EB93.3C5D2BF0" X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=1.4, required 9, HTML_FONT_COLOR_BLUE, SPAM_PHRASE_00_01, SPAM_REDIRECTOR) X-MailScanner-SpamScore: s X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --=_4916EB93.3C5D2BF0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Kris/Argyn It seems that this is a topic that comes up again and again on this list - everyone that tackles it comes up with an approach that is similar to, but slighltly different from, each of the others ... I have also had a go at creating a structure which I call a "DBreport" layout which has worked for me (so far). Do you - and any other lurkers (sorry, "interested readers") think there is any merit in trying to collate/synthesise such efforts into something which can be developed and maintained by the community as a whole; rather than the wheel being reinvented each time - I am sure that, as in all these projects, each person could being some very useful insights that will improve "the whole". We could start on the wiki as a "quick and easy" central location before having to register any kind of formal project... Thanks Derek >>> akuketayev@cox.net 05/04/2003 01:35:19 >>> Kris, this sounds very familiar to me. Once I had to make a reporting module with PDF generation. When I looked at the existing reports (about 50-60 of them), I found out that they are all (surprise!) similar :) Actually, now I think that I found an example of self-similar fractals in reporting domain, maybe I can claim for Turing award :) Seriously, after few hours of thinking I came to conclusion that they all can be constructed with a limited number of elements, which can be nested and combined. I called them "layoutlets". By nesting and joining 3-4 layoutlets, one can generate unlimited variety of report layouts. As far as I remember, I identified three main structural layoutlets for my reports: list, vertical-list and table. I also had some other stuff, like row, column, multi-line row etc. So, when I extracted data from DB, I put it into content XML. Something like: Wow Meow This has a nested resultset. Next step was to write stylesheet which makes as you call it "structural" XML, I called it layout sheet. This would use my layoutlets, which are defined as templates in a separate stylesheet library (I called it generic). Example:

The above template uses "row-list" layoutlet to render the "master" resultset. "row-list" template is defined in generic layoutlet library. I can cimply change this layoutlet, and all reports will be affected. "row-list" renders coumns of the row as a vertical list using XSL-FO. At the end I get XSL-FO file and make PDF out of it using FOP or something else. So, the report specifi stylesheet only has to map resultsets in content XML to appropriate layoutlets (generic templates). What's interesting is that layoutlets are orthogonal, so I can combine them in any order. Orthogonality also is very good for stylesheet languages, as you know, because it makes template writing very straightforward. cheers, Argyn -----Original Message----- From: Kris Rasmussen [mailto:kriscocoon@yahoo.com] Sent: Friday, April 04, 2003 2:36 PM To: cocoon-users@xml.apache.org Subject: seperating content structure and style Let me know what you guys think about this. The general idea these days is to seperate content logic and style, as cocoon does very well. However, I think it is even better if you can seperate structure from style. The way i have done this in the past is with template calling in xsl. However, I think it would be much cleaner to have two style sheet transformations in cocoon, one that takes content to structure, and another that takes structure to style. For example, if I had an employee database that output xml like this (content): Some Name 343234234 ... I would then transform it to some structural language like this:

....

And then finally transform the structural elements to some sort of presentational form. Preferably the structural language would consist of as few as possible elements, maybe a couple types of box's, a couple types of lists, a couple types of sections, etc. Do people do stuff like this already, and if so are there any good xml languages that one could use to describe structure? Kris Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Mailscanner thanks transtec Computers for their support. --=_4916EB93.3C5D2BF0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit

Kris/Argyn

It seems that this is a topic that comes up again and

again on this list - everyone that tackles it comes up with

an approach that is similar to, but slighltly different from,

each of the others ... I have also had a go at creating a

structure which I call a "DBreport" layout which has worked

for me (so far). Do you - and any other lurkers (sorry,

"interested readers") think there is any merit in trying to

collate/synthesise such efforts into something which can

be developed and maintained by the community as a whole;

rather than the wheel being reinvented each time - I am

sure that, as in all these projects, each person could being

some very useful insights that will improve "the whole".

We could start on the wiki as a "quick and easy" central

location before having to register any kind of formal project...

Thanks

Derek

>>> akuketayev@cox.net 05/04/2003 01:35:19 >>>

Kris,

this sounds very familiar to me. Once I had to make a reporting module with PDF generation. When I looked at the existing reports (about 50-60 of them), I found out that they are all (surprise!) similar :)

Actually, now I think that I found an example of self-similar fractals in reporting domain, maybe I can claim for Turing award :)

Seriously, after few hours of thinking I came to conclusion that they all can be constructed with a limited number of elements, which can be nested and combined. I called them "layoutlets". By nesting and joining 3-4 layoutlets, one can generate unlimited variety of report layouts.

As far as I remember, I identified three main structural layoutlets for my reports: list, vertical-list and table. I also had some other stuff, like row, column, multi-line row etc.

So, when I extracted data from DB, I put it into content XML. Something like:

</row></resultset>

This has a nested resultset. Next step was to write stylesheet which makes as you call it "structural" XML, I called it layout sheet. This would use my layoutlets, which are defined as templates in a separate stylesheet library (I called it generic). Example:

<xsl:template match ="row[../@name='master']" mode="list">

<xsl:call-template name="row-list">

<xsl:with-param name="columns"><xsl:call-template name="list-columns"/></xsl:with-param>

<xsl:with-param name="is-nested" select="true()"/>

</xsl:call-template>

</xsl:template>

So, the report specifi stylesheet only has to map resultsets in content XML to appropriate layoutlets (generic templates). What's interesting is that layoutlets are orthogonal, so I can combine them in any order. Orthogonality also is very good for stylesheet languages, as you know, because it makes template writing very straightforward.

cheers,

Argyn

-----Original Message-----
From: Kris Rasmussen [mailto:kriscocoon@yahoo.com]
Sent: Friday, April 04, 2003 2:36 PM
To: cocoon-users@xml.apache.org
Subject: seperating content structure and style

Let me know what you guys think about this.

The general idea these days is to seperate content logic and style, as cocoon does very well. However, I think it is even better if you can seperate structure from style. The way i have done this in the past is with template calling in xsl. However, I think it would be much cleaner to have two style sheet transformations in cocoon, one that takes content to structure, and another that takes structure to style.

For example, if I had an employee database that output xml like this (content):

<employee id=2>
<name>Some Name</name>
<phone>343234234</phone>
...
</employee>

I would then transform it to some structural language like this:

<box title="{@name}">
<section title="details">
....
</section>
<section title="some other section">
</section>
</box>

And then finally transform the structural elements to some sort of presentational form.

Preferably the structural language would consist of as few as possible elements, maybe a couple types of box's, a couple types of lists, a couple types of sections, etc.

Do people do stuff like this already, and if so are there any good xml languages that one could use to describe structure?

Kris

Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Mailscanner thanks transtec Computers for their support. --=_4916EB93.3C5D2BF0--