On Wed, Jul 8, 2009 at 1:47 AM, SergeyPo <[email protected]> wrote:
>
> Yarko,
>
> imagine a web shop. You have Products class (SQL table) and Users
> class (SQL table).
> In RoR you would write a method in Product class:
>
> def price_for_user(user_id=nil)
> if user_id
> user = User.find(user_id)
> return self.list_price * (1 - user.discount)
> else
> return self.list_price
> end
> end
>
> Here user.discount may be either SQL field 'discount' or a method in
> class User which calculated discounts on the fly based on current
> shopping cart amount and user history.
Well, we're not talking about RoR or web2py here --- I'll say this:
decision on discount does not seem to belong to user's responsibility.
Now, shopping cart amount for user, I can see....
User "class" that is if user is group "employee", then policy may allocate a
discount.
But to put this responsibility in "user" encapsulation (e.g. class), while
you can make it work, is structurally likely to be problematic - not what I
would want to do, not "natural" in the real world, so not a good model (in
that it doesn't model after anything real).
But I'm not going to argue or defend structural things too much here; that
is a rich, and big topic.
>
> Than in controller
> for product in basket
> total_order += product.price_for_user(session.user_id)
product.price(session.user_id) # makes more sense;
order.total.discount(...)
> end
>
> Or even in template you can write
> <td>{=product.price_for_user(session.user_id)}</td>
>
> In web2py you would write a function price_for_user(product_id,
> user_id) and get the same result, but the whole code will sit in a
> file in /models directory which will grow quickly as application
> grows.
Mmmm... I don't see why I couldn't (or wouldn't) write a class that holds
the data from the tables...
and in any case, I'm not sure I would write anything that is structured as
you describe it... but that's another story...
anyway, it's late here; I'm tired; interesting discussion; will look more
tomorrow...
>
>
>
> On Jul 8, 10: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
-~----------~----~----~----~------~----~------~--~---
