Colin Law wrote:
I have a problem with YM4R however. The concept there is to construct
the map object in the controller and then display it in the view.
It's been a while since I've touched that part of my codebase, so I had
temporarily forgotten that.
I'm actually no longer quite using YM4R's view code in any case, since
suggest that the map is not an object to be set up in the controller
but is a feature of the view.
I suggest that you're probably wrong. If the map is to be treated as an
object at all (admittedly, that's a nontrivial if), then the controller
is by definition the appropriate place to load it.
I am suggesting that the map is not to be treated as an object any
more than a table is in a view. It is just a particular way of
viewing a set of markers, waypoints etc. If you want a table in a
view one does not setup number of columns, column width, styles etc in
the controller then display it in the view so why setup the map object
in the controller? Just setup the waypoints or whatever is required
there and display the map in the view. Another reason for this
approach is the same controller could be used to serve the data as
xml, or as a tabular view or any other view.
I setup the data to be viewed in the
controller/model (@markers to hold the markers for example) and then
construct the map in the view just using the mapstraction (or google)
js API. I believe this fits the MVC architecture better.
This is more or less what I do as well, but whether it's a better use of
MVC or not depends on whether you consider the map or the markers to be
the primary objects.
Arguably, almost by definition of what a map is, a map is a view on a
dataset, not a primary object. If it were, then the map would be
stored in the db, rather than the definition of what one would like to
see on the view.
I agree though that if one does consider the map to be a primary
object then setting it up in the controller may be a valid approach.
Not that I think one should be dogmatic about this sort of thing, the
best way to do something is often the way that sits best with ones gut
feelings for how to partition a problem, rather than that demanded by
some ideological truth.