Hi All, yarko, are you carrying an ID? So if I want to know who you are you show me your ID aren't you?
So @user.is_loggedin is quite valid, but it depends on your implementation and philosophy. The same goes with DAL and ORM. It depends on what you want. I like both, and it depends on the situation what has the preference. For some parts I'm busy building classes to easy some coding througout my app, but I'm glad that I can use DAL to finetune what I want. Hans On Wed, Jul 8, 2009 at 8:27 AM, SergeyPo<[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
