2009/8/3 Marnen Laibow-Koser <[email protected]>: > > 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 > it puts JavaScript in the HTML files, which is poor practice. > >> I >> 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. Colin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
