Sergey, Massimo - Both of you are talking about what is more than "merely syntax", but responsibility.
Stepping away from software for a minute, ask yourself: Does a user ask if he is admin? (user.is_admin) Or is it more naturally appropriate that this responsibility lies with some authority, e.g.: auth.belongs_to( group(admin), user) # not real code - intentionally trying to make the ownership / responsibility explicit Regardless of classes, to me user.is_admin seems upside-down. If my system allows a user class (or it's extension) to write security checks, this looks like a problem. If - however - I update or extend an authorization class, those behaviors (and their resopnsibilities in the system) are more explicit, and seem more appropriate. Of course, there are times when things "seem" upside down, but in some situation this is the "right" or "better" way. My point: the "shape" of the way Massimo has done this is preferable at many levels to what you described as the rails way. Imagine reading something like this: @user.is_logged_in def my secure function A user (class) validating access to sensitive information.... ugh! As for the ORM argument: ORM - object-relational-mapping is just that - if you build object oriented systems, and those objects depend on persistence, and all of your solution is encapsulated in the objects, then anything about relational systems or SQL is deemed to be an abstraction, and should be automated away. ORMs can be implemented and used well. Just not (usualy) for web applications, and particularly not where - if you were really to get strict about object encapsulation - with legacy or shared / sharable data, you would need to make an "object" to encapsulate the relational model. If the relational model is often a "first class citizen", the overhead of a "relational class" makes no sense (you could still use an ORM for the business-rules objects of a solution, so I could accept an argument that a mixed ORM/DAL system ... might make sense). But, really, Massimo has chosen to leave relational persistence as a first-class citizen, so DAL makes sense (we may see if shoe-horning column-centric data, e.g. big-tables, et.al. makes long term sense, or if a new abstraction for that as first-class citizen makes more long term sense). As for logging.record vs. record.log, the question of this balance is again one of appropriate an natural responsibilities: Is logging a primary object? Do records need to provide record-specific methods for logging? These are more maleable questions in my mind. But I think DAL is a choice with good foundation, and the auth class also feels correctly rooted, w.r.t. responsibilities, and maintainability of security aspects. My two cents worth. - Yarko On Wed, Jul 8, 2009 at 12:25 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > 1. I agree that RoR migrations are more powerful but web2py can update > the data too. Can you provide an example of something you can do in > RoR migrations that you believe cannot be done in web2py? > > 2. That is a major philosophical difference. Most people including me > believe that a proper mapping between database tables and object in a > programming language is not possible. Any attempt to do it necessarily > imposes limitations on what you do or forces you to introduce an > unnatural syntax. That is way they have an ORM and we have a DAL. In > practice this is syntactical difference more than a functional one. > They say > > record.is_logged() > > we say > > is_logged(record) > > The rails syntax can easily be implemented on top of web2py and I do > not completely exclude it will be supported in the new DAL (without > going to a full ORM). > > Massimo > > On Jul 8, 12:03 am, SergeyPo <ser...@zarealye.com> wrote: > > I like web2py and prefer it over RoR but two things I am missing: > > 1. migrations (RoR migrations are really more powerful, you write the > > script that not only changes database scheme but also can update data, > > you have full control etc.) > > 2. models (web2py model layer is purely database layer which you use > > by ORM, in RoR models are classes that run on top of ORM and let you > > program custom methods; e.g. for class 'Users' you can develop methods > > 'is_logged', 'is_admin', 'dont_destroy_admin' etc etc.) > > > > Many-to-many relations that are supported by many frameworks are > > actually a drawback and Rails have already changed original concept to > > 'belongs ... through' which is actually a manual table definition for > > many-to-many relations; so in web2py you just define a table with all > > necessary fields for your particular situation. > > > > And the biggest advantage of web2py is Python language. It's by far > > more mature than Ruby and have so many libraries available that you > > hardly have to develop any system level task, you just script the > > behavior you need in terms of domain area of your application. I mean, > > if you want to use statistics you use scipy, you need pdf - reportlab, > > networking - no problem, AI - no problem. Web2py makes it easy to > > install libraries and distribute/deploy with your apps. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
