What’s in a name? (Or a package)

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:

  1. A model holds and manages application data and behaviour
  2. A model’s state might change at runtime
  3. 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?

Thoughts?

About the Author

I'm an actionscript programmer living and working in a tiny village in the Yorkshire Dales, UK. I used to be a TV reporter, but my inner (and often outer) geek won. I also write stuff. Most recently Head First 2D Geometry.

Visit Stray's Website

Share the post

Delicious It Digg this! Stumble this! Share on Reddit Share on Buzz Share on FriendFeed
  • http://twitter.com/activepoison Josh Iverson

    I only have two issues really with putting in either the view or the model, and that is reusability and locale. True ResourceBundle.getInstance() is not pretty but at the same time it is a singleton in all sense of the pattern and I unfortunately missed the whole twitter on which is better/worse…

    • http://www.xxcoder.net Stray

      Hi Josh – I think the trouble with .getInstance() singletons is that you can’t switch in a mock for testing, you’re reliant on using the real ResourceBundle.

      Same with any static method or property really.

      Reusability / locale is exactly what brought me here. 99 times out of 100 I need my content to be externally configured. But this time I don’t – so it’s a new question, with maybe new (different to my normal) answers?

  • http://joelhooks.com Joel Hooks

    presentation models unmuddy this a bit. The actual text, the words and their formation, that is definitely a model. The pixels on the screen and the machinations under the hood that make those appear is the view. It *does* get confusing because the internal workings of flash use addition MVC-esque bits under the hood to some extent.

    model, view, controller, whatever. The software could care less as long as it compiles and runs. All of this abstraction is strictly for you and your cohorts. As long as it is defined and consistant the cohorts should be fine :>

    • http://twitter.com/benbjohnson Ben Johnson

      I agree with Joel that this is simply an abstraction for you and your cohorts. Ultimately everything is data. Separating your types of data should benefit how you personally organize your code — not simply placing it in a view or model bucket because it’s “supposed” to go there.

      For me, the text is purely for visual purposes and I’d place it with my views before I put it with my model. However, I think it is ultimately a resource and I’d separate it out from either views or model since it doesn’t contribute to the logic of either.

      • http://www.xxcoder.net Stray

        So – Ben, you might have a package structure more like view.model. ?

        I like that.

        And you’re spot on Joel – the compiler only cares that I’m consistent. I’m very interested in what it means when I’m inconsistent with myself though – because these cracks are, I suspect, where there is good learning to be had.

        • http://twitter.com/benbjohnson Ben Johnson

          I actually have a directory structure like this:

          + src
          ..+ main
          ….+actionscript
          ….+resources
          ..+ test
          ….+actionscript
          ….+resources

          My package structure then starts at src/main/actionscript (and src/test/actionscript for test code). It works well because I can separate all my assets (locale-specific text files, images, mxmlc config files) into my resources folders and they’re separated by code/tests.

          I’m not sure when I came up with that structure. I believe it’s maven inspired; although I actually hate maven.

          Most of my ActionScript & Flex repos have that structure. Here’s an example on my Mockdown repo:

          https://github.com/benbjohnson/mockdown

          • http://www.xxcoder.net Stray

            Oh – yes, totally, I didn’t mean to suggest that it was limited to view/model at all.

            My test dir sits outside my src dir, but I like to use

            + src
            ..+ functionalarea
            ….+ api
            ……+ events
            ……+ vos
            ……+ core (interfaces)
            ….+ restricted
            ……+ controller
            ……..+ commands
            ……..+ events
            ……+ model
            ……+ services
            ……+ view

            In a larger app I’ll have multiple functionalarea packages, usually then compiled as modules. I like the restricted / api classification, and being able to confirm that there’s no spill-over using FlexPMD.

            The quandry is that you could have (within any sensible structure)

            view.model (models that are used in the view)

            or

            model.view (models that are used in the view)

            Cake slicing :)

        • http://twitter.com/benbjohnson Ben Johnson

          Also, I think it’s important to note that your package structure shouldn’t be limited to “views” and “models”. I usually end up with those two packages when I’m building an application (instead of a library) but I also have packages like “components”, “parsers”, “commands”, “events”, etc.

          I think Adobe does a good job of separating their packages appropriately. If I can mimic their structure then I usually do. It helps other coders understand where code should go.

  • http://twitter.com/s9tpepper Omar Gonzalez

    So here is the way I look at it. Text by itself can not be a view, because you can not put text on the display list. What do I mean by this? Consider this:

    var myMessage:String = “I am a message string.”;

    If we had the ability to do something like:

    myMovieClip.addChild(myMessage);

    Then I would most certainly say, text can and should probably be considered a View type of object. However, a String object requires a vehicle upon which to arrive at the screen, in plain AS3 this would be TextField. TextField is the View object upon which the String Model object can be viewed on the screen.

    The way that the data came to be in the application, whether it be embedded and started as a byte array etc, or loaded at runtime, or retrieved from a server, in each and every one of these scenarios the resulting loaded data can not be simply placed on the stage, in my opinion, making it not eligible for consideration as a View object, the loaded data model must be paired with some view component, a TextField, a s:Label, whatever, to actually make it viewable.

    Just my 2 cents.

    • http://www.xxcoder.net Stray

      This is making me think that a view is a decorator for a model, perhaps? As in, TextField really decorates the .text model that is inside of it?

      Which would perhaps lend itself to a package structure more like

      model
      view
      view.model

      etc?

      It possibly depends on which we consider to be the important part of the application – does the model provide content for the (vital) view, or does the view only exist to express the model?

  • Online

    I think the way I normally see it is that the view is responsible for display, style, layout type stuff and is given content to do it with. Of course everything apart from actually adding things to the display list could be content passed in. Text, images, styles, layout. However often such things are non dynamic and are best defined in the view seeing as they only pertain to the presentation.

    • http://www.xxcoder.net Stray

      “seeing as they only pertain to the presentation”

      Yes – that’s exactly what I’m wrestling with. Is it about *how* something works, or the *purpose* of the class? Interesting differentiation.

  • http://twitter.com/DavidArno David Arno

    I feel the discussion over whether text is the view or the model suggests that people are confusing data and information. Data and information are not the same thing. “1″ is data. “1cm” is information. “The bug is one one hundreth of the SI unit, metres, long” is more information. Information is data with meaning, context, description, decoration or some such other metadata.

    Both the model and view are concerned with information. In the case of the view, it decorates and displays the data. In the model’s case, it is concerned with storage and retrieval of the data; how it changes over time; how sets of data relate to each other etc. In both cases, they are concerned with the data only in these ways. If the model is involved with laying out the data, or the view with how it is stored, then there is a breakdown in this separation of concerns.

    The data is neither the view, nor the model: it is the result of communication between the two. Text is one such form of data. So to ask “is the text the view or the model” is the wrong question to ask as it is nether. I’d suggest the correct question is “is processing the text is way x a responsibility of the model or the view?”. In other words it is the action upon the text – the information – that belongs to the view or the model.

  • http://davidarno.org David Arno

    I feel the discussion over whether text is the view or the model suggests that people are confusing data and information. Data and information are not the same thing. “1″ is data. “1cm” is information. “The bug is one one hundreth of the SI unit, metres, long” is more information. Information is data with meaning, context, description, decoration or some such other metadata.

    Both the model and view are concerned with information. In the case of the view, it decorates and displays the data. In the model’s case, it is concerned with storage and retrieval of the data; how it changes over time; how sets of data relate to each other etc. In both cases, they are concerned with the data only in these ways. If the model is involved with laying out the data, or the view with how it is stored, then there is a breakdown in this separation of concerns.

    The data is neither the view, nor the model: it is the result of communication between the two. Text is one such form of data. So to ask “is the text the view or the model” is the wrong question to ask as it is nether. I’d suggest the correct question is “is processing the text is way x a responsibility of the model or the view?”. In other words it is the action upon the text – the information – that belongs to the view or the model.

    • http://www.xxcoder.net Stray

      Thanks for contributing – I think this data vs information thing is exactly what my subconscious is picking up on.

      Basically whether I think of treating this data as ‘view’ or as ‘model’, I experience cognitive dissonance. My dopamine receptors do not get the ‘Yes!’ hit.

      It probably sounds as though I’m disappearing down a rabbit hole here, but I rely on that cognitive dissonance for a lot of my architecture decisions. Does it ‘feel’ right? Often when something ‘feels’ wrong I experience a reluctance to implement it. I just can’t get my fingers to type …

      I’m not a procrastinator by nature, if anything I’m the opposite, so the absence of that “Yes! Let’s do it!” feeling, or even the presence of genuine reluctance, is something I find informative.

      It’s a nuance, but I think view.data or view.detail or view.config as a package would “feel” better to me than view.model, and definitely better than model.view (which I am still finding distasteful despite lots of rational arguments why it should be fine).

      The responsibility is definitely in the ‘view’ area.

  • Amy

    I think your mistake is thinking that MVC is something we should be rigidly adhering to in Flash at all, when in fact it’s not an expecially appropriate pattern most of the time http://www.as3dp.com/2010/03/01/separated-presentation-the-classic-model-view-controller-pattern/

  • http://creynders.be creynders

    I’m wondering why you’re so set on creating a “view.model” (or “model.view”) package? IMHO, a model is a model, whether it’s data is entirely shown in the view or not, it doesn’t matter. And whether it’s loaded at compile time, or run time is irrelevant too. To determine whether something needs to be a model I ask myself 2 questions:
    1. is it data?
    2. is it changeable?

    If I answer no to one of these questions, then I think it shouldn’t be a model. So, when it comes to text, my conclusion would be that it’s not a model at all. For all text in my applications I use a helper class which has basically a dictionary holding key/value pairs, this gets directly injected in mediators/commands/whatever and exposes a getText method with a key parameter. Simple as that.
    I know and understand that since this helper class is a data holder to many people it qualifies as a model and should be defined as that, but exactly because of the weird nature of this data I chose to differentiate and to put it outside the traditional mvcs structure.
    Probably there are tons of disadvantages to this method, but so far, it has worked very easily and intuitively for me.
    2 cents.