Dear Tiago,
No problem at all. All comments can help us improve and or give us an
opportunity for clarification.
On Thursday, 3 May 2012 16:04:14 UTC-5, Tiago Almeida wrote:
>
> 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 do not remember objections. In fact it was rewritten two years ago. It
just took some time.
> - 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 only difference between a DAL and an ORM is that in the DAL tables are
instances of one Table class, in an ORM each table is its own class and
records are instances of that class. This distinction is mostly semantic.
In our case it I believe it makes dealing with joins, aggregates, and
combinations, more transparent. I do not believe we have any loss of
functionality because it is a DAL and not an ORM.
> -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?
>
Not sure I understand. We can do this:
Department = db.define_table('department',Field('name'))
Teacher =
db.define_table('teacher',Field('name'),Field('department',Departement))
Teacher.insert(name="Max",department=Department.insert(name="CDM"))
for teacher in db(Teacher).select():
print teacher.name, teacher.department.name
for department in db(Department).select():
print department.name
for teacher in department.teacher.select():
print '-',teacher.name
for row in db(Department.id==Teacher.department).select():
print row.teacher.name, row.department.name
> - 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.
>
We agree there should not be logic in templates but there are exceptions
(for example generating HTML recursively). We allow those exceptions.
> - 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.
>
I agree about the editor. I use emacs. I still do not see what an ORM buys
us that we do not already have. Can you provide an example.
> Anyway, I come in peace :)
>
>>
