Just curious if anybody prefers web2py over django, and visa versa. I know it's been discussed on a flame war level a lot. I am looking for a more intellectual reasoning behind using one or the other.
On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote:
> Just curious if anybody prefers web2py over django, and visa versa. I > know it's been discussed on a flame war level a lot. I am looking for a > more intellectual reasoning behind using one or the other.
Chevy or Ford? (or whatever pair you prefer) vi or emacs? <pick your favorite two long-lasting world religions>...
These hold one aspect.
Hammer or a saw?
Hold (perhaps) another...
us.pycon.org, for example, uses both (in reality a mix of the above argument sets, but at least evidence of the latter: different tools for different problems).
From a rapid prototyping perspective, web2py is heavily data-table efficient: that is, you can define a system, and all the app creation, form generation and validation have defaults out of the box, and you can have a "sense" of your data-centric structure in minutes. The same argument can go against ("how do I get it to do exactly what _I_ want it to, not what it wants to?") - that is, defaults hide things, and that has two edges...
From a layout/user interaction rapid prototyping perspective, web2py is just entering the waters...
There is a steady growth of users, and (as you would expect for a young framework), a lot of changes going on (although backward compatiblity is a constant mantra when considering changes, that too is a double-edged thing).
I find web2py useful, fast, and at times / in areas not as evolved / flexible as I'd like. BUT I could learn it quickly, and get to work quickly.
I have taken an intro Django course (at a PyCon), have built a few things with it (not nearly as many as I have w/ web2py), and I _can_ do things in it - so I'll let someone else w/ django "miles" under their belt speak their mind.
> On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote:
> > Just curious if anybody prefers web2py over django, and visa versa. I > > know it's been discussed on a flame war level a lot. I am looking for a > > more intellectual reasoning behind using one or the other.
> Chevy or Ford? (or whatever pair you prefer) > vi or emacs? > <pick your favorite two long-lasting world religions>...
> These hold one aspect.
> Hammer or a saw?
> Hold (perhaps) another...
> us.pycon.org, for example, uses both (in reality a mix of the above > argument sets, but at least evidence of the latter: different tools > for different problems).
> From a rapid prototyping perspective, web2py is heavily data-table > efficient: that is, you can define a system, and all the app creation, > form generation and validation have defaults out of the box, and you > can have a "sense" of your data-centric structure in minutes. The > same argument can go against ("how do I get it to do exactly what _I_ > want it to, not what it wants to?") - that is, defaults hide things, > and that has two edges...
> From a layout/user interaction rapid prototyping perspective, web2py > is just entering the waters...
> There is a steady growth of users, and (as you would expect for a > young framework), a lot of changes going on (although backward > compatiblity is a constant mantra when considering changes, that too > is a double-edged thing).
> I find web2py useful, fast, and at times / in areas not as evolved / > flexible as I'd like. BUT I could learn it quickly, and get to work > quickly.
Oh and one more thing: I find it dependable (not that snapshots don't have bugs, but that they are well defined, not "wild", and quickly fixed - and if you work around them, you can also depend on the system you've created). FYI, it does the money/registration part of PyCon (past 2 years).
> I have taken an intro Django course (at a PyCon), have built a few > things with it (not nearly as many as I have w/ web2py), and I _can_ > do things in it - so I'll let someone else w/ django "miles" under > their belt speak their mind.
On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote:
> Just curious if anybody prefers web2py over django, and visa versa. I > know it's been discussed on a flame war level a lot. I am looking for a > more intellectual reasoning behind using one or the other.
Of course I am the most biased person in the world on this topic but perhaps you want to hear my bias.
A little bit of history... I thought a Django course at DePaul University and built a CMS for the United Nations in Django. I loved it. Then I also learned RoR. I found RoR more intuitive and better for rapid prototyping. I found Django much faster and more solid. I decided to build a proof of concept system that was somewhat in between Django and Rails with focus on 3 features: 1) easy to start with (no installation, no configuration, web based IDE, web based testing, debugging, and database interface); 2) enforce good practice (MVC, postbacks); 3) secure (escape all output, talk to database via DAL to present injections, server-side cookies with uuid session keys, role based access control with pluggable login methods, regex validation for all input including URLs).
Originally it was a proof of concept, mostly suitable for teaching. Then lots of people helped to make it better and turn it into a production system. Now he had more than 50 contributors and a more than 20 companies that provide support.
There are some distinctive features of web2py vs Django. Some love them, some hate hate them (mostly people who did not try them):
- We promise backward compatibility. I do not accept patches that break it. It has been backward compatible for three years and I will enforce the copyright, if necessary, in order to ensure it for the future.
- In web2py models and controllers are not modules. They are not imported. They are executed. This means you do not need to import basic web2py symbols. They are already defined in the environment that executes the models and controllers (like in Rails). This also means you do not need to restart the web server when you edit your app. You can import additional modules and you can define modules if you like.
- You have a web based IDE with editor, some conflict resolution, Mercurial integration, ticketing system, web-based testing and debugging.
- The Database Abstraction Layer (DAL) is closed to SQL than Dango ORM is. This means it does less for you (in particular about many 2 many) but it is more flaxible when it comes to complex joins, aggregates and nested selects.
- The DAL supports out of the box SQLite, MySQL, PostgreSQL, MSSQL, Oracle, FireBird, FireBase, DB2, Informix, Ingres, and the Google App Engine (except for joins and multi-entity transactions). We plan support for Sybase and MongoDB within one month.
- The DAL supports transactions. It means it will create and/or ALTER tables for you as your model changes. This can be disabled.
- The DAL has partial support for some legacy databases that do not have an 'id' auto increment primary key.
- It has a plugin and a component systems (here is an old video: http://www.vimeo.com/7182692 the video says "experimental" but this is now stable in trunk, although not very well documented).
- both systems have a web based database interface (Django calls it "admin", web2py calls it "appadmin, not to be confused with web2py "admin", the IDE). The Django one is more polished, customizable and designed to be exposed to users. The web2py one is raw and designed for the administrator. It is not customizable. Because it is designed for the administrator and requires administrator login it allows arbitrary DAL code to be executed. It can be disabled.
Here http://www.vimeo.com/6507384 you can see a video in which I rewrite the Django polls tutorial in web2py. You will get an idea of some of the differences.
Anyway, I think both system are great. Spend 15 minutes (no more) with each to make up your mind, and stick with it.
Errata. I said "The dal supports transactions" where I meant "the dal supports migrations". Of course it also supports "transactions" as well as "distributed transactions".
On Dec 19, 5:32 pm, mdipierro <massimodipierr...@gmail.com> wrote:
> On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote:
> > Just curious if anybody prefers web2py over django, and visa versa. I > > know it's been discussed on a flame war level a lot. I am looking for a > > more intellectual reasoning behind using one or the other.
> Of course I am the most biased person in the world on this topic but > perhaps you want to hear my bias.
> A little bit of history... I thought a Django course at DePaul > University and built a CMS for the United Nations in Django. I loved > it. Then I also learned RoR. I found RoR more intuitive and better for > rapid prototyping. I found Django much faster and more solid. I > decided to build a proof of concept system that was somewhat in > between Django and Rails with focus on 3 features: 1) easy to start > with (no installation, no configuration, web based IDE, web based > testing, debugging, and database interface); 2) enforce good practice > (MVC, postbacks); 3) secure (escape all output, talk to database via > DAL to present injections, server-side cookies with uuid session keys, > role based access control with pluggable login methods, regex > validation for all input including URLs).
> Originally it was a proof of concept, mostly suitable for teaching. > Then lots of people helped to make it better and turn it into a > production system. Now he had more than 50 contributors and a more > than 20 companies that provide support.
> There are some distinctive features of web2py vs Django. Some love > them, some hate hate them (mostly people who did not try them):
> - We promise backward compatibility. I do not accept patches that > break it. It has been backward compatible for three years and I will > enforce the copyright, if necessary, in order to ensure it for the > future.
> - In web2py models and controllers are not modules. They are not > imported. They are executed. This means you do not need to import > basic web2py symbols. They are already defined in the environment that > executes the models and controllers (like in Rails). This also means > you do not need to restart the web server when you edit your app. You > can import additional modules and you can define modules if you like.
> - You have a web based IDE with editor, some conflict resolution, > Mercurial integration, ticketing system, web-based testing and > debugging.
> - The Database Abstraction Layer (DAL) is closed to SQL than Dango ORM > is. This means it does less for you (in particular about many 2 many) > but it is more flaxible when it comes to complex joins, aggregates and > nested selects.
> - The DAL supports out of the box SQLite, MySQL, PostgreSQL, MSSQL, > Oracle, FireBird, FireBase, DB2, Informix, Ingres, and the Google App > Engine (except for joins and multi-entity transactions). We plan > support for Sybase and MongoDB within one month.
> - The DAL supports transactions. It means it will create and/or ALTER > tables for you as your model changes. This can be disabled.
> - The DAL has partial support for some legacy databases that do not > have an 'id' auto increment primary key.
> - It has a plugin and a component systems (here is an old video:http://www.vimeo.com/7182692the video says "experimental" but this is > now stable in trunk, although not very well documented).
> - both systems have a web based database interface (Django calls it > "admin", web2py calls it "appadmin, not to be confused with web2py > "admin", the IDE). The Django one is more polished, customizable and > designed to be exposed to users. The web2py one is raw and designed > for the administrator. It is not customizable. Because it is designed > for the administrator and requires administrator login it allows > arbitrary DAL code to be executed. It can be disabled.
> Herehttp://www.vimeo.com/6507384you can see a video in which I > rewrite the Django polls tutorial in web2py. You will get an idea of > some of the differences.
> Anyway, I think both system are great. Spend 15 minutes (no more) with > each to make up your mind, and stick with it.
On Dec 19, 1:42 am, AppRe Godeck <a...@godeck.com> wrote:
> Just curious if anybody prefers web2py over django, and visa versa. I > know it's been discussed on a flame war level a lot. I am looking for a > more intellectual reasoning behind using one or the other.
Hi! I come from a mvc framework background in a few different languages (java, php, ruby). I'm only a couple weeks into web2py, I'm finding web2py a joy to work with. I won't waste your time with the features it provides, as you can find these on the website. There is also a copy of the lead developer's book on the site, and its very well written.
If web2py intrigues you, I would recommend just trying it for a few days. It's pretty small (relatively few exposed classes and functions) and very comprehensible, so you won't really have to invest much if you decide to try it and don't like it. The mailing list is active and responsive, and the lead developer happens to have chimed in on every question i've asked. On the down side, the irc community is very small.
Errata 2. Before people jump on me. I said "copyright" but I meant "trademark". Of course web2py is GPL2 so everybody can copy and modify it.
The license has an exception that basically treats the compiled web2py as freeware.
The license does not extend to apps that require web2py. They can be distributed under any license you like, included closed source and bundled with the web2py binary.
On Dec 19, 5:32 pm, mdipierro <massimodipierr...@gmail.com> wrote:
> On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote:
> > Just curious if anybody prefers web2py over django, and visa versa. I > > know it's been discussed on a flame war level a lot. I am looking for a > > more intellectual reasoning behind using one or the other.
> Of course I am the most biased person in the world on this topic but > perhaps you want to hear my bias.
> A little bit of history... I thought a Django course at DePaul > University and built a CMS for the United Nations in Django. I loved > it. Then I also learned RoR. I found RoR more intuitive and better for > rapid prototyping. I found Django much faster and more solid. I > decided to build a proof of concept system that was somewhat in > between Django and Rails with focus on 3 features: 1) easy to start > with (no installation, no configuration, web based IDE, web based > testing, debugging, and database interface); 2) enforce good practice > (MVC, postbacks); 3) secure (escape all output, talk to database via > DAL to present injections, server-side cookies with uuid session keys, > role based access control with pluggable login methods, regex > validation for all input including URLs).
> Originally it was a proof of concept, mostly suitable for teaching. > Then lots of people helped to make it better and turn it into a > production system. Now he had more than 50 contributors and a more > than 20 companies that provide support.
> There are some distinctive features of web2py vs Django. Some love > them, some hate hate them (mostly people who did not try them):
> - We promise backward compatibility. I do not accept patches that > break it. It has been backward compatible for three years and I will > enforce the copyright, if necessary, in order to ensure it for the > future.
> - In web2py models and controllers are not modules. They are not > imported. They are executed. This means you do not need to import > basic web2py symbols. They are already defined in the environment that > executes the models and controllers (like in Rails). This also means > you do not need to restart the web server when you edit your app. You > can import additional modules and you can define modules if you like.
> - You have a web based IDE with editor, some conflict resolution, > Mercurial integration, ticketing system, web-based testing and > debugging.
> - The Database Abstraction Layer (DAL) is closed to SQL than Dango ORM > is. This means it does less for you (in particular about many 2 many) > but it is more flaxible when it comes to complex joins, aggregates and > nested selects.
> - The DAL supports out of the box SQLite, MySQL, PostgreSQL, MSSQL, > Oracle, FireBird, FireBase, DB2, Informix, Ingres, and the Google App > Engine (except for joins and multi-entity transactions). We plan > support for Sybase and MongoDB within one month.
> - The DAL supports transactions. It means it will create and/or ALTER > tables for you as your model changes. This can be disabled.
> - The DAL has partial support for some legacy databases that do not > have an 'id' auto increment primary key.
> - It has a plugin and a component systems (here is an old video:http://www.vimeo.com/7182692the video says "experimental" but this is > now stable in trunk, although not very well documented).
> - both systems have a web based database interface (Django calls it > "admin", web2py calls it "appadmin, not to be confused with web2py > "admin", the IDE). The Django one is more polished, customizable and > designed to be exposed to users. The web2py one is raw and designed > for the administrator. It is not customizable. Because it is designed > for the administrator and requires administrator login it allows > arbitrary DAL code to be executed. It can be disabled.
> Herehttp://www.vimeo.com/6507384you can see a video in which I > rewrite the Django polls tutorial in web2py. You will get an idea of > some of the differences.
> Anyway, I think both system are great. Spend 15 minutes (no more) with > each to make up your mind, and stick with it.
On Sat, 19 Dec 2009 12:48:07 -0800, Yarko wrote: > On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote: >> Just curious if anybody prefers web2py over django, and visa versa. I >> know it's been discussed on a flame war level a lot. I am looking for a >> more intellectual reasoning behind using one or the other.
> Chevy or Ford? (or whatever pair you prefer) vi or emacs? > <pick your favorite two long-lasting world religions>...
> us.pycon.org, for example, uses both (in reality a mix of the above > argument sets, but at least evidence of the latter: different tools for > different problems).
> From a rapid prototyping perspective, web2py is heavily data-table > efficient: that is, you can define a system, and all the app creation, > form generation and validation have defaults out of the box, and you can > have a "sense" of your data-centric structure in minutes. The same > argument can go against ("how do I get it to do exactly what _I_ want it > to, not what it wants to?") - that is, defaults hide things, and that > has two edges...
> From a layout/user interaction rapid prototyping perspective, web2py is > just entering the waters...
> There is a steady growth of users, and (as you would expect for a young > framework), a lot of changes going on (although backward compatiblity is > a constant mantra when considering changes, that too is a double-edged > thing).
> I find web2py useful, fast, and at times / in areas not as evolved / > flexible as I'd like. BUT I could learn it quickly, and get to work > quickly.
> I have taken an intro Django course (at a PyCon), have built a few > things with it (not nearly as many as I have w/ web2py), and I _can_ do > things in it - so I'll let someone else w/ django "miles" under their > belt speak their mind.
> - Yarko
It seems that this is the biggest issue surrounding web2py, from my research, is the ability to customize the defaults (the easy). If all web2py offers is default views, then it may be good for proof of concept projects, however I can't see in my right mind, proofing an application, and then turning around to write it in django because more than the defaults is needed.
Thanks for your replies, I was hoping to hear from some django people as well. Especially if you choose django over web2py, and why.
If you have time to write,
Give a situation where you would prefer to have django over web2py, and then another situation you would prefer web2py over django, and why.
Why does web2py have classes that represent HTML? I can't see ever needing to write VIEW code in my controller, since thats what views are for.
It seems that even though web2py is fast, supports lots of features, the fact that in the end it gets in the way of doing what you want is it's downfall. Django, even though requiring more "ground work", this ground work becomes a solid foundation on which to build your application on.
> Why does web2py have classes that represent HTML? I can't see ever > needing to write VIEW code in my controller, since thats what views are > for.
You do not need to use but if, for example, you want to build a menu recursively, having a server-side presentation of the DOM allows to do it without string manipulation. It is safer and less error prone. Anyway, it is not something you must use.
Lots of the features are optional. Like the web based IDE. If you do not like it, you can use the shell like you use Django.
> It seems that even though web2py is fast, supports lots of features, the
> fact that in the end it gets in the way of doing what you want is it's > downfall. Django, even though requiring more "ground work", this ground > work becomes a solid foundation on which to build your application on.
What do you mean by "gets in the way"? Could you provide an example?
> On Sat, 19 Dec 2009 12:48:07 -0800, Yarko wrote: > > On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote: > >> Just curious if anybody prefers web2py over django, and visa versa. I > >> know it's been discussed on a flame war level a lot. I am looking for a > >> more intellectual reasoning behind using one or the other.
> > Chevy or Ford? (or whatever pair you prefer) vi or emacs? > > <pick your favorite two long-lasting world religions>...
> > These hold one aspect.
> > Hammer or a saw?
> > Hold (perhaps) another...
> tis the nature of man kind to war.
> > us.pycon.org, for example, uses both (in reality a mix of the above > > argument sets, but at least evidence of the latter: different tools for > > different problems).
> > From a rapid prototyping perspective, web2py is heavily data-table > > efficient: that is, you can define a system, and all the app creation, > > form generation and validation have defaults out of the box, and you can > > have a "sense" of your data-centric structure in minutes. The same > > argument can go against ("how do I get it to do exactly what _I_ want it > > to, not what it wants to?") - that is, defaults hide things, and that > > has two edges...
> > From a layout/user interaction rapid prototyping perspective, web2py is > > just entering the waters...
> > There is a steady growth of users, and (as you would expect for a young > > framework), a lot of changes going on (although backward compatiblity is > > a constant mantra when considering changes, that too is a double-edged > > thing).
> > I find web2py useful, fast, and at times / in areas not as evolved / > > flexible as I'd like. BUT I could learn it quickly, and get to work > > quickly.
> > I have taken an intro Django course (at a PyCon), have built a few > > things with it (not nearly as many as I have w/ web2py), and I _can_ do > > things in it - so I'll let someone else w/ django "miles" under their > > belt speak their mind.
> > - Yarko
> It seems that this is the biggest issue surrounding web2py, from my > research, is the ability to customize the defaults (the easy). If all > web2py offers is default views, then it may be good for proof of concept > projects, however I can't see in my right mind, proofing an application, > and then turning around to write it in django because more than the > defaults is needed.
> Thanks for your replies, I was hoping to hear from some django people as > well. Especially if you choose django over web2py, and why.
> If you have time to write,
> Give a situation where you would prefer to have django over web2py, and > then another situation you would prefer web2py over django, and why.
> Why does web2py have classes that represent HTML? I can't see ever > needing to write VIEW code in my controller, since thats what views are > for.
> It seems that even though web2py is fast, supports lots of features, the > fact that in the end it gets in the way of doing what you want is it's > downfall. Django, even though requiring more "ground work", this ground > work becomes a solid foundation on which to build your application on.
You need to realize that web2py is still a relatively young framework, issues to certain problems are currently being addressed in web2py. For example, the DAL is being re-written in a much more modular maner, allowing the addition of new database backends to be quite seemless. Other parts of web2py will follow as web2py grows I am sure. I wouldn't disqualify web2py based off what you read, you really need to try it for yourself, and if you run into a problem, I'm sure, some way there is a solution if you bring up the problem, and your problem might even help web2py to grow to be an even better framework.
I dare you to try developing a web application with both. Spend one day working on a simple django application, polls, blog, image gallery, family pet tree, you name it. Then take the next day, and write the same application with web2py, and you decide. In the end, both are tools and you need to figure out what is best for YOU.
On Dec 19, 2:42 pm, AppRe Godeck <a...@godeck.com> wrote:
> Just curious if anybody prefers web2py over django, and visa versa. I > know it's been discussed on a flame war level a lot. I am looking for a > more intellectual reasoning behind using one or the other.
Hi,
I am not very familiar with Django, anyway, my reasons for selecting web2py are:
- I believe Django naturally "fits in" to a publishing type of application. web2py seems to be more focussed on being a front-end to "applications" not so much for CMS type or newspaper type publishing. (There is a web2py based wiki/CMS app, though). Though, I agree either could fulfil any of these roles.
- Django documentation is vastly superior, including third party books etc. After the v2 Web2py book, we do have solid documentation, but web2py evolves so quickly, there are always things that are documented only on the google groups, slices or wiki.
- Many training courses are available pretty much everywhere for Django. Web2py needs to catch up - it will, probably.
- Web2py lowers the barrier to entry into python web programming, since it is well thought out and intuitive. The support on the mailing list is fantastic, though I have no idea how good the support for Django is. w2py is easy to pick up for even a python newbie.
- Massimo claims about the backward compatibility. I was surprised recently when I took an app I deployed several months (and several versions old) and retested it with the latest SVN code. And it worked fine! Which means, if my client asks for it, I could swap out old w2py with the latest code with no problems.
On Dec 20, 1:35 am, mdipierro <massimodipierr...@gmail.com> wrote:
> Errata. I said "The dal supports transactions" where I meant "the dal > supports migrations". > Of course it also supports "transactions" as well as "distributed > transactions".
Sorry, if this is not related to this topic. Does web2py support distributed transactions with Google App Engine Datastore?
The concept of distributed transaction does not make sense on GAE because there is only one datastore.
It supports regular transactions on GAE to the extent that GAE supports them but you have to use the GAE run_in_transaction API explictely.
It does support distributed transactions with multiple database connection to postgresq, mysql and/or firebird. I think this is related to the topic because it is a distinctive feature of web2py.
Massimo
On Dec 20, 1:32 pm, Lacrima <lacrima.ma...@gmail.com> wrote:
> On Dec 20, 1:35 am, mdipierro <massimodipierr...@gmail.com> wrote:
> > Errata. I said "The dal supports transactions" where I meant "the dal > > supports migrations". > > Of course it also supports "transactions" as well as "distributed > > transactions".
> Sorry, if this is not related to this topic. > Does web2py support distributed transactions with Google App Engine > Datastore?
> If all > web2py offers is default views, then it may be good for proof of concept > projects, however I can't see in my right mind, proofing an application, > and then turning around to write it in django because more than the > defaults is needed.
You *can* customize web2py views ...
> Why does web2py have classes that represent HTML? I can't see ever > needing to write VIEW code in my controller, since thats what views are > for.
I use these in my views when a HTML tag has multiple dynamic properties because it looks more neat.
I came to web2py a year back after writing applications in many other frameworks (Turbogears / Symonfy / Rails / Django) and find myself more productive with web2py. So as others have said - try both. Write a small application in both to see which suits you.
People seem to think that because web2py has a default for almost everything (part of its design) than you must use the default.
- There is a web based IDE but you *can* use the shell instead (like you do in Django) - There are migrations but you *can* disable then (and it works like Django that does not do migrations) - There are default views for every action but you *can* make your own - There is a default route to every action but you *can* create your own routes.py, equivalent to Django urls.py - There is a default for form layout but you *can* customize them in multiple ways - There is a default widget for every field but you *can* change it or define your own - There is a default validator for every field but you *can* change it or create your own - It comes with a default layout.html but you can user any other html/ css layout or make your own - It comes with jQuery but you *can* use any other javascript library - It default to email/password login but you *can* use other authentication methods (gmail, twitter, openid, rpx, cas, ldap). - etc.
The only things that web2py does not let you customize are things that have security implications (like how sessions and uploads are handled).
On Dec 20, 3:09 pm, Baron <richar...@gmail.com> wrote:
> > If all > > web2py offers is default views, then it may be good for proof of concept > > projects, however I can't see in my right mind, proofing an application, > > and then turning around to write it in django because more than the > > defaults is needed.
> You *can* customize web2py views ...
> > Why does web2py have classes that represent HTML? I can't see ever > > needing to write VIEW code in my controller, since thats what views are > > for.
> I use these in my views when a HTML tag has multiple dynamic > properties because it looks more neat.
> I came to web2py a year back after writing applications in many other > frameworks (Turbogears / Symonfy / Rails / Django) and find myself > more productive with web2py. > So as others have said - try both. Write a small application in both > to see which suits you.
> Thanks for your replies, I was hoping to hear from some django people as > well. Especially if you choose django over web2py, and why.
I don't know what a "django people" is - but if you mean "django core developper", I'm not one of them. Now wrt while I use Django instead of web2py, the answer is quite simple: web2py didn't exist when I started using Django !-)
> Spend one > day working on a simple django application, polls, blog, image > gallery, family pet tree, you name it. Then take the next day, and > write the same application with web2py, and you decide. In the end, > both are tools and you need to figure out what is best for YOU.
The problem is not how easy it makes to write a *simple* (should I say "braindead" ?) dummy test app, but how easy - or even possible -it makes writing and maintaining a *real-world* complex application.
> On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote: >> Just curious if anybody prefers web2py over django, and visa versa. I >> know it's been discussed on a flame war level a lot. I am looking for a >> more intellectual reasoning behind using one or the other.
> Of course I am the most biased person in the world on this topic
Indeed !-)
> - In web2py models and controllers are not modules. They are not > imported. They are executed.
I assume you mean "executed in an environment defined by the framework"...
> This means you do not need to import > basic web2py symbols. They are already defined in the environment that > executes the models and controllers
Ok. As far as I'm concerned : show stops here.
>(like in Rails). This also means > you do not need to restart the web server when you edit your app.
The dev server that comes with Django do the autorestart thing. And you *don't* "edit yoour app" directly on the production server, do you ?
> - You have a web based IDE with editor,
Why should I care ? I have a way better development environment on my own box.
> some conflict resolution, > Mercurial integration,
What if use something else than mercurial ?
> ticketing system,
...doesn't belong to the framework. FWIW, I already have a ticketing system that's language/techno agnostic, thanks.
> - The DAL supports transactions. It means it will create and/or ALTER > tables for you as your model changes.
Err... how does schema changes relates to transactions ???
Now FWIW, when my schema do change, the create/alter table code is usually the most trivial part - there are quite a few other things to do, that no framework will ever be abale to guess. IOW, you *do* have to write a migration script anyway.
> - The DAL has partial support for some legacy databases that do not > have an 'id' auto increment primary key.
Django's ORM has full support for tables that don't use an "auto_id" key.
> Anyway, I think both system are great. Spend 15 minutes (no more) with > each to make up your mind, and stick with it.
Once again, while doing a quick dummy test app can give you a first general "feel" of the tool, it means nothing wrt/ complex real-world applications.
> On Dec 19, 2:42 pm, AppRe Godeck <a...@godeck.com> wrote: >> Just curious if anybody prefers web2py over django, and visa versa. I >> know it's been discussed on a flame war level a lot. I am looking for a >> more intellectual reasoning behind using one or the other.
> Hi,
> I am not very familiar with Django, anyway, my reasons for selecting > web2py are:
> - I believe Django naturally "fits in" to a publishing type of > application.
I just don't get why so many people have this antipattern... None of the projects I did with Django were on the CMS side. Django is *NOT* a "CMS-growned-into-a-framework" in any way, it's a web development framework, period.
Don't "believe", check.
> web2py seems to be more focussed on being a front-end to > "applications" not so much for CMS type or newspaper type publishing.
Please provide *any* evidence of your (plain wrong) assertions and assumptions...
> > On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote: > >> Just curious if anybody prefers web2py over django, and visa versa. I > >> know it's been discussed on a flame war level a lot. I am looking for a > >> more intellectual reasoning behind using one or the other.
> > Of course I am the most biased person in the world on this topic
> Indeed !-) > > - In web2py models and controllers are not modules. They are not > > imported. They are executed.
> I assume you mean "executed in an environment defined by the framework"...
yes
> > This means you do not need to import > > basic web2py symbols. They are already defined in the environment that > > executes the models and controllers
> Ok. As far as I'm concerned : show stops here.
It is your choice but, why? Exec/eval is only true distinctive feature of an interpreted language vs a compiled language.
> >(like in Rails). This also means > > you do not need to restart the web server when you edit your app.
> The dev server that comes with Django do the autorestart thing. And you > *don't* "edit yoour app" directly on the production server, do you ?
Unfortunately it has happened. In my experience the distinction between development and production is fiction.
> > - You have a web based IDE with editor,
> Why should I care ? I have a way better development environment on my > own box.
I only use emacs. I do not use the web based IDE much myself but I found it really helps in learning how to use the framework.
> > some conflict resolution, > > Mercurial integration,
> What if use something else than mercurial ?
You can use any version control you want, the same way you would in Django. web2py itself is version controlled in both bazaar and mercurial. The only think about mercurial is that, if you have it installed, the web based IDE lets you commit at the click on a <button>.
> > ticketing system,
> ...doesn't belong to the framework. FWIW, I already have a ticketing > system that's language/techno agnostic, thanks.
Perhaps we are not talking about the same thing. if an error occurs in a web2py application and I want: 1) notify the user, 2) assign the user a ticket number; 3) log the error in the framework; 4) allow administrator to browse past error logs; I think this belongs to the framework else it gets clunky. Web2py tickets are out of the box and always on.
> > - The DAL supports transactions. It means it will create and/or ALTER > > tables for you as your model changes.
> Err... how does schema changes relates to transactions ???
Type "migrations" not "transactions" sorry.
> Now FWIW, when my schema do change, the create/alter table code is > usually the most trivial part - there are quite a few other things to > do, that no framework will ever be abale to guess. IOW, you *do* have to > write a migration script anyway.
No. We do not have migration scripts. It is nothing like Rails. You just edit a model and, voila', database is migrated. Nothing to type. Nothing to click on. (you can disable it)
I respect you choosing Django but it looks like you have never tried web2py.
> > - The DAL has partial support for some legacy databases that do not > > have an 'id' auto increment primary key.
> Django's ORM has full support for tables that don't use an "auto_id" key.
web2py too has support for legacy databases for tables without an auto_id but not yet for all database back-ends.
> > Anyway, I think both system are great. Spend 15 minutes (no more) with > > each to make up your mind, and stick with it.
> Once again, while doing a quick dummy test app can give you a first > general "feel" of the tool, it means nothing wrt/ complex real-world > applications.
While this may be true as a general statement could you explain which feature you find in Django that is not in web2py and that is is crytical for building large web applications? Could you provide a coding example of such feature? This is an honest question because it can help us make web2py better. I have personally learned a lot from Django and thank the Django developers for their work, I would be happy to learn more.
On Dec 19, 8:39 pm, AppRe Godeck <a...@godeck.com> wrote:
> On Sat, 19 Dec 2009 12:48:07 -0800, Yarko wrote: > > On Dec 19, 12:42 am, AppRe Godeck <a...@godeck.com> wrote:
....
> It seems that this is the biggest issue surrounding web2py, from my > research, is the ability to customize the defaults (the easy). If all > web2py offers is default views, then it may be good for proof of concept > projects, however I can't see in my right mind, proofing an application, > and then turning around to write it in django because more than the > defaults is needed.
Perhaps I can clarify this: - You CAN customize defaults easily ... but the default setup is so easy, sometimes it's not initially clear where / how to do this in web2py.
For example: default views:
I updated (recently) the PyCon-2010 registration site so that it "looked" like the base PyCon-2010 (django) site. I copied some key css and image files, replaced the big header/footers in the web2py base layout (which is inherited by other views - also by default - so he effect cascaded exactly as I wanted).
To quickly morph what I wanted from the web2py app's existing view onto the new template (e.g., the menus, and the color/highlits of it's pulldowns) I went into a PC app (thru virtualbox): stylizer - and moved things around, changed the colors (e.g. of highlites) and saved the result. I then had cleaned it up. Total time to change the look: about 45 minutes (20 minutes of that playing around with Stylizer, enough to decide to use that for what I wanted to do).
In the result, the templating (or view) language in Web2Py is... um... *cough* ... *ahem* ... _simply pure python.
"How to I update the view?" comes up often for new people. "Just write the code and references you want to call up in the view." "How do I write them?" "Python."
This comes up over and over. How can you write python in view (html files)? How is indenting handled? That's perhaps the only thing the "templateing" language does: It makes some assumptions about indenting, so (for example) where context would signal the natural end of indenting, in the template language you add a "hint" to the template language: {{ pass }}.
To output to the view, leave the left side empty: {{ var='Output this text'; =var }} (result of var is output).
Another "how do I customize" question that comes up: data validation: there are 2 levels in the DAL: constraints which are defined in a table field, and passed on as a constraint in the db engine; constraints which are runtime in the request (e.g. in the web app). The latter is easy to programmatically modify per context. The first time you do validation this becomes clear.
Another place is form customization. You can customize forms. There are layers to this: in web2py, forms are automatically created for data objects. At one level, you have control over what data fields are exposed. At another, you have control over the type of object that is presented in the form (list? text field?) by the form of the validator you setup. This is one place where you have control over "default" behaviors, but still used lots of the default "engine". And you can create custom forms altogether.
Then there are viewports: Beside layouts / template (all the basic stuff you will recognize from most other frameworks - not just django), and more-or-less the same kind of inheritence model of views you might expect, there are a few things: the classes for HTML you asked about: If you reference those classes in your view, output and integration with any view code will happen for you (that is, prefer the class definition of bold to the html syntax, for you can pass arguments, escape, and put in other activity on the content and output within the HTML tag for which there is a class member. You'd mentioned "class" not being "view" - the first thing to let go of is "executable python code" is not the same thing as "controller", eg. view-logic != behavior-logic (business-rule, controller, whatever you are accustomed to calling this). Views have logic (just think of ajax calls, javascript, and now Python-for-template code). It's not "is it code that runs" that is the important question, it is "what is this code affecting?" - Presentation, "business logic", or persistence/data/model?
And then there's is automatic association of behavior with some part of your view: automatic controller assignment and ajax setup...
All the tools within web2py provide what you need to customize / change defaults. Perhaps "forms" are the ... least clear... have the most layers / ways to approach (or is it views? ;-). But there is a way for all, no reason to prototype and throw away. But you WILL be asking "how" at first, not doubt.
42.desthuilli...@websiteburo.invalid> wrote: > Thadeus Burgess a écrit : > (snip)
> > Spend one > > day working on a simple django application, polls, blog, image > > gallery, family pet tree, you name it. Then take the next day, and > > write the same application with web2py, and you decide. In the end, > > both are tools and you need to figure out what is best for YOU.
> The problem is not how easy it makes to write a *simple* (should I say > "braindead" ?) dummy test app, but how easy - or even possible -it makes > writing and maintaining a *real-world* complex application.
Bruno -
Check out the 50 minute coding-dojo we did at PyCon-2009: a complete news aggregation system, with authentication. There were people (who encouraged us to do the dojo) who doubted that we could cover so much ground in so little time. We asked WingIDE folks if they would donate a WingIDE for raffling at the dojo (to help draw people) - not only did they agree, then came and sat thru the dojo. At the end of the dojo,
I think most people there were amazed: they had a complete system, and insight into how to extend and keep going with developing it further (e.g. for their own needs). I know the person who won the copy of WingIDE was on the web2py list after, continuing to work on apps. Wing wrote up a "how-to" develop web2py apps directly from wing, and we added a hook to defer "tickets" (web2py traceback logs) to the wing exception reporting system, if running under Wing (http:// www.wingware.com/doc/howtos/web2py).
Hardly "brain-dead" (that is just a loaded term you threw out, but I see your skepticism). At some level, each programming activity decays to a "brain-dead" one, that is - to a trivially simple activity. However, a trivial activity (define a news aggregator, data tables; define a service to aggregate other data sources) does not equal a trivial result: in fact, the higher the level of abstraction I can make a _programmer_ activity trivially easy and still accomplish significant function, the more attention and time the programmer can spend on thinking about _the problem at hand_, rather than the _setting up of the system_.... This is precisely one of the benefits I've seen touted in numerous papers arguing for teaching either Flash (adobe) over Java, or Python over Java --> the decrease in time spent worrying about setup of the system used to address a given problem/ algorithm.
Easier / trivial setup in tool is good when it accomplishes what you need (e.g. gets out of your way, leaves more attention to the problem at hand).
42.desthuilli...@websiteburo.invalid> wrote: > mdipierro a écrit : ... > > This means you do not need to import > > basic web2py symbols. They are already defined in the environment that > > executes the models and controllers
> Ok. As far as I'm concerned : show stops here.
Sorry- I don't _think_ I'm following: If you want to write an app all yourself, and use components to put it together, that's fine - more control, and more responsibility (e.g. watch for security, etc.).
But most web applications simply do not require or justify this much effort spent on this level of "responsibility"; but maybe I'm missing something less obvious that you mean, that makes "the show stop here" for you. If so, maybe you can be a bit more explicit about it.
....
> > - You have a web based IDE with editor,
> Why should I care ? I have a way better development environment on my > own box.
For example, on a running system, simple things are possible simply: change the cutoff date on something; change a class size. Yeah, sure - my app could write a controller for all those _little_ unanticipated tweaks that inevitably come, but why bother? You can just do it with existing environment: Want 100 coupons for that vendor? No problem (lets say that's in a controller). Want to make it a special thingy for that special vendor - put his image on his coupons? his words and instructions? Ok - I suppose i might have written a wiki interface so someone can do this one thing, this one time - but (again) why bother? I'll do it thru the dev. interface on a running system. If I'm convinced it was an un-captured requirement (e.g. no one thought of it until the system was running, or it was "assumed" but somehow missed by everyone) then I'll write the associated code, and add it to the running system. In fact, this is quite an agile way to do it. Both the dev. environ, and the command line shell help in this (I can write a small loop in the shell to effect what might be a controller for a customer, and output to a file instead of a view, and ask the customer "Is this what you're looking for?" - tweak, confirm happy client, and then put the code I just used into a controller - if it's short enough, right in the interface on the running system, and have the client try it while we're still on the phone/IM/whatever.
The things I didn't think would be that useful - proved to have useful application.
......
> Now FWIW, when my schema do change, the create/alter table code is > usually the most trivial part - there are quite a few other things to > do, that no framework will ever be abale to guess. IOW, you *do* have to > write a migration script anyway.
In practice, this is /should be much less than you would think... ADDING columns to tables is simple. REMOVING columns... perhaps unnecessary on running systems... ALTERING columns... can probably be handled instead by adding.
I think for most useful (and certain development time) cases, the framework can do reasonable things, usefully. But I do not deny that there are cases where there is not way around doing things smarter than that. I think it is just that there are times where that is not as necessary as at first appears.
.....
> Once again, while doing a quick dummy test app can give you a first > general "feel" of the tool, it means nothing wrt/ complex real-world > applications.
Actually, I agree - and I would go a bit further: NO FRAMEWORK / tool has anything much to do wrt/ complex real-world apps. In fact, at the framework / coding level, things should be as simple as possible (that is where the cost is, anyway).
Good analysis of the problem domain will suggest the shape of the solution needed. Prototyping will then help with things like "can it be a web app?" and "what technologies / implementation languages are appropriate?" Once you're at that stage, _any tool_ (and most likely, combination of tools / set of tools) come into play: what do they do to help at this level, how do they enable the process you want to follow, how do they get out of the way. Are they too rigid (too many defaults / too few options for a given solution decision)?
But this is so far down the path of designing a solution that "complex real-world" doesn't fitthis discussion, without getting more specific, e.g. _a_ specific real-world app. For PyCon, web2py registration was done, reviewed, and put into place with little more than a month's worth of discussion / prep. Yeah, it didn't "look" like the main PyCon site the first year (and didn't take much at all to change that when I decided to). Yeah, there are still details about integrating w/ the django part of the site that could be taken care of from the web2py end (I don't know, but was lead to believe it would be easier from the web2py end than the django end, e.g. multiple database connections). As with many projects, if it is volunteer programming, and if it's _really_ important, it will happen, or if someone _really_ wants to do it - otherwise it's not evidence of anything more than something that's not really all that important. A few years ago, there was a challenge app (build a survey building app) that web2py finished, and donated in < 24 hrs; no one else either completed, knew of, or whatever - point is, if you _really_ want to make claims like this, then setup an essential ingredient that you are convinced is really beneficial - define it such that everyone agrees that it's a good definition: it will either be a key deciding point (and helpful to the community - "a does this; b does not"), or it will be a challenge point that can be tested (e.g. two solution approaches can be devised by "those who know the tools", and inspected and reviewed by the community - also helpful). Anything else is just opinion and talk - and to be sure, there is room for opinion, talk, and preferences (no one really _needs_ to convince a Ford owner to drive a Chevy - until some level of bankruptcy happens, it really doesn't matter). But even there, it is a benefit to the community in general to separate the talk from the real deciding factors. Thankfully, preference will always play a part.
They basically describe the same app and the steps to built it. Sorry I had not time to make screenshots.
I personally think it is great that we can learn from each other from this kind of comparison and we can both improve. I also think that stressing the similarities and the differences will help prospective users understand the underlying design patterns.
> On Saturday, December 19, 2009 1:42 AM AppRe Godeck wrote: > Just curious if anybody prefers web2py over django, and visa versa. I > know it is been discussed on a flame war level a lot. I am looking for a > more intellectual reasoning behind using one or the other. >> On Saturday, December 19, 2009 3:48 PM Yarko wrote: >> Chevy or Ford? (or whatever pair you prefer) >> vi or emacs? >> <pick your favorite two long-lasting world religions>...
>> These hold one aspect.
>> Hammer or a saw?
>> Hold (perhaps) another...
>> us.pycon.org, for example, uses both (in reality a mix of the above >> argument sets, but at least evidence of the latter: different tools >> for different problems).
>> From a rapid prototyping perspective, web2py is heavily data-table >> efficient: that is, you can define a system, and all the app creation, >> form generation and validation have defaults out of the box, and you >> can have a "sense" of your data-centric structure in minutes. The >> same argument can go against ("how do I get it to do exactly what _I_ >> want it to, not what it wants to?") - that is, defaults hide things, >> and that has two edges...
>> From a layout/user interaction rapid prototyping perspective, web2py >> is just entering the waters...
>> There is a steady growth of users, and (as you would expect for a >> young framework), a lot of changes going on (although backward >> compatiblity is a constant mantra when considering changes, that too >> is a double-edged thing).
>> I find web2py useful, fast, and at times / in areas not as evolved / >> flexible as I'd like. BUT I could learn it quickly, and get to work >> quickly.
>> I have taken an intro Django course (at a PyCon), have built a few >> things with it (not nearly as many as I have w/ web2py), and I _can_ >> do things in it - so I will let someone else w/ django "miles" under >> their belt speak their mind.
>> - Yarko >>> On Saturday, December 19, 2009 3:51 PM Yarko wrote: >>> Oh and one more thing: I find it dependable (not that snapshots do not >>> have bugs, but that they are well defined, not "wild", and quickly >>> fixed - and if you work around them, you can also depend on the system >>> you have created). FYI, it does the money/registration part of PyCon >>> (past 2 years). >>>> On Saturday, December 19, 2009 6:32 PM mdipierro wrote: >>>> Of course I am the most biased person in the world on this topic but >>>> perhaps you want to hear my bias.
>>>> A little bit of history... I thought a Django course at DePaul >>>> University and built a CMS for the United Nations in Django. I loved >>>> it. Then I also learned RoR. I found RoR more intuitive and better for >>>> rapid prototyping. I found Django much faster and more solid. I >>>> decided to build a proof of concept system that was somewhat in >>>> between Django and Rails with focus on 3 features: 1) easy to start >>>> with (no installation, no configuration, web based IDE, web based >>>> testing, debugging, and database interface); 2) enforce good practice >>>> (MVC, postbacks); 3) secure (escape all output, talk to database via >>>> DAL to present injections, server-side cookies with uuid session keys, >>>> role based access control with pluggable login methods, regex >>>> validation for all input including URLs).
>>>> Originally it was a proof of concept, mostly suitable for teaching. >>>> Then lots of people helped to make it better and turn it into a >>>> production system. Now he had more than 50 contributors and a more >>>> than 20 companies that provide support.
>>>> There are some distinctive features of web2py vs Django. Some love >>>> them, some hate hate them (mostly people who did not try them):
>>>> - We promise backward compatibility. I do not accept patches that >>>> break it. It has been backward compatible for three years and I will >>>> enforce the copyright, if necessary, in order to ensure it for the >>>> future.
>>>> - In web2py models and controllers are not modules. They are not >>>> imported. They are executed. This means you do not need to import >>>> basic web2py symbols. They are already defined in the environment that >>>> executes the models and controllers (like in Rails). This also means >>>> you do not need to restart the web server when you edit your app. You >>>> can import additional modules and you can define modules if you like.
>>>> - You have a web based IDE with editor, some conflict resolution, >>>> Mercurial integration, ticketing system, web-based testing and >>>> debugging.
>>>> - The Database Abstraction Layer (DAL) is closed to SQL than Dango ORM >>>> is. This means it does less for you (in particular about many 2 many) >>>> but it is more flaxible when it comes to complex joins, aggregates and >>>> nested selects.
>>>> - The DAL supports out of the box SQLite, MySQL, PostgreSQL, MSSQL, >>>> Oracle, FireBird, FireBase, DB2, Informix, Ingres, and the Google App >>>> Engine (except for joins and multi-entity transactions). We plan >>>> support for Sybase and MongoDB within one month.
>>>> - The DAL supports transactions. It means it will create and/or ALTER >>>> tables for you as your model changes. This can be disabled.
>>>> - The DAL has partial support for some legacy databases that do not >>>> have an 'id' auto increment primary key.
>>>> - It has a plugin and a component systems (here is an old video: >>>> http://www.vimeo.com/7182692 the video says "experimental" but this is >>>> now stable in trunk, although not very well documented).
>>>> - both systems have a web based database interface (Django calls it >>>> "admin", web2py calls it "appadmin, not to be confused with web2py >>>> "admin", the IDE). The Django one is more polished, customizable and >>>> designed to be exposed to users. The web2py one is raw and designed >>>> for the administrator. It is not customizable. Because it is designed >>>> for the administrator and requires administrator login it allows >>>> arbitrary DAL code to be executed. It can be disabled.
>>>> Here http://www.vimeo.com/6507384 you can see a video in which I >>>> rewrite the Django polls tutorial in web2py. You will get an idea of >>>> some of the differences.
>>>> Anyway, I think both system are great. Spend 15 minutes (no more) with >>>> each to make up your mind, and stick with it.
>>>> Massimo >>>>> On Saturday, December 19, 2009 6:35 PM mdipierro wrote: >>>>> Errata. I said "The dal supports transactions" where I meant "the dal >>>>> supports migrations". >>>>> Of course it also supports "transactions" as well as "distributed >>>>> transactions".
>>>>> w.vimeo.com/7182692the video says "experimental" but this is >>>>>> On Saturday, December 19, 2009 6:42 PM Jake wrote: >>>>>> Hi! I come from a mvc framework background in a few different >>>>>> languages (java, php, ruby). I am only a couple weeks into web2py, I am >>>>>> finding web2py a joy to work with. I will not waste your time with the >>>>>> features it provides, as you can find these on the website. There is >>>>>> also a copy of the lead developer's book on the site, and its very >>>>>> well written.
>>>>>> If web2py intrigues you, I would recommend just trying it for a few >>>>>> days. it is pretty small (relatively few exposed classes and >>>>>> functions) and very comprehensible, so you will not really have to invest >>>>>> much if you decide to try it and do not like it. The mailing list is >>>>>> active and responsive, and the lead developer happens to have chimed >>>>>> in on every question i've asked. On the down side, the irc community >>>>>> is very small.
>>>>>> Good Luck, >>>>>> Jake >>>>>>> On Saturday, December 19, 2009 7:07 PM mdipierro wrote: >>>>>>> Errata 2. Before people jump on me. I said "copyright" but I meant >>>>>>> "trademark". Of course web2py is GPL2 so everybody can copy and modify >>>>>>> it.
>>>>>>> The license has an exception that basically treats the compiled web2py >>>>>>> as freeware.
>>>>>>> The license does not extend to apps that require web2py. They can be >>>>>>> distributed under any license you like, included closed source and >>>>>>> bundled with the web2py binary.
>>>>>>> w.vimeo.com/7182692the video says "experimental" but this is >>>>>>>> On Saturday, December 19, 2009 9:39 PM AppRe Godeck wrote: >>>>>>>> tis the nature of man kind to war.
>>>>>>>> It seems that this is the biggest issue surrounding web2py, from my >>>>>>>> research, is the ability to customize the defaults (the easy). If all >>>>>>>> web2py offers is default views, then it may be good for proof of concept >>>>>>>> projects, however I cannot see in my right mind, proofing an application, >>>>>>>> and then turning around to write it in django because more than the >>>>>>>> defaults is needed.
>>>>>>>> Thanks for your replies, I was hoping to hear from some django people as >>>>>>>> well. Especially if you choose django over web2py, and why.
>>>>>>>> If you have time to write,
>>>>>>>> Give a situation where you would prefer to have django over web2py, and >>>>>>>> then another situation you would prefer web2py over django, and why.
>>>>>>>> Why does web2py have classes that represent HTML? I cannot see ever >>>>>>>> needing to write VIEW code in my controller, since thats what views are >>>>>>>> for.
>>>>>>>> It seems that even though web2py is fast, supports lots of features, the >>>>>>>> fact that in the end it gets in the way of doing what you want is it is >>>>>>>> downfall. Django, even though requiring more "ground work", this ground >>>>>>>> work
