Good points, Segey - thanks for the thoughtful exchange. What you say about migrations and maintenance really makes sense. I can't think of any reason this would be incompatible w/ automatic migrations.
- Yarko On Wed, Jul 8, 2009 at 1:27 AM, SergeyPo <ser...@zarealye.com> wrote: > > I gave bad example with User.is_logged but obviously having center > place where to put model logic is good thing. In web2py I write > functions (not methods in OOP sense) into db.py to get reusable code > that has to be called from various controllers. In RoR I write methods > to DAL classes that are called Models there. Model consists of > database table, its relations, methods and event handlers (on_create, > on_delete etc etc). This is obviously powerful. But we love web2py for > simplicity. I personally quit RoR world after their version 2.0 which > has become overcomplicated and full of competing concepts (REST > against CRUD controller functions). And of course making it backwards > incompatible was a shame. > > I hope Massimo won't repeat famous "v2.0" mistake, won't > overcomplicate the framework and it stays elegantly simple. But due to > models approach I still recommend RoR for applicatons of ERP/CRM > grade. > > Also RoR is slow :-) > > For migrations, RoR migrations are very efficient when you have > several servers to maintain, and sometimes you can not update all of > them at once - clients may restrict, etc. In this case migrations keep > track of where you actually are, kind of version control for DB. It's > just very usable approach, not generic, not universal, but proven > usable. I like it. And I still do have problems with migrations on > MySQL/Oracle in web2py, however having web2py style migrations is a > benefit for my particular application. > > On Jul 8, 10:04 am, Yarko Tymciurak <yark...@gmail.com> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
