Prev: Setting Parameters inside of code
Next: Problem with Dynamically unloading a module
From: Anand Vaidya on 19 Dec 2009 23:30
On Dec 19, 2:42 pm, AppRe Godeck <a...(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.

My $0.02
From: Lacrima on 20 Dec 2009 14:32
On Dec 20, 1:35 am, mdipierro <massimodipierr...(a)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?
From: mdipierro on 20 Dec 2009 15:14
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...(a)gmail.com> wrote:
> On Dec 20, 1:35 am, mdipierro <massimodipierr...(a)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?

From: Baron on 20 Dec 2009 16:09
> 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.

Richard
From: mdipierro on 20 Dec 2009 17:57
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...(a)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.
>
> Richard

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Setting Parameters inside of code
Next: Problem with Dynamically unloading a module