> > Yes, it's fine for the controller to notify a view that it needs to be > updated, with typical observer/listener semantics. I think it's less > good when the controller has to collect all the relevant data from the > model and pass it to the view. This makes it harder to vary the > controller and view independently, which is often helpful.
Sure. Yet I tend to only return "raw" model objects, only very seldom I do compute anything. So most of the time, it's just returning the objects I modified in the controller. > > 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. > > My only quibble is that the view-setup-code is typically in the > controller. I don't have a perfect solution for this in mind, however. > There's obviously little to stop me moving all that code into the > template itself, but that seems to be mixing presentation with logic. > It feels like there should be another layer in there, but I don't > suppose many people would want that. I do know & partly share this feeling, yet fail to see how this can be so decoupled it's worth the effort. Most of the time, you need data that the controller computes anyway - for example, take the difference between updating and creating an entity. The controller decides which of both things to do, based on e.g. a default ID parameter. Yet the view code needs to make the same decision. So either the controller communicates which path it chose - or you duplicated the decision code, leading to DRY-violations that are even worse. > > 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. > > Is there documentation on this? It sounds interesting. A very quick > search of the TG2 docs didn't yield anything. It's the pylons tmpl_context: http://docs.pylonshq.com/glossary.html It's nothing but a thread-local variable you can use to stuff e.g. widgets into, and thus make the controller only return actual data. 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 -~----------~----~----~----~------~----~------~--~---
