Robin Munn, el martes 27 de diciembre a las 16:48 me escribiste: > > My only concern is with 'title', that is also at the model... My first idea > > was using a dictionary instead of a list and using the keys for column names > > and values as labels. But SQLObject already provides 'title' for columns, > > so... > > "title" is one attribute that I, for one, don't mind seeing at the > model level. The idea behind Model-View-Controller separation is to > reduce the amount of "binding" between layers, so that when you write > a new View (a GUI instead of a Web interface or what have you), you > don't have to touch your Model code. > > But no matter what view you're using, you're going to need to present > the user with some kind of form to fill in. And you're probably going > to be autogenerating it from your model's sqlmeta attributes. So > whatever view you write will probably need the "title" attribute. > Therefore, putting this one attribute in the model will not make you > rewrite your model to accomodate new views. In fact, if for some > reason you're not using the view at all, you can just ignore the > "title" attribute completely. > > I think this is a case of "practicality beats purity." Putting "title" > in the model is by far the most practical approach that I can come up > with.
I agree on this, but I think you should _always_ can easily override in the view the defaults specified in the model (which are great to get started). That's why I don't really care too much about form_order and/or resume_order in the model, as long as it's used as the lazy-man-defaults and can be overriden by the controller and view. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ .------------------------------------------------------------------------, \ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 / '--------------------------------------------------------------------' I would drape myself in velvet if it were socially acceptable. -- George Constanza
