On 6/27/07, Mark Ramm <[EMAIL PROTECTED]> wrote: > I'm looking forward to some spirited discussion of the TurboGears 2.0 > plan, and the plan for TurboGears 1.1 on the TurboGears trunk mailng > list.
Hey Mark, Let me say first that I think the idea of building TG2 on top of Pylons is one I've secretly wished were possible from a political and migration perspective, and that I'm impressed at the community leaders being so much behind this, and by the sprint's effort into looking into this. After looking at what's been done, I really think this is the best outcome. I really like how much the expose and validate decorators have been made a lot simpler to understand and, to some degree, reimplement to suit your needs. I'd like to broach the subject of convention over configuration at this point. At work, I have a Pylons-esque controller being dispatched to by Routes (running in TurboGears). I've modified the __call__ function to do a few things: 1. Search for the action name followed by the HTTP method name before looking for the action name alone. This means that I can write "create" and "create_POST", and I know that I only need to worry about the POST case in "create_POST". (In Pylons proper, you can use @rest.dispatch_on to do this explicitly.) 2. In the POST case, search for the action name followed by the word "schema". If it is found, apply the validation in the schema function to the current request. If that fails, look for the action name followed by "POST_fallback", otherwise treat the request as if it were a GET, and apply the errors dictionary to the form. This means that the 99% of the time that a POST fails validation and goes to the GET page is catered for for free. (The current method is to explicitly set error_handler.) 3. I'm a little skeptical about this one, but my next step is to pre-populate the "template name" that will be used with a name based on the controller and action name. This means that the 99% of the time that each separate non-redirecting page has a template with a consistent name is dealt with for free. (You still need to mark that the method is exposed, just not the template to use.) Once set up, this really has saved time and kept things very simple for us. I think it's also the sort of thing that should be pretty easy to document, that won't get in the way of people who prefer the explicit route, and that can be configured on a per-controller basis. In fact, I think there may be quite a lot of value in putting more power into the controller objects (FooController, rather than the method "foo"), and that this could mean sharing the same controller object semantics between the Routes and object dispatch methods. In other words, rather than having all the calling logic in TurboGearsController, the controller class (FooController) could inherit from "BaseController", which has that logic in it. This means that there can be subtle changes in how the logic plays out - for example, using htmlfill after the response to a page that had failed validation. Or using an entirely different validation system. I think that fits in with the TG idea of allowing choices so that people don't have to go elsewhere when there's a 5% chunk that TG makes near-impossible. This also creates a place (ie, a particular Controller class to inherit from) where we can create some backwards-compatibility. >From my cursory look at the code, it looks like I could create a patch in a day or two if people thought this approach was worth pursuing. Neil -- Neil Blakey-Milner http://nxsy.org/ [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
