> > >http://code.google.com/p/webpyte/wiki/FormettoFramework > > > > > I have written up the above page about why I was unsatisfied with the > > > interface of TG widgets (which puts widgets in our controllers instead > > > of our template) and why I am making a new interface: Formetto. > > > > I haven't looked at your code yet but have to say that I also don't > > like very much the fact that I have to define what widgets are used in > > the controller. It feels more natural to declare this in the template. > > I don't claim to have a very precise opinion on what solution would be > > the best but it just doesn't feel right how things are now (and > > probably will be with TW) although I go with the flow and do it the TG > > way anyway because it's not a really big deal. > > > > Now that we are at it could one or more of the developers expand on > > what lead to the current design decision regarding widgets? I mean > > that they need to be declared in the controller. I'm sure there are > > very good reasons to do things this way I just fail to see them. > > There are two reasons for which the may be defined outside the > template (not necessarily "the controller", I don't consider a > "widgets" package to be controller code just because it's not in the > template): > > 1) To have a reference to the form instance to validate input. This is > the only hard reason, but a single line is needed in the module where > controllers are declared to avoid cluttering it with widget > declarations ;) > > 2) So resources (js & css) needed for the widgets are picked up to be > injected in the template. The current implementation scans the output > dict returned by controllers and picks up widgets from there, it is > done this way because the resources in the <head> are rendered before > any other widget is so its impossible to know in advance which widgets > are actually going to be rendered. > In TW I was experimenting with another approach which injected the > resources after the page was finished using lxml. This allowed you to > import, or even declare, widgets in the template and their resources > would be included too. Unfortunately I consider the experiment of mild > success since lxml, being a C coded extension, causes installation > problems for some and because of the fact that lxml currently cannot > serialize XHTML, only HTML. Genshi could be used to inject resources > post-widget-render but will be terribly inefficient with string-based > templates (like Mako). Ideas welcomed :)
I understand that the widget code doesn't have to go into the controller and it can happily live in its own module but in the controller I have to instantiate a widget class and stuff it into the dict the controller is returning. This is the part which I don't quite get (again, not a big issue, TG/TW works great, just a minor question I have). Why not have a way in which the template says it needs this and that widget and if those widgets need some parameters from the controller then these parameters are returned in the dict, are available in the template so the widget has access to them in the template. BTW, regarding validation I fully agree with you that things should be in the way they are right now. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
