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 -- http://mail.python.org/mailman/listinfo/python-list