On Wed, Jul 8, 2009 at 1:55 AM, Yarko Tymciurak <yark...@gmail.com> wrote:
> On Wed, Jul 8, 2009 at 1:45 AM, Hans Donner <hans.don...@pobox.com> wrote: > >> >> 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? > > > I present those to log in; I don't use those to say "I decide I am > authorized!" > Actually, if I'm KGB or CIA, and carry a weapon, I suppose I would say "I decide I am authorized...", I just don't think that's the model appropriate for web authentication ;-) > > > >> >> >> So @user.is_loggedin is quite valid, but it depends on your >> implementation and philosophy. > > > distributes (or is part of), decentralizes an important domain concept / > responsibility; my guy says "bad idea" > >> >> >> 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<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 -~----------~----~----~----~------~----~------~--~---
