For my part, I'm a true fan of web.py. I've used most of the options out there at least once, from ASP.NET to Django to Rails. Each has a purpose, some (Rails) were just too damn complicated for me personally to get my head around and others (.NET) just don't make it easy for you to do thing any way other than the (well documented yet often inefficient) way.
All these options out there work well for what I'll call a "moderately basic" web application, but fall short when things (inevitably) get complicated. We've all at least once spend days trying to jump some hurdle because our application is just "special" and our toolkit just doesn't quite fit. For example: I don't wanna be forced to abstract my database into objects and compartmentalize my code into MVC. (I like sql, and am good at it.) I don't wanna have four technologies (html/css/js/php) intertwined all in one file. I don't want to compile all my code every time I change one line just to test it. Some of my objects actually have sub-classes six levels deep. Most of my objects have at least a dozen methods, can be queried for presentation in multiple ways (list, edit dialog, draggable item, etc), and can deliver themselves in dictionary, json or xml format. Web.py empowered me to start working immediately, without having to mess around with any of the HTTP crap. Since my pages are well more complicated than tables, buttons and forms, I've not used the templating bit. Because I already had a solid database layer (and my application connects to multiple databases defined customly at runtime) I could not use the built in db layer. My point? In my opinion, web.py fulfills and stays true to it's mantra. I rebuilt an enterprise application from the ground up in python in 10 weeks, by simply "thinking about the ideal way to write it" then making it happen. Every other tool I looked at was a barrier - web.py was an enabler. For me. Your mileage may vary. NSC P.S. As others have said... yes, I do agree when getting started the documentation was kindof annoying. I think the community here would deliver some great, practical tutorials if a wiki were started and opened up for contribution. I'll write at least two. On Thursday, February 23, 2006 9:59:26 AM UTC-5, Aaron Swartz wrote: > > > Inventing yet another template language... > > You don't have to use it -- each part of web.py is completely separate > from the others. But you're right, it is "yet another template > language". And I'm not going to apologize for it. > > The goal of web.py is to build the ideal way to make web apps. If > reinventing old things with only small differences were necessary to > achieve this goal, I would defend reinventing them. The difference > between the ideal way and the almost-ideal way is, as Mark Twain > suggested, the difference between the lighting and the lightning bug. > > But these aren't just small differences. Instead of exposing Python > objects, web.py allows you to build HTTP responses. Instead of trying > to make the database look like an object, web.py makes the database > easier to use. And instead of coming up with yet another way to write > HTML, the web.py template system tries to bring Python into HTML. Not > many other people are really trying to do that. > > You can disagree that these ways are better and say why. But simply > criticizing them for being different is a waste of time. Yes, they are > different. That's the whole point. > > -- You received this message because you are subscribed to the Google Groups "web.py" group. To view this discussion on the web visit https://groups.google.com/d/msg/webpy/-/OaRLuD9idkgJ. 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.
