On Nov 16, 2005, at 9:23 AM, Kevin Dangoor wrote:
How would you, in an ideal world, see the API as being different with events or "better filtering"? Always best to start with the ideal and then make tradeoffs as needed.
At least in the case of transactions, it would be nice if it wasn't a transaction per controller method, but a transaction per *request*, which isn't really handled by the decorator case. I think it _could_ be handled better by a filter-like approach.
What if my controller method calls another controller method that is also decorated to run inside a transaction? Will the decorator be smart enough to use the current transaction? In the case of a filter- based approach, you could instead start a transaction `onRequestStart`, rollback and display an error message `onRequestError`, and commit `onRequestEnd`. This way, irrespective of the code path, you are guaranteed one transaction-per-request in a simple and straightforward manner. In this way, I think of TurboGears as a container for my WSGI application. I manage the logic, it manages the boilerplate for transactions, logging, exceptions, etc.
In my darker days of ASP.NET development (*shudder*), I frequently used Global.asax, which provides filter capabilities very much like the above, for doing transactions and error handling. Its one of the only parts of ASP.NET that isn't entirely nauseating :)
-- Jonathan
