For some time in personal projects I have been using XSL to convert my raw XML data into human-friendly HTML/CSS (in simple projects, I have no JavaScript, so let’s leave that out of the equation for simplicity).
Now I’m trying to understand the MVC architectural pattern (not my first experience with it, but it is taking some work to go from understanding it basically to understanding it well), and I’m wondering if there is an analogy between the two.
- XML: data model; lacks the complexity/logic of a full-blown model component, but intent seems similar
- XSL: converts raw data for viewing—seems like a controller
- HTML/CSS (rendered): the viewable output
Is this analogy fitting? What in it matches well and what does not?
(One dissimilarity, I suppose, is that in my example I am not getting any input back from the view—only producing output.)
1
In this case, I would suggest that you don’t really have a controller per se. The XML is the model and the XSL (by way of producing an HTML output) is a view on that data. If you had some mechanism which took some user input and filtered (or caused to be filtered) the raw XML prior to the XSL transformation, then you might consider that mechanism to be your controller.
Almost, but not quite. If you had a hypothetical webserver that could pass URL query strings as XSL paramaters I’d say you were quite close, that would allow you to respond to user input.
eg. http://www.example.com/path/file.xml?param1=foo;param2=bar
And your xsl contained:
<xsl:param name="param1"/><xsl:param name="param2"/>
But even then, there is no way to actually change the data itself. So, again no.
Your analogy is flawed.
First of all, if you have a completely static website (no dynamic content at all), then I would say that you only have a set of Views. There is no Model and the small Controller part you need is completely taken care of by the webserver.
The task of the Controller is to update the Model based on the actions and input of the user and to decide what page to show next based on the result of that update. In your XML/XSL/HTML there is no component filling that role.
Assuming you XML is dynamically generated, it could be argued that the component generating the XML is (part of) the Controller. and the source for the XML is the Model.
What you have with your XML/XSL is only a View component. In most frameworks, the View consists of a collection of classes and the class’ methods are the means to provide the relevant data to the View. In your case, the View consists of a collection of XSL specifications and XML is the means to provide data to the View. In both cases, the HTML is just the (ephemeral) output of the View.
Static content is usually not considered in the MVC triad, but if I must, I would classify it as part of the View.
No, it is not MVC
XML is a data protocol. XSL is a translation specification language, but even with the engine that does the translation, it still is just a mechanism. Server-side frameworks like Struts can use this mechanism to create HTML and CSS
HTML and CSS can define views.
JavaScript can work inside a page to move data in and out of a view, sort of like a controller. I guess, as with anything, you can write a complete MVC in JavaScript — and others already have (see Atwood’s Law).
Cheers