Last night, I put a shout out on twitter for some input into something I’ve been wrestling with:
On-screen text content, model or view?
I got some excellent input, learned a lot (you can embed XML direct in a class, pull in a text file at compile time as a
ByteArray, and the flex framework ResourceBundle is a gross
getInstance() Singleton) from a whole bunch of smart people. Thanks @benbjohnson @davidortinau @johnguenin @nodename @redannick @tjgillis @troygilbert – a good twitter geek network is like a super-seminar-o-matic.
The general consensus was that it belongs in the model package, but it brought to my attention an interesting question that I’d have assumed I had a smart answer to:
What makes a model a model?
It’s pretty easy to answer “What makes a view a view?”. Can you see it? Yeah? Well then it’s probably a view. But what makes a model a model? I realised that I don’t have a very clear definition, so I scraped together a few things that I think are true about models:
- A model holds and manages application data and behaviour
- A model’s state might change at runtime
- A model responds to queries about its state and requests to change its state
Testing my class, a collection of strings to be displayed to the user, against these three points I can see instantly that statement 2 isn’t relevant. This text is fixed at compile time, and I just want to have a place to group some of it together to make the final edits to it easier.
Statement 3 is kind of relevant – this text-holding class never changes its state, but it wouldn’t be much use if it wasn’t possible to query its state. But then you can also query state on a view (x, y, width, height) so that, of itself, doesn’t seem to differentiate between a view and a model.
So I need to consider statement 1. Which brings me to another question…
What is data anyway?
It’s clear that if I was loading this text at runtime, it would be data. I’d load it with a service and I’d store it in a model. For umpteen reasons that I won’t expand upon, I’m not loading it at runtime.
And this is why my brain keeps nagging me with the suggestion that perhaps, just perhaps, this text is not model; it’s view.
If I wasn’t pulling the text together to make it easier for me to develop, it would sit on stage in the relevant views in the Flash IDE. So, how does a view become a model, just by virtue of being moved to a different file in the development environment? At runtime, from the application’s perspective, the purpose and responsibility hasn’t changed… which brings me to an even bigger question:
Does the package structure of an application reflect the product or the process?
There are two potentially conflicting points of view – the developer’s and the software’s. Which of those two should our package structure stay loyal to?
Is there something inherently mucky about the view/model split in flash applications, or does this apply more widely?
Perhaps a view is actually a special type of model, rather than a distinct classification?
Am I falling into the Korzybski trap – mistaking the map for the territory?