May 25, 2011

Proxy Models

I'll forewarn that this is more of a work thing.  And also forewarn that this isn't anything new... just new to me.

The "aha" last week was when I realized I needed to modify the model of the model not the view.  Actually, I didn't modify the model or the view.  I sat a "proxy model" on top of the model for the view to see.

The "aha" doesn't have to do with showing filtered data in a table widget, but it will serve as an example.  In the past, I would have wanted to dig into the view, filter the data through a callback and reshow the view.  Instead of that, now, I'd probably place a filter proxy model over the the actual model.  One benefit from this is that multiple views can view the same proxy model so filtering or whatever can be done in one spot - and views can be more simple.  The proxy is really an indexing over the model and has no data (actually "the model" has no data, it's a cover for a data store).

Proxy models can be stacked like different lenses over the model for views.  From a view's point of view a proxy model is a model. But it's also a kind of "view" of the model. A lense might be the right term.  Hmmm.

In a very practical sense the code gets a lot cleaner and you don't have to go digging in a lot of places.  I think I like the idea of the model being an index.  It's like an acceptance that indexes are a fact of life and formalizing it... and putting it in one spot... all that translation, mapping, morphing, switching can be it's own thing.

The other thing is that operations on the proxy occur on the actual model.  So signals tied to the model's change are fed back to the signalees.

btw, it wasn't until recently that I separated data and model in my head - if you can believe that...  I've always wanted to be close to my data... and have seen a view as a view of the data... which is true kinda... I thought what you really wanted was a uniform agreed upon data form.  What happens with that is that you have an "internal format" and translators.  Seems like things are always broken in that case - I'd have to think about why, but it's a mess somehow.  A *model* is different.  It's more about formalized access to the data - e.g. like the DOM (document object *model*).  Of course there is a marriage between model and data... and that's messy... but still... oh well... I don't need to convince... I needa work!

PS: another aha was the existence of a "selection model" which actually works over the model... and is used by and can be shared by views.

No comments: