Hi, Other than trying to start a flame war, I don't see reasons for bringing my comment from the portuguese python group to here. Anyway, since Anthony cared to comment I'll also comment.
- I'm glad DAL was re-written. When I left web2py it was a mess and there were many objections to touching it. - I know it does not have an orm. To me, that is a disadvantage. ORM's were invented the same reason higher level programming languages were. They hide details allowing people to produce more with the same effort. -The manual mapping is a consequence of not having an orm. If you have a business model called Department for which there are a lot of domain-specific operations you want to perform (like, say, registering Teachers), you would probably declare a Python class with methods for these operations. When you go to the DAL and make a select for your Department, you get a Row (or whatever is called), not an instance of class Department. If magic is so great, why don't you like for the framework to magically transform the bytes from the DB into a Department? - Allowing arbitrary python code on the template is a first step for having templates filled with business logic especially when you work with not-so-perfectionist programmers. Web templates are already a mess because you can intermingle css+javascript+html. If the framework prevents another language to that party, great! Even if it means having to type a few extra chars in another file. - I agree that the magic regarding request execution is a matter of preference more than a technical one. - The editor is only useful if you're making your first steps in programming. For all other professional programmers it has no value. Even if it is a third party app, you still have to make sure that changes to web2py don't break anything. I think it would be much more useful, for instance, to build an orm on top of the dal. Anyway, I come in peace :) Regards, Quinta-feira, 3 de Maio de 2012 14:02:55 UTC+1, Anthony escreveu: > > Well, I had to use Google Translate, so not sure I got everything, but > here are a few thoughts: > > - Sounds like he used web2py quite a long time ago, before the DAL was > re-written, and before countless other improvements, so this is not really > a criticism of the current web2py. > - web2py does not have an ORM, it has a DAL. He seems to be thinking > the DAL was intended to be an ORM and somehow failed, hence his > disappointment. It's true that the DAL is closer to SQL, but it is not > "SQL > in disguise" (you don't have to know any SQL), and in particular, it uses > a > single universal syntax/API across all supported backends (just like an > ORM). This design actually makes the DAL more flexible than an ORM in > terms > of what it can model. The DAL also tends to be faster than ORMs. It would > be interesting to ask what he thinks he can do with the Django ORM that > could not easily be done with the DAL. Anyway, this is somewhat a matter > of > preference, though many web2py users consider the DAL to be one of > web2py's > great strengths. > - I don't understand what he's saying about objects returned by the > DAL (perhaps a translation issue). I'm not sure what mapping he thinks > needs to be done by hand. > - The complaint about views being difficult to maintain because they > include Python + HTML + Javascript doesn't make any sense -- that's > exactly > what Django does as well (though Django uses a specialized template > language rather than straight Python, but effectively no different in > terms > of inter-mixing of code and ease of maintenance). Perhaps he simply saw > some bad examples. > - Regarding "magic" and the existence of a few global API objects, > such as "request", so what? He seems to prefer the Django method of > importing and instantiating everything but doesn't explain the benefit of > that. Why does he like repeating the same boilerplate code everywhere for > objects as common as "request" and "response"? I refer him to the > following > quotes from Zed Shaw: > https://twitter.com/#!/zedshaw/status/80415443558477825, > https://twitter.com/#!/zedshaw/status/80418794526351360. > - Regarding executing models, I'm not sure exactly what he means about > overhead, but we now have conditional models, and you can always import > your models from modules, just like in Django. > - Regarding the admin editor, it is not intended to replace Vim, > Emacs, etc. It is just a convenience for minor editing and to help > beginners get started. Using it is completely optional, so it's an odd > reason to give for leaving web2py -- just don't use it. Also, it's a > third-party editor that was simply plugged in, so including it did not > take > away precious development time from the framework as he suggests (the > current web2py also has a much better editor than the one he would have > been using back then). > > Some further reading: > http://www.quora.com/What-are-the-advantages-of-web2py-over-Django > > Anthony > > On Thursday, May 3, 2012 7:40:45 AM UTC-4, Ramos wrote: >> >> a person just wrote this about web2py in a portuguese forum >> Anyone care to coment? >> >> >> Viva, >> >> Eu conheci primeiro o web2py e só uns meses depois o Django. >> Ao início achei bastante interessante (a ferramenta de admin, tutorial >> fácil de seguir, etc.). O que me fez saltar do web2py para o django e nunca >> voltar para trás foi, entre outros, o seguinte: >> >> - web2py não tem um ORM, tem uma api OO mas que segue o mesmo paradigma >> de SQL, No fundo, ao fazer .select() / .union() estamos a escrever SQL >> disfarçado. Um bom ORM permite não ter de escrever SQL em 90% dos casos, >> poupando trabalho. >> >> - Os objectos retornados pela camada de persistência do web2py não têm >> classes que façam sentido no domínio (Books, Persons, whatever seja o >> domínio), aquilo retorna umas instâncias de Record (ou lá o que é) que não >> são mais do que dicts. O mapeamento disso para instâncias de classes do >> domínio tem de ser feito à mão. >> >> - A ideia de poder meter python arbitrário no template parece gira mas >> facilmente descamba para ficheiros com python+html+javascript tudo >> entrelaçado e impossível de manter. >> >> - A magia da framework. Se bem me lembro os dados do request actual são >> postos em variáveis globais sem qualquer necessidade (podiam ser passados >> para a view, como no django). >> >> - Os models são executados ( exec() ) a cada pedido. Não há necessidade >> para este overhead. >> >> - Com tantos editores excelentes (emacs,vim,eclipse,vstudio,..),porquê >> usar um editor inferior no browser? Se gastarem tempo a trazer esse editor >> ao nível dos outros, perderam tempo que podia ter sido usado para melhorar >> outras partes da framework. >> >> - A qualidade do código é incomparável. Pequeno exemplo: Lembro-me que o >> núcleo da persistência do web2py na altura era um sql.py com algumas 3000 >> linhas, todo martelado com ifs para emitir SQL cozido ou assado consoante a >> BD e, de ver o Massimo* argumentar na mailing list que não era crítico >> melhorar aquela parte. >> >> Para mim, o web2py é bom como uma ferramenta de aprendizagem, nada mais. >> >> Cumprimentos. >> >
