Separation of Concerns

May 9, 2012, 7:53 PM

Tags: xpages

A while back, I wondered about the right way to write XPages. Things have changed a bit since then - Domino has gotten a bit better, the Extension Library exists and is great, and I'm a bit more adept with the environment. The forum app, which I should probably write a post explaining one day, came together kind of like how I mentioned there - Java classes to wrap all of the Domino access, which dramatically reduced the amount of code in the XPages themselves.

Still, I'm not sure I'm doing it right most of the time.

I've never done extensive work in a proper MVC environment, but I've gotten a bit of a taste for it on the occasions that I've tinkered with Rails. I feel like the components are there in XPages, but none of the official documentation encourages using any of them, nor does Designer encourage programming that way. You can do it in bits, though - for event handlers, you can point the action to a Java method via EL (like "#{someObject.doSomething}", if I recall correctly), and the "Next page" things in the XPage's properties panel use this underlying xp:navigationRule architecture, which is probably a mix of View and Controller, but it's an interesting idea.

I may have been on to something with the forum app, but I had to create a very aggressive caching system to make it at all practical. The end result was good - very little code in the XPages themselves - but there was more "framework" necessary than I think I'm comfortable with. Still, that discomfort isn't as bad as seeing a lot of business logic in an XPage (yes, I am aware that my main side project is a way to make it all the easier to do this).

I feel like the "right" way to do it would be to really restrict the XPage itself to be a page-layout engine, concerned only with declaring widgets and connecting them to actions on data. However, you can't get very far with just the components you're given, since you're eventually going to want to, say, set a couple values on a document programmatically. You can sort of stumble along with some of the built-in actions, but that's not necessarily any cleaner... just more XML-y.

Maybe the correct thing to do would be to make it easier to expand on Controllers or Models (my MVC knowledge gets shaky here) in code in Designer so that you could, for example, define a publish action for a blog post document that handles setting the published date, changing the status, and saving it. That way, the XPage would be referencing the actual job to be done - publishing the post - while the back-end code would handle the implementation details of replaceItemValue and so forth. Maybe it'd be best to treat Forms like an object definition - a combination of instance members (fields) and actions to be performed. They're already on their way to being mostly structural support for XPages apps.

I may try to structure my next XPage like this, perhaps writing wrapper objects that take Documents or DominoDocuments in their constructor and providing all the actions that I'd want to perform on them. I could set that up as a dataContext perhaps, and then use its methods instead of adding inline code on the XPage. It's worth some experimenting, I think.

Commenter Photo

Tim Tripcony - May 10, 2012, 2:32 AM

You're definitely on the right track, Jesse. In many ways, XPages disguise their own JSF nature merely by the extent of what they do automatically for us. In typical JSF implementations, for instance, because there is no such thing as a "Domino Document" or "Domino View", in order to have any Model at all, you have to define your own data source. Because XPages, on the other hand, provide these two data sources OOB, it's fairly instinctive both to continue to think in "classic Notes" patterns where one user interface element == one document or view, and to pressure IBM to define new types of data sources for us (e.g. RDBMS connectors).

But we can define our own data sources. Doing so really only consists of three pieces:

  1. A data source class
  2. A data object class
  3. A "complex-type" definition in a .xsp-config file

Naturally, the structure of each must conform to a few conventions. And obviously it's "easier" to just use what we're already given rather than creating this conceptual separation between UI and data. But when you start defining your own BlogPost or PurchaseRequisition or PhotoAlbum data sources (just to toss out a few random examples), your XPages start to become precisely what you describe: visual page definitions bound to properties and methods of the person or process or physical object the data is meant to represent, not to the data itself.

This provides enormous flexibility later down the road: when applications are structured in this manner, it's often easy to dramatically alter either the look and feel of the application or the way its data is structured without having to touch the other layer at all.


P.S. As soon as I have time to do so, I'll post an article detailing the full process of creating custom data sources... if nothing shows up by the end of the coming weekend, feel free to pester me. Wink

New Comment