On Tuesday 26 August 2008 17:26:42 Ben Sizer wrote: > On Aug 25, 9:33 am, "Jorge Vargas" <[EMAIL PROTECTED]> wrote: > > On Mon, Aug 25, 2008 at 2:19 AM, Boštjan Jerko <[EMAIL PROTECTED]> wrote: > > > I'd like to change field in the database when I click the button on > > > the page. I've "connected" python script in the kid template to the > > > button > > > but I don't know how to access table from the database in the kid > > > template. > > > > Please do not do this, it violates the MVC architecture, you should be > > doing that in the controller code and then pass the result to the > > templates for display. > > Actually, the original idea of MVC would be that the View pulls the > data it needs from the Model, which is exactly what Boštjan seems to > be attempting. More recently, people have mischaracterised MVC as > having the Controller be some sort of mediator between the View and > the Model. (http://martinfowler.com/eaaDev/uiArchs.html). > > Personally I find the original way makes more sense: the View knows > which aspects of the Model it needs to display and queries for them > accordingly, and the Controller just handles input logic, not having > to concern itself with which parts of the Model it needs to expose to > the View. Controllers and Views can vary independently. > > But yes, certainly this way is not the TurboGears way, which is fair > enough.
I have to disagree on several points here. The first and most important: the OP does *not* want to pull data. He very clearly states that he wants to manipulate model objects in the template. The part you quoted above contains the word "change", which makes that rather obvious I'd say. And as others - including you - have pointed out: it totally goes against the philosophy of both TG and MVC, however these are related. Regarding the general aspects of separation of views and controllers it has always been my impression that it is kind of artificial. If one strives for a pure implementation of MVC, the controller code would be triggered through some user-generated event, then modify the model accordingly. Here it gets shady for the first time: obviously enough, for anything beyond simple key or mouse-clicks the controller relies heavily on the view. Form-values in case of HTTP, or control-data int case of traditional GUI apps needs to be gathered before actually performing any modifications. And once the model is modified - how do the views reflect the changes that occured? Either they waste their time polling the model, or some event based triggering has to be employed as well. This can come from the model itself, but can easily end in useless re-rendering. Instead, the controller should - at least - initiate a final "update"-event - as only the controller knows when a series of model changes are actually finished. Additionally, we have the "problem" that some user-actions trigger re-configuration of the views themselves, instead of doing any changes whatsoever. And last but not least, in the world of "normal" gui-applications, you set up a view and bind it to a model. In the web, this isn't possible due to the stateless nature of HTTP. So it's not only controller code we need to run, we also need to run view-setup-code, on each request. Which IMHO is pretty much what TG does: leaving the controller will trigger the (re)rendering of a specific view, communicate which data has changed, and possibly contains information that also affects it's appearance. I agree that some of the aspects only the view is or should be interested in are somewhat intermingled in TG. For example the decision which actual widgets to render inside a site as long as these are "static" for the given view. This is somewhat mitigated in TG2 through the template-context. While that still is a tight coupling, it at least doesn't affect the actual returned "changed model event", the dictionary containing changed model data. To me, the MVC boils down to the clear separation of model logic from presentation and interaction. Which TG allows. You can of course always force things in the wrong way, as the OP wants, or by e.g. returning rendered HTML from model-methods... Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
