> Hello all, > > This list seems awfully quiet, so I'll post some questions here. > > - What's the status on 0.11? I'm confused if it's out or not. I'm > currently developping an app from branches/0.11. This version still > doens't seem fixed, right?
0.11 Release Candidate 1 is out, yes. There will be an RC2 next week. As Veikko said, we broke some things again, but it's well worth it, and we're really done now. The branch (david-execution_flow) will be merged to branches/0.11 this weekend. Once 0.11-final is out, development will occur in trunk again and the 0.11 branch will be updated if necessary (i.e. for urgent bug fixes that warrant a 0.11.x release) > - The new routing is very cool. Quite an improvement on 0.10. Congrats > on that. All in all, the new things I've tested seem to be > improvements. Thanks :) > - Performance does seem to be down a bit from 0.10 (haven't done any > benchmarks yet, just an impressions). I'm guessing there'll be some > benchmarking and speed optimization later? Yes, definitely. After 0.11, we won't change much anymore. We'll focus on all-new unit tests for the framework itself, performance improvements, some feature additions (support for more template engines, for instance), support for applicaiton unit tests and, most importantly, full documentation - www.djangobook.com is the benchmark (we'll have a similar system while the manuals are in beta where people can comment to give feedback). > - How do you handle e.g. the database being unavailable. I could check > everytime a db-connection is acquired and forward/redirect to a > 'DatabaseUnavailableAction', but that can get repetitive quickly. For > 0.10 I used a filter that did nothing more than catch > 'DatabaseUnavailable' or 'GatewayUnavailable' (for external resources > like soap) exceptions, logging them and redirect the user to a nice > page > saying that the database is unavailable. Which kind of filter shoud > this > be under 0.11? Global or Action? I tried making on, but I couldn't > forward. I got the following exception: > > For security reasons, Request Parameters cannot > be accessed directly. Please use the ParameterHolder object passed to > your Action or View execute method to access Request Parameters. > > Apparently this happens when the controller tries to add the action to > the actionstack. So I'm guessing I need to unlock the request before > forwarding, or should I redirect? What's the correct way to do this? > > Or is there a better way to do some of this global error handling? We now have a concept called exception templates, these can be configured (also per env, context and even per output type) and used to show error messages instead of the default screen. You bring up a pretty good point here, it might be wise to extend that so you can have templates that only catch a specific type of exception... David _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
