Re: injecting Og functionality

Hi,

sorry for not taking part in the orgiginal discussion, just
trying to
wrap it up.  :P

>> > It might be worth talking about whether it
makes sense to fail fast on
>> > missing Og::Model inclusions, and when to do
that.
>>  Yes. I think it pretty trivial to add "is
Model" to a class.
>>
>> In either case, I feel those should be the only two
ways to do it. B/c
>> it is efficient, not overly magical, and serves all
use cases. The
>> attr magic is neat, but I've always felt it
complicates things
>> unnecessarily.
>Ok, give me a day or two to finalize the forum stuff on
np.org (and
> maybe work a bit on georgeandstella.com, remember, I am
getting
> married ) and
then I will make Og work more or less as you suggest

So, the new Og will look like:

class MyModel
   is Og::Model

   attr_accessor :foo, Bar
end

With no other 'enchanting' method allowed?

Jo

-- 
Feel the love
http://pinkjuice.c
om/pics/ruby.png
_______________________________________________
Nitro-general mailing list
Nitro-generalrubyforge.org
h
ttp://rubyforge.org/mailman/listinfo/nitro-general

>
> class MyModel
>    is Og::Model
>
>    attr_accessor :foo, Bar
> end
>

yeap, Og tries to automagically include the Og::Model mixin
where
appropriate. All further 'enchanting' is done by including
more
modules (mixins).

-g.


-- 
http://georgeandstella.com

http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
_______________________________________________
Nitro-general mailing list
Nitro-generalrubyforge.org
h
ttp://rubyforge.org/mailman/listinfo/nitro-general

Hi,

>> With no other 'enchanting' method allowed?

> yeap, Og tries to automagically include the Og::Model
mixin where
> appropriate. All further 'enchanting' is done by
including more
> modules (mixins).

This is kind of contradictory.  :P   My question was, will
the
automagical inclusion and the subclassing enchanting methods
be
removed?

Some time ago I compiled a list on how to enchant an Og
model:

http://oxyliquit.de/tip/33


The rules are pretty much clear (to me) and I see no real
advantage
(other than nitro internal code simplification) to change
the
current behaviour.

Jo

-- 
Feel the love
http://pinkjuice.c
om/pics/ruby.png
_______________________________________________
Nitro-general mailing list
Nitro-generalrubyforge.org
h
ttp://rubyforge.org/mailman/listinfo/nitro-general