Anybody use web2py?
Abhinav Sood
abhinav.sood at radbox.me
Thu Mar 3 05:50:14 EST 2011
We have built Radbox.me on web2py and it's amazing..
> 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 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
>>>>>>>>>>>>>>> On Sunday, December 20, 2009 5:57 PM mdipierro wrote:
>>>>>>>>>>>>>>> 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).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 }}
>>>>>>>>>>>>>>>>>>>>> (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 !=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
>>>>>>>>>>>>>>>>>>>>>> On Monday, December 21, 2009 11:08 AM Yarko wrote:
>>>>>>>>>>>>>>>>>>>>>> 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 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
>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, December 22, 2009 1:16 PM mdipierro wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Some may find useful to compare:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - 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
>>>>>>>>>>>>>>>>>>>>>>>> Submitted via EggHeadCafe
>>>>>>>>>>>>>>>>>>>>>>>> C# Dynamic XElement wrapper
>>>>>>>>>>>>>>>>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/b830e703-480e-4dde-a957-bda9b6fc8d47/c-dynamic-xelement-wrapper.aspx
More information about the Python-list
mailing list