[Nitro] Og Revisted
epiperak at gmail.com
Fri Feb 10 05:49:59 EST 2006
I am not the web devel expert, but let me put just a small piece of
I believe Nitro/Og should stay as is, conceptually for the moment. George
had/has an idea and a lot of reason for this idea. He should be advised for
any large scale changes. Additions should be welcomed
as long as they do not de-RAIL Nitro/Og (hehe... nice) from its original
The major disadvantage (I do not need to mention the tones of advantages,
they are obvious) of having many developers working on the same idea is that
rarely a complete consensus on the idea is reached. In that case a hierarchy
in the decission process always helps. I suggest that we / you / everyone
plan new changes / upgrades for Nitro/Og and even implement them, but let
George decide what should be incorperated.
:-/ Just my opinion...
On 2/10/06, Rob Pitt <rob at motionpath.com> wrote:
> I do not like those ideas at all. I do not agree that by default
> instance variables used in the constructor should be database driven. I
> do not think the automated enchanting of property creates too much of a
> CPU drain, much worse are things like the pre-compiling of scaffold
> templates (what is the point?). I am not a fan of annotations either but
> I recognise I may be alone in this last point.
> If you want to reduce the complexity of the code, it wouldn't be hard to
> do this within the existing syntax as a framework. If you wish to have a
> way of explicitly specifying which classes to enchant (ignoring the
> obvious that property as a keyword is an explicit way of specifying a
> class to be managed), I would suggest something more like:
> class Address
> include Og::Model
> og_property :address_1, String
> og_related :belongs_to, Employee
> On Fri, 2006-02-10 at 02:18 +0000, TRANS wrote:
> > I'd like work on improving Og according to some of the ideas here:
> > http://www.nitrohq.com/view/OgRevisited
> > The first part is to change the way a class gets enchanted
> > ("ogified"). Right now a class in _usually_ enchanted when the
> > #property method is used. There are a few draw backs to this. Firstly,
> > it is inefficent b/c every time the property method is called it has
> > to first check to see if the class is already enchanted or not. Also,
> > it's not 100% consistant because some people have reported cases when
> > a class needs to be enchanted though the #property method hasn't been
> > used. And though it's nice when things seem automatic, in this case
> > being explict about which class are enchanted is a much better thing,
> > making it easier to maintain the code. Also it will greatly reduce
> > some complexity in parts of the Og code and improve run times a bit.
> > So what do others think? Also, what alternatives, modifications, or
> > other suggestions with regard to this (the Setup section on the wiki
> > page) does anyone have?
> > T.
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
> Nitro-general mailing list
> Nitro-general at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nitro-general