| September 2002 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||
| Feb Oct | ||||||
Incoming thought food
Marc, himself, his blogs, and you reading them
Matthew Langham's Radio Weblog
Here's how this works.
donderdag 26 september 2002
Big grin - my baby daughter just finished her bottle. The two boys went to bed hours ago, but she prefers to enjoy the evening hours, it seems. I wonder where she got that from?
10:20:45 PM
comment []
<map:aggregate> considered harmful - an answer
Ovidiu asked me to elaborate on the statement of
<map:aggregate> considered harmful, so here goes...
When I started to use Cocoon, I made extensive use of the aggregation component since it seemed like a good way to combine several sources into one output stream. Problem however is that the aggregator is merily a concatenator, i.e. it appends the result of one or more pipelines to another one, provides a root element and fires of SAX events to the next component. It took me a while (and Bruno's help) to find out that this is not what I typically want - the Cocoon aggregator is often regarded as being Frames on Steroids. But I don't want to have one <frameset> document, I want <iframe>'s or even better XInclude!
The problem
A typical pipeline using aggregation does the following:
--- (T) --- A ---
> aggregation ---> C --(T)--> D
--- (T) --- B ---/
Let's imagine the 'classic' example of assembling a webpage - we have content and navigation brought together using aggregation. So we will have one pipeline A producing the content (maybe just a FileGenerator, but it could as well be a DocBook2xdocs transformation), and one pipeline B producing the navigation, probably accessing a directory structure, a database or whatelse. With the ideas of the TwoStepView pattern in mind, we won't immediatelly produce (X)HTML yet, we will do that in a final step. So using the aggregator, those two sources are concatenated, and the result is one big document C containing everything we need...
But now, we have a problem: we have to write a stylesheet that translates C into decent (X)HTML D. While this shouldn't be a problem, it causes however a mix of concern I find counterproductive, especially in terms of maintenance afterwards. The stylesheet needs to achieve two tasks: moving the two streams around so that they are correctly positioned in the pagegrid (presumably) constructed using an (X)HTML table, and doing the style transformation of the individual elements from XML to (X)HTML.
Getting there? No.
Thinking I could do better, I started building two-step transformations inside pipelines A and B, making sure that (X)HTML was sent into the aggregator. And yes, my last transformation became much simpler, basically only positioning elements into an HTML grid. I thought. Because it still felt not right. My final post-aggregation stylesheet still contained (X)HTML-generating templates in non-obvious places.
The CInclude Transformer
To have your pagegrid properly split out from the various components it is filled with, the CInclude transformer seems like a better solution. Your input document to the CInclude transformer will basically be structured as your pagegrid table. If you would be generating portal-like pages, you might as well have a <grid> with <pane>s in it, too. These panes are then filled (should we say 'decorated'?) with (X)HTML fragments coming from the different content- or navigation-producing pipelines, perhaps parametrized with respect to what kind of (X)HTML markup they should be producing using simple sitemap parameters.
That stream is passed into the CInclude transformer, filling up the panes, and presto, the only (X)HTML manipulation which might be left is producing the <head> element and wrapping the stream with the appropriate <html> element. Nothing fancy - something which could be hardcoded in the input document to the CInclude tranformer if you have only one type of lay-out to generate.
The funny thing is that the CInclude tranformer input document will likely to be dynamic, depending on the URI request. So you'll have a stylesheet building up that input document based on external parameters. Basically, you could get rid of the input document to that transformation, because the result of the transformation can be completely artificially constructed, without an input document directing the process. One could imagine a NullGenerator for producing such documents, don't we?
The result
--- A ------------
|
--- B ------- |
| |
v v
--> C ----- CInclude
|
v
(X)HTML
Comments are welcomed! I'll add this to the Cocoon Wiki if it seems useful to some.
8:48:09 PM comment []
Meet the Gnu
Yesterday, I had the occasion of being invited to an 'Oracle on Linux' diner organized because some Oracle R&D people were (supposed to be) in Belgium. While I'm not a Linux nor a database afficionado (this stuff is 'merily' infrastructural to me), the gathering itself was interesting because I had the opportunity to meet some ardent Belgian {GNU/}Linux supporters.
I had the opportunity to reiterate the license debate we had on the cocoondev.org list with Peter Vandenabeele, CEO of a company working on embedded Linux implementations. He is also working on the thin balance between free software, community, and keeping a business sound and safe. Interesting guy to meet.
10:20:19 AM comment []
This Page was last update: 3/01/2003; 13:28:59
Copyright 2003 Steven Noels
Theme Design by Bryan Bell
