Putting display logic back in the data model?

Display logic belongs in the data model, or so goes the old school of thought. There is some truth to it. However, formatting and layout are part of the view, though governed by the user's specifications.

The nice thing about event-driven display is that events do not deal with formatting and low-level events have nothing to do with layout. So its easy to put this part of the display logic back into the data model. And that potentially eliminates a lot of redundent code.

Well, I've completed the conversion of the display header to events. And moved the generation of the display event itself into scriptUI and interactiveUI. (And ScriptUI no longer displays classifier entries with its customized header logic.) At the same time, I've moved all the header formatting logic from the UI base class into the text client. Where it belongs! Meanwhile, the Rolon class is now handling the generation of pathname and classifierEntries events, while the session object generates the time event. (Its the session object which tracks the time context.)

Using events has allowed me to break up the display logic into parts and scatter those parts to where they are most appropriate, without anything becoming too cryptic. The interesting thing is that the client formatting logic would likely be a lot cleaner if the output was a web page--a lot of that formatting could easily be handled by CSS, or perhaps a JSP tag library. :-)

Of course, converting the display header is the smallest part of this conversion effort. But since I can do incrimental conversions and everything just keeps working, its not too bad. Hmm. Time to get back to sorting papers. Gotta get these taxes done. :-(

Bill