Anybody use web2py?
AppRe Godeck
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.
Yarko
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.
- Yarko
Yarko
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).
mdipierro
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 is the last app I built with it: http://www.vimeo.com/7182692
running on GAE here: http://www.vimeo.com/7182692
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
mdipierro
supports migrations".
Of course it also supports "transactions" as well as "distributed
transactions".
> - 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.
>
> Here is the last app I built with it:http://www.vimeo.com/7182692
> running on GAE here:http://www.vimeo.com/7182692
>
> Herehttp://www.vimeo.com/6507384you can see a video in which I
Jake
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.
Good Luck,
Jake
mdipierro
"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:
> - 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.
>
> Here is the last app I built with it:http://www.vimeo.com/7182692
> running on GAE here:http://www.vimeo.com/7182692
>
> Herehttp://www.vimeo.com/6507384you can see a video in which I
AppRe Godeck
> 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.
mdipierro
> 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?
Thadeus Burgess
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.
Anand Vaidya
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
Lacrima
> 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?
mdipierro
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
Baron
> 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
mdipierro
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).
Bruno Desthuilliers
(snip)
> 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 !-)
Bruno Desthuilliers
(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 Desthuilliers
> 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.
Bruno Desthuilliers
> 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...
mdipierro
> >> 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.
Massimo
Yarko
> 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.
Hope this has been somewhat helpful.
- Yarko
Yarko
42.desthuilli...@websiteburo.invalid> wrote:
> Thadeus Burgess a écrit :
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).
- Yarko
Yarko
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.
Kind regards,
- Yarko
mdipierro
- A Crash Course on Django
http://articles.sitepoint.com/article/django-crash-course
- A Crash Course on Web2py
http://www.web2py.com/AlterEgo/default/show/253
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.
Massimo
Abhinav Sood
> 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).
>>>> - 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 is the last app I built with it: http://www.vimeo.com/7182692
>>>> running on GAE here: http://www.vimeo.com/7182692
>>>>
>>>>
>>>> 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 becomes a solid foundation on which to build your application on.
>>>>>>>>> On Saturday, December 19, 2009 10:04 PM mdipierro wrote:
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> features, the
>>>>>>>>>
>>>>>>>>> What do you mean by "gets in the way"? Could you provide an example?
>>>>>>>>>> On Saturday, December 19, 2009 11:21 PM Thadeus Burgess wrote:
>>>>>>>>>> a
>>>>>>>>>> n
>>>>>>>>>> t
>>>>>>>>>> t
>>>>>>>>>> s
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> would not disqualify web2py based off what you read, you really need to
>>>>>>>>>> try it for yourself, and if you run into a problem, I am 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 Saturday, December 19, 2009 11:30 PM Anand Vaidya wrote:
>>>>>>>>>>> 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
>>>>>>>>>>>> On Sunday, December 20, 2009 2:32 PM Lacrima wrote:
>>>>>>>>>>>> Sorry, if this is not related to this topic.
>>>>>>>>>>>> Does web2py support distributed transactions with Google App Engine
>>>>>>>>>>>> Datastore?
>>>>>>>>>>>>> On Sunday, December 20, 2009 3:14 PM mdipierro wrote:
>>>>>>>>>>>>> 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 Sunday, December 20, 2009 4:09 PM Baron wrote:
>>>>>>>>>>>>>> You *can* customize web2py views ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> t
>>>>>>>>>>>>>>> ,
>>>>>>>>>>>>>>>> On Monday, December 21, 2009 3:25 AM Bruno Desthuilliers wrote:
>>>>>>>>>>>>>>>> AppRe Godeck a ??crit :
>>>>>>>>>>>>>>>> (snip)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I do not know what a "django people" is - but if you mean "django core
>>>>>>>>>>>>>>>> developper", I am not one of them. Now wrt while I use Django instead of
>>>>>>>>>>>>>>>> web2py, the answer is quite simple: web2py did not exist when I started
>>>>>>>>>>>>>>>> using Django !-)
>>>>>>>>>>>>>>>>> On Monday, December 21, 2009 3:32 AM Bruno Desthuilliers wrote:
>>>>>>>>>>>>>>>>> Thadeus Burgess a ?crit :
>>>>>>>>>>>>>>>>> (snip)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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 Monday, December 21, 2009 3:50 AM Bruno Desthuilliers wrote:
>>>>>>>>>>>>>>>>>> mdipierro a ?crit :
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Indeed !-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I assume you mean "executed in an environment defined by the framework"...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ok. As far as I am concerned : show stops here.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The dev server that comes with Django do the autorestart thing. And you
>>>>>>>>>>>>>>>>>> *do not* "edit yoour app" directly on the production server, do you ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Why should I care ? I have a way better development environment on my
>>>>>>>>>>>>>>>>>> own box.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What if use something else than mercurial ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ...does not belong to the framework. FWIW, I already have a ticketing
>>>>>>>>>>>>>>>>>> system that is language/techno agnostic, thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Django's ORM has full support for tables that do not use an "auto_id" key.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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 Monday, December 21, 2009 3:55 AM Bruno Desthuilliers wrote:
>>>>>>>>>>>>>>>>>>> Anand Vaidya a ?crit :
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I just do not 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 is a web development
>>>>>>>>>>>>>>>>>>> framework, period.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Don't "believe", check.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please provide *any* evidence of your (plain wrong) assertions and
>>>>>>>>>>>>>>>>>>> assumptions...
>>>>>>>>>>>>>>>>>>>> On Monday, December 21, 2009 10:02 AM mdipierro wrote:
>>>>>>>>>>>>>>>>>>>> yes
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is your choice but, why?
>>>>>>>>>>>>>>>>>>>> Exec/eval is only true distinctive feature of an interpreted language
>>>>>>>>>>>>>>>>>>>> vs a compiled language.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Unfortunately it has happened.
>>>>>>>>>>>>>>>>>>>> In my experience the distinction between development and production is
>>>>>>>>>>>>>>>>>>>> fiction.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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>.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Type "migrations" not "transactions" sorry.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> web2py too has support for legacy databases for tables without an
>>>>>>>>>>>>>>>>>>>> auto_id but not yet for all database back-ends.
>>>>>>>>>>>>>>>>>>>>> On Monday, December 21, 2009 10:50 AM Yarko wrote:
>>>>>>>>>>>>>>>>>>>>> ....
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Perhaps I can clarify this:
>>>>>>>>>>>>>>>>>>>>> - You CAN customize defaults easily ... but the default setup is so
>>>>>>>>>>>>>>>>>>>>> easy, sometimes it is 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 is
>>>>>>>>>>>>>>>>>>>>> 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=3D'Output
>>>>>>>>>>>>>>>>>>>>> this text'; =3Dvar }}
>>>>>>>>>>>>>>>>>>>>> view-logic !=3D 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 is 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 is 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.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hope this has been somewhat helpful.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - Yarko
>>>>>>>>>>>>>>>>>>>>>> I have 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).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> - Yarko
>>>>>>>>>>>>>>>>>>>>>>> On Monday, December 21, 2009 3:50 PM Yarko wrote:
>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sorry- I do not _think_ I am following: If you want to write an app all
>>>>>>>>>>>>>>>>>>>>>>> yourself, and use components to put it together, that is 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 am 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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ....
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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 is 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 will do it thru the dev. interface on a running system. If
>>>>>>>>>>>>>>>>>>>>>>> I am 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 will 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 are looking for?" - tweak, confirm
>>>>>>>>>>>>>>>>>>>>>>> happy client, and then put the code I just used into a controller - if
>>>>>>>>>>>>>>>>>>>>>>> it is short enough, right in the interface on the running system, and
>>>>>>>>>>>>>>>>>>>>>>> have the client try it while we are still on the phone/IM/whatever.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The things I did not think would be that useful - proved to have useful
>>>>>>>>>>>>>>>>>>>>>>> application.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ......
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> .....
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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 are 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" does not 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 did not "look" like the main
>>>>>>>>>>>>>>>>>>>>>>> PyCon site the first year (and did not 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
>>>>>>>>>>>>>>>>>>>>>>>> Submitted via EggHeadCafe
>>>>>>>>>>>>>>>>>>>>>>>> C# Dynamic XElement wrapper
>>>>>>>>>>>>>>>>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/b830e703-480e-4dde-a957-bda9b6fc8d47/c-dynamic-xelement-wrapper.aspx