cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toby Ferguson <>
Subject Re: XML Query language
Date Thu, 17 Feb 2000 21:33:07 GMT
Mark Washeim wrote:

> on 17/2/2000 11.38, Stefano Mazzocchi at wrote:
> >
> >> In any case, while I don't understand most of what you guys discussed,
> >> one thing stuck: I agree that it *is* evil to put anything
> >> cocoon-specific in an XML file. Or, to generalize: XML files should
> >> contain data, not instructions for an application, be it cocoon, a web
> >> server or whatever. The data should drive the application, not the other
> >> way around.
> >
> > Yes! Exactly!
> >
> There is a confusion here. Data does not drive anything. Neither should the
> design of applications contaminate a well designed data model (within
> limits). More after next . . .
> >> So, when I look at my XML files, I find these lines:
> >>
> >> <?cocoon-process type="xslt"?>
> >> <?xml-stylesheet href="test.xsp" type="text/xsl"?>
> >>
> >> We are basically telling cocoon what to do with this XML file (in this
> >> case apply an XSP transform). As far as I understand the sitemap, it
> >> will allow us to put these instructions into a seperate file. Doesn't
> >> that solve the whole problem? A single file to manage (or one per
> >> directory if we like) and clean XML files.
> >
> > Or, put it another way, pure MVC!
> Ok, firstly the use of the Model View Controller pattern, inductively,
> yields an important piece of information. Namely, the logic part of the
> exquation is contained, so to speak, in the controller. The controller
> drives the application, not the Model. But the controller does not
> 'constrain' the design of the Model (which, after all could be a Composite
> pattern of other objects).
> This gets very complex if you stop for a moment and remember something.
> Although in our panacea mode we expect Cocoon (Processors, filters, etc) +
> Data (XML) + XSL to be our implementation of an MVC, it's actually NOT the
> case. This is the real aggregation:
> Controller Layer:
> Cocoon + XSL (I place XSL here while it mediates between the 'real' view and
> the model, just like the other parts of the controller)
> Model Layer:
> Structured Data Sources (SQL -> XML, XML files, etc)
> View Layer:
> HTML, PDF, ASCII (my favourite), GIF, etc.

I have to offer an alternate opinion here - I see a View as an abstraction of a
Model, providing a "read-only" abstraction of the Model. In other words, it
abstracts from the implementation and representation that the Model uses, and
also abstracts from the interactive properties that the Model might present.
Given that the View is an abstraction, then it *might* be simply inert data
(HTML, PDF, ASCII), but it also can be an active component, configured with an
XSL stylesheet, which represents the Model (which, presumably, provides an XML
representation). So, in that case, I think that XSL fits into the View side of
the MVC paradigm. Indeed, as XSL is part of a one-way filter, I think it fits
there best of all.

> This is not a claim. It's a simple fact that we don't have the luxury in the
> document publishing domain that we do as java developers. Namely, unlike
> applying MVC patterns using JFC components (swing) or awt components, we
> don't have a set of well defined conventions (ie, frame, window, menubar,
> menu, panel, combobox, etc) for what are, esentially components of the view
> layer. And XSL is NOT those components but a means for TRANSFORMING the
> model into the view.

Only true if a view is static.

> Now if you consider that numerous 'controllers' that can effectively be
> created with XSL in ADDITION to the controller functions performed by cocoon
> (namely, the application of more transformation by other means), you wind up
> with MANY controllers, producing MANY views. It becomes clear that you can't
> simply assume within a framework (cocoon, THE controller) to be used across
> content domains that you won't wind up with CONTENTION over the use(s) of
> the model(s) if what is available of the model to users outside one domain
> is the (mediated by XSL) VIEW.  Considering the stylesheet as view is a
> design error.

I don't see things quite as you do. I see Controllers as providing the place
where state specific to a use (or kinds of use) of a Model is managed. The
Controller responds to input requests by determing how that request fits into
the current state of use of the Model, then choosing to reflect the result of
that determination by choosing a View to provide an abstraction of the Model
back to the requestor.  The fact that a Model might be used by multiple
controllers is to be considered at design time. Parallel updating of any data
structure is an issue that will have deep repercussions on any design.


> [snip snip]

I don't think I can contribute more right now - I just wanted to give an
alternative opinion and see where that took us.

Meantime I'm fascinated by this discussion - I just wish I knew more about the
sitemap stuff to really understand the nuances of the discussion!

Toby Ferguson

View raw message