Hi. I'm replying more to the subject than the body, so I'll just put my reply up here.
I'm not sure these need to be "fixed". There are a lot of approaches to building webapps, and the various webapp frameworks largely represent different approaches, with some overlap. As you develop your own methods, you'll inevitably want to cover or replace parts of the framework you're using; some frameworks accomplish this by being modular, some don't really cater to it at all, and web.py manages this by being so small and simple that you can either rewrite the portions you want to, or just paper over them. The small size and simplicity of the core of web.py is the best thing about it, in my opinion. Like nostrademons, I don't use the templating system, because I have my own which I prefer, but it's easy enough just not to use it. Also, I prefer a pagelet model where each apparent page is usually in its own module on disk and decorators indicate actions to take at various stages of the response cycle. This is not especially compatible with web.py's web.run() system, but it took less than 60 lines of code to paper over web.run() and make my preferred system work. So, I like web.py precisely *because* it's easy to rewrite the parts which don't quite fit what you want to do. On Aug 8, 2007, at 5:11 AM, Green wrote: > > 3 points by nostrademons 7 hours ago | link > I've found that I had to gradually replace large parts of web.py as my > webapp evolved. For instance: > > I had to drop the built-in DB library once I needed to connect to > multiple databases. Global DB connections = bad. I suspect that if I'd > kept using it, I would've had problems with transactions too. > > I had to replace some of the request dispatching when I wanted to add > code that triggers on every request (eg. logging, transactions, custom > session management, "who's online?", traffic analytics). > > I had to drop the Cheetah integration to add internationalization > support - Cheetah supports the _ function, but only in precompiled > templates. > > I had to drop Cheetah entirely as the templates got a little more > complicated and I wanted to factor some bits out. Web.py patches the > Cheetah #include directive to do what you'd expect: include a file at > compile-time (which is the same as runtime under web.py). With > precompiled templates, however, it includes it at runtime, which means > the included file can't have any #defs. Big pain. > > It's not a bad framework to start out with, but you will end up > needing to ditch nearly all of it by the time you've handled > everything a typical webapp needs. If I were to do it over again, I'd > probably start with Pylons. I'd consider Django, but I'm not sure you > can swap out Django components the way you can with Pylons. > > > > -- Randall Randall <randall at randallsquared.com> (706) 536-2674 Backup -- software -- consulting --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web.py" 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/webpy?hl=en -~----------~----~----~----~------~----~------~--~---
