First, welcome, and thanks for taking the time to share your thoughts. > Other than trying to start a flame war, I don't see reasons for bringing > my comment from the portuguese python group to here. >
I don't think anyone was trying to start a flame war. I assume he was just seeking clarification and perhaps a different perspective. I think most folks here welcome discussion about technical issues. > - I know it does not have an orm. > Sorry, perhaps that was a mistranslation, or just my misunderstanding of the point you were making. > 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. > I'm not sure an ORM necessarily provides *more* abstraction than the DAL so much as a different *type* of abstraction (an ORM does hide join tables for simple many-to-many relations with no extra fields, but some people prefer to model and access those tables directly). As for the nature of the abstraction, there are tradeoffs to consider. Here are some of Massimo's thoughts on the advantages of the DAL approach: https://groups.google.com/forum/#!msg/web2py/ro1CKfElZQI/4kQfmjrENt4J. He also notes that queries with aggregates, left joins, and nested selects are easier to do with the DAL. There are benefits to the ORM approach as well, so to a large extent this is probably a matter of preference. > -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. > This is a fair point, though I suspect in many cases what you would do with a model method in an ORM you could do with a computed field<http://web2py.com/books/default/chapter/29/6#Computed-fields>or virtual field <http://web2py.com/books/default/chapter/29/6#Virtual-fields> in the DAL (not sure if virtual fields were around back when you tried web2py). For an example of a more class-based approach to models in web2py, though, see https://github.com/rochacbruno/Movuca. > - 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 have seen such hypothetical concerns articulated before, but in practice, I haven't seen actual web2y users complain about this. Keep in mind that all requests in web2py get routed to a controller function, so there isn't much motivation to load a template with business logic given that you have to create the controller function anyway. Of course, Django templates allow plenty of logic as well -- the logic is simply implemented in a DSL rather than in Python. You can even create custom tags and filters (which of course is the first step to having templates filled with business logic ;-). Most of the logic you see in web2py templates is probably similar to the logic you see in Django templates. The advantage of web2py is that you don't have to learn a DSL, and you don't get stuck when the DSL happens to lack something you need to do. - The editor is only useful if you're making your first steps in > programming. For all other professional programmers it has no value. > Well, I don't see anything wrong with catering to new programmers, but I disagree that the editor has no value to others -- it can be useful for minor edits (especially if you're not at your own machine and need to fix something ASAP) and to do some quick experimenting. It is also integrated with the debugger, enabling you to set breakpoints. Even if it is a third party app, you still have to make sure that changes > to web2py don't break anything. > Since web2py maintains backward compatibility, changes to web2py shouldn't break anything, and we're really not spending any significant time maintaining the editor. In any case, its mere existence does not seem a good reason to avoid or leave the framework. I think it would be much more useful, for instance, to build an orm on top > of the dal. > I recall some effort along those lines a while back, but apparently there wasn't much interest. I think most folks get along fairly well with the DAL, including many former ORM users. That's not to say you shouldn't use or even prefer an ORM -- that's why we have different frameworks, to satisfy different needs and preferences. > Anyway, I come in peace :) > And you are received in peace :-) Anthony
