Architecting Your Views Part 3: A Proposed Solution

And so in the spirit of Einstein’s famous quote, here is my currently proposed solution to my view design requirements . . .

Re-introducing the IBO
Anyone who follows this blog will have heard about the Iterating Business Object. In short, it is a way to encapsulate the getting and setting of the attributes of your business objects, but using a single object to handle 1..n records to handle the performance issues with creating large numbers of transient objects in ColdFusion.

Two things I wanted to automate were the creation of fields for editing attributes and any display rules for displaying the value of attributes. Both of those can be specified automatically using custom data types. However, to make this work I need to add a field() and display() method to my IBO. But these are HTML aware methods, so I really don’t want to stick them in the same IBO that I use in my model for encapsulating the business rules around getting and setting attribute values. So, I’ve added a com.view.IBOViewDecorator.BaseIBOViewDecorator.cfc with three new methods: field(), display() and loadIBO() – as well as delegates for all of the IBO methods that would be relevant in a view (attributeTitle(), get(), set(), first(), next() and hasNext()).

The benefits of the IBOViewDecorator are that it allows you to use custom data types to handle field display and value display (prefixing money data types with the appropriate currency symbols or formatting dates and times appropriately) removing a lot of the busy-work scripting from your applications and cleaning up your view templates.

The Render Object
I REALLY like Dependency injection. With DI, objects just *have* the objects they need without having to worry about it. I like it so much I thought it would be great to be able to DI within my views, but to do that I had to run LightBase page requests as a single method call (which I did – you now just call application.LightBase.processRequest()) and I needed to create a cfc to handle and hide the orchestration of all view rendering (which I did – com.view.render.cfc).

By using IBO’s I was already going to have to teach my designers to use syntax like #Product.display(“Price”)# for displaying the price of products. I thought it would be cool to be able to use the same syntax with a fairly limited vocabulary to encapsulate the complexity of any scripting from the templates my designers used.

For instance, a page template is comprised of HTML, optional snippets, and 1..n content areas, so when a designer wants to drop in a dynamic content area, they can just write #Render.contentArea(“Sidebar”)# to have the sidebar content area rendered in that place.

I also provided for #Render.snippet(“CheckoutMessage”)# for rendering snippets of content for clients to manage using the CMS and #Render.form(“UserForm”)# for displaying a user add/edit form and #Render.table(“AttorneyList”)# for displaying a list of an object in a state aware table with filtering, paging an ordering features based on the parameters associated to and the data returned by the model method bound to the “AttorneyList” table.

There are a few nice things about this approach.

I love the fact that I just need to teach designers a single manageable syntax for handling everything from displaying a product price to displaying a snippet, component or content area. I love the fact that with the exception of looping through iterators and possibly the occasionally expedient cfif, it almost entirely removes scripting from the templates, providing for a clean separation of concerns and making it feasible for designers with basic HTML knowledge to do all of the custom layout without getting into too much trouble.

I love the fact that designers don’t have to worry about passing the RequestObject or other data to each method. They don’t have to do something like #Render.table(“AttorneyList”,RequestObject.get(“AttorneyIBO”))# which would be a little confusing for a designer. I don’t love having to use the variables scope within the Render object to provide this feature as it makes the methods a little less self contained than I’d usually like, but I feel it is an appropriate solution to the problem at hand so I’ll take it as a win!

Above all, I love the levels of reusability that this provides and the flexibility it offers for declaratively specifying a huge proportion of your view logic, just leaving a set of templates for your designers to tweak as they will. This is particularly important for my use case as I have to engineer almost all of the programming out of creating custom web applications while still providing unlimited view flexibility.

UI Components
My first two UI components are table and form – and they still need a lot of work. The basic principle is that these can be used for scaffolding that is so sophisticated that for the vast majority of your pages (at least on low budget projects) the scaffolding will BE the application – perhaps with a few tweaks.

The basic idea was to provide the benefits of a Visual Studio style approach while allowing for the association of UI components to model methods rather than straight to a data source (and if I can offer Mark Drew enough drinks, cash or stock options - who knows - maybe there WILL be a visual designer for LightBase!). I also wanted something that would be capable of maintaining state so you didn’t have to write a bunch of code to ensure that when you changed the order by for a table it remembered the number of records per page or when you moved to a new page it still remembered the filters you had applied to the records in the table. I know a lot of this can be implemented using AJAX, but I wanted an HTML reference implementation to which I could then add AJAX or Flex renderers if I so chose (Q1 2007 – quicker if anyone wants to help out!).

Each user component has a set of methods together with a template so that if you don’t like how a template pulls the scripted code together, you can just create another template, set that as a parameter declaratively, and customize it. Of course, if you don’t like how any of the scripted methods work (above and beyond any parameterizations available), you can just extend the object and overload any method implementations that don’t work for you (sometimes inheritance is very cool!).

To be honest I am thoroughly relieved to have an approach to pulling together templates and components with support for DI, inheritance, good separation of concerns, intelligent conventions, unlimited flexibility to customize or extend, etc. My UI controls aren’t much good yet as I need to do a lot of thinking about state. But it’s looking like LightBase is going to be pretty good by Christmas.

Any constructive input or questions always gratefully received!