One of the lead bullets describing why XForms is cool always mentions that it is based on a Model View Controller framework. When building a full XRX app, though, MVC might not be the best choice to organize things overall. Why not?
Consider a typical XRX app, like MarkLogic Application Builder. (You can download a your copy of MarkLogic, including Application Builder, under the community license at the developer site.) For each page, the cycle goes like this:
- The browser requests a particular page, say the one that lets you configure sorting options in the app you’re building
- The page loads, including client-side XForms via JavaScript
- XForms requests the project state as XML from a designated endpoint; this becomes the XForms Instance Data
- Stuff happens on the page that changes the client-side state
- Just before leaving the page, XML representing the updated state is HTTP PUT back to the endpoint
The benefit of this approach is that you are dealing with XML all the way through, no impedance mismatches like you might find on an app that awkwardly transitions from (say) relational data to Java objects to urlencoded name/value pairs embedded in HTML syntax.
So why not do this in straight MVC? Honestly, MVC isn’t a bad choice, but it can get unwieldy. If an endpoint consists of a separate model+view+controller files, and each individual page consists of separate model+view+controller files, it adds up to a lot of stuff to keep track of. In truly huge apps, this much attention to organization might be worth it, but most apps aren’t that big. Thus the MET pattern.
Model: It still makes sense to keep the code that deals with particular models (closely aligned with Schemas) as a separate thing. All of Application Builder, for example, has only one model.
Endpoint: The job of an endpoint is to GET and PUT (and possibly POST and DELETE) XML, or other equivalent resource bundles depending on how many media types you want to deal with. It combines an aspect of controllers by being activated by a particular URL and views by providing the data in a consistent format.
Template: Since XForms documents already contain MVC mechanics, it not a high-payoff situation to further use MVC to construct the XForms and XHTML wrapper themselves. The important stuff happens within XForms, and then you need various templating mechanisms for example to provide consistent headers, footers, and other pieces across multiple pages. For this, an ordinary templating mechanism suffices. I can imagine dynamic assembly scenarios where this wouldn’t be the case, but again, many apps don’t need this kind of flexibility, and the complexity that comes along with it.
What about separation of concerns? Oh yeah, what about it? :-) Technically both Endpoints and Templates violate classical SOC. In an XRX app, this typically doesn’t lead to the kinds of spaghetti situations that it might otherwise. Endpoints are self contained, and can focus on doing just one thing well; with limited scope comes limited ability to get into trouble. For those times when you need to dig into the XQuery code of an endpoint, it’s actually helpful to see both the controller and view pieces laid out in one file.
As for Templates, simplicity wins. With the specifics of models and endpoints peeled away, the remaining challenge in developing individual pages is getting the XForms right, and again, it’s helpful to minimize the numbers of files one XForms page are split across. YAGNI applies to what’s left, at least in the stuff I’ve built.
So, I’ve been careful in the title to call this an “organizational pattern”, not a “design pattern” or an (ugh) “architectural pattern”. Nothing too profound here. I’d be happy to start seeing XRX apps laid out with directory names like “models”, “endpoints”, and “templates”.
What do you think? Comments welcome.
-m
If I understood you correctly you mean coupling the XForms and HTML in the same file as the XQuery?
I might argue that the XForms architecture lends itself to leaving the presentation to XForms / HTML and having XQuery only manipulate the DB or incoming XML. Not only do I think this lets you organize the XQuery in a meaningful way on the server you can serve the View (Xforms / HTML) from a different folder then the controller. Therebey several views associated with a certain controller, and a cleaner organization, something that I might be useful for an admin / user style app where a large portion of the functionality might be shared?
>>> Endpoints are self contained, and can focus on doing just one thing well; with limited scope comes limited ability to get into trouble.
I would think that simplifying the nature of templates and endpoints alike allows a development team to place more focus on interactivity on the XForms/client-side. My experience has been that separation of concerns, at least as far as Spring is concerned in a typical Java control architecture, results in complexity rather than simplicity.
Using the word “endpoint” is good too – communication endpoints had a meaning before SOA took over the term. I suppose one of the hurdles people often encounter with REST as a concept is that it doesn’t actually mean you can do everything and anything you want with a URL. Defining a collection of endpoints helps to alleviate this approach.
“Template” has the added advantage that it is immediately grokkable by the PHP community.