Rails core - Apr 2008 - Active Model - work in progress, questions and thoughts

Hello, World!

I''ve been doing some hacking on ActiveModel, and I''m pretty
satisfied
with the results. Mmost of the validations stuff is finished.
Callbacks and observing is yet to come (though Rick Olson has done
some work on the observers).

Here''s one of the tests, which mocks an active record implementation
of AtiveModel: http://pastie.org/185638

It lets you overwrite default validation settings. It detects if the
implementation defines new_record?, if it does, ActiveModel activates
new/existing record differences. If it doesn''t, stuff like :on
=> :update is ignored.

The API is pretty clean, and yes, the tests pass ; ) I''m poking around
with error messages now, trying out various approaches. I think the
basic idea of Errors < Hash is DHH''s, and I really based my stuff on
his approach, just tweaking it a bit. For instance, instead of
user.errors[:base] << "foo", I''ve done user.errors
<< "Foo" (which was
to be honest Pratik''s idea). Also, instead of user.errors[:base] for
yielding them, I''m doing user.errors.on_base. It''s a very
different
kind of error than the attribute-based errors you add with
foo.erros[:bar], so I think it makes sense to have the api different
for those as well.

Certain things makes backwards compability hard, though. I''ve changed
it so that adding errors on base causes the record to be invalid,
which as far as I know breaks backwards compability (this is the first
time I hack around whith in-deep rails stuff like this, so do arrest
me on this if I''m wrong). Therefore, aiming for ActiveModel being a
none backwards compatible 3.0 thing would make sense. As mentioned, it
would really easen the process of coding it, and makes it less hacky.
And it really affects active record as well, involving a lot of re-
writing, so the 3.0 badge would indeed be deserved for a release like
this.

So, that''s it. My work so far is available on github,
http://github.com/leethal/rails/tree/activemodel_cleanup/activemodel.
I hope you like what I''ve done so far, I''ve really enjoyed
hacking on
this. Comments appreciated =)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

I think you''re getting a little ahead of yourself. We still
haven''t
made any real decisions about the direction of ActiveModel. Its pretty
experimental at this point.

Please feel free to continue to play around but don''t assume we are
going be taking your direction.

Also, I think we are going go w/ rspec too.

On Apr 23, 2:12 pm, August Lilleaas <augustlille...@gmail.com>
wrote:
> Hello, World!
>
> I''ve been doing some hacking on ActiveModel, and I''m
pretty satisfied
> with the results. Mmost of the validations stuff is finished.
> Callbacks and observing is yet to come (though Rick Olson has done
> some work on the observers).
>
> Here''s one of the tests, which mocks an active record
implementation
> of AtiveModel:http://pastie.org/185638
>
> It lets you overwrite default validation settings. It detects if the
> implementation defines new_record?, if it does, ActiveModel activates
> new/existing record differences. If it doesn''t, stuff like :on
> => :update is ignored.
>
> The API is pretty clean, and yes, the tests pass ; ) I''m poking
around
> with error messages now, trying out various approaches. I think the
> basic idea of Errors < Hash is DHH''s, and I really based my
stuff on
> his approach, just tweaking it a bit. For instance, instead of
> user.errors[:base] << "foo", I''ve done user.errors
<< "Foo" (which was
> to be honest Pratik''s idea). Also, instead of user.errors[:base]
for
> yielding them, I''m doing user.errors.on_base. It''s a very
different
> kind of error than the attribute-based errors you add with
> foo.erros[:bar], so I think it makes sense to have the api different
> for those as well.
>
> Certain things makes backwards compability hard, though. I''ve
changed
> it so that adding errors on base causes the record to be invalid,
> which as far as I know breaks backwards compability (this is the first
> time I hack around whith in-deep rails stuff like this, so do arrest
> me on this if I''m wrong). Therefore, aiming for ActiveModel being
a
> none backwards compatible 3.0 thing would make sense. As mentioned, it
> would really easen the process of coding it, and makes it less hacky.
> And it really affects active record as well, involving a lot of re-
> writing, so the 3.0 badge would indeed be deserved for a release like
> this.
>
> So, that''s it. My work so far is available on
github,http://github.com/leethal/rails/tree/activemodel_cleanup/activemodel.
> I hope you like what I''ve done so far, I''ve really
enjoyed hacking on
> this. Comments appreciated =)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

I didn''t really see where he was getting ahead of himself. 
He''s done
a lot of hacking on this and he was saying that if you take his
patches/changes then backwards compatibility could be hard.  If you
don''t, well, who cares?  That''s the beauty of Git: he can
maintain his
own repos of the code, you can maintain yours.

Also, I think perhaps you''re getting ahead of yourself, since I
don''t
see your name on http://rubyonrails.org/core (at least not yet :)).
I''d like to get Rick Olson''s take on it (and I think Rick
Bradley has
been involved), since I know he has taken a look at this stuff
previous to this ML message.

As for myself, I think this stuff is really cool.  I had someone ask
me about something like this (or, well, a little more than
this...closer to DataMapper I guess) at MySQLConf, so it''s cool to see
something materializing.  I''m going to start toying around with this
and ActiveRelation once it''s substantial enough to tinker with. 
I''m
really excited to see where the model layer in Rails is going...

--Jeremy

On Thu, Apr 24, 2008 at 1:24 AM, Josh Peek <joshpeek@gmail.com>
wrote:
>
>  I think you''re getting a little ahead of yourself. We still
haven''t
>  made any real decisions about the direction of ActiveModel. Its pretty
>  experimental at this point.
>
>  Please feel free to continue to play around but don''t assume we
are
>  going be taking your direction.
>
>  Also, I think we are going go w/ rspec too.
>
>
>
>  On Apr 23, 2:12 pm, August Lilleaas <augustlille...@gmail.com>
wrote:
>  > Hello, World!
>  >
>  > I''ve been doing some hacking on ActiveModel, and
I''m pretty satisfied
>  > with the results. Mmost of the validations stuff is finished.
>  > Callbacks and observing is yet to come (though Rick Olson has done
>  > some work on the observers).
>  >
>  > Here''s one of the tests, which mocks an active record
implementation
>  > of AtiveModel:http://pastie.org/185638
>  >
>  > It lets you overwrite default validation settings. It detects if the
>  > implementation defines new_record?, if it does, ActiveModel activates
>  > new/existing record differences. If it doesn''t, stuff like
:on
>  > => :update is ignored.
>  >
>  > The API is pretty clean, and yes, the tests pass ; ) I''m
poking around
>  > with error messages now, trying out various approaches. I think the
>  > basic idea of Errors < Hash is DHH''s, and I really based
my stuff on
>  > his approach, just tweaking it a bit. For instance, instead of
>  > user.errors[:base] << "foo", I''ve done
user.errors << "Foo" (which was
>  > to be honest Pratik''s idea). Also, instead of
user.errors[:base] for
>  > yielding them, I''m doing user.errors.on_base. It''s
a very different
>  > kind of error than the attribute-based errors you add with
>  > foo.erros[:bar], so I think it makes sense to have the api different
>  > for those as well.
>  >
>  > Certain things makes backwards compability hard, though.
I''ve changed
>  > it so that adding errors on base causes the record to be invalid,
>  > which as far as I know breaks backwards compability (this is the
first
>  > time I hack around whith in-deep rails stuff like this, so do arrest
>  > me on this if I''m wrong). Therefore, aiming for ActiveModel
being a
>  > none backwards compatible 3.0 thing would make sense. As mentioned,
it
>  > would really easen the process of coding it, and makes it less hacky.
>  > And it really affects active record as well, involving a lot of re-
>  > writing, so the 3.0 badge would indeed be deserved for a release like
>  > this.
>  >
>  > So, that''s it. My work so far is available on
github,http://github.com/leethal/rails/tree/activemodel_cleanup/activemodel.
>  > I hope you like what I''ve done so far, I''ve really
enjoyed hacking on
>  > this. Comments appreciated =)
>  >
>


-- 
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

>  I didn''t really see where he was getting ahead of himself. 
He''s done
>  a lot of hacking on this and he was saying that if you take his
>  patches/changes then backwards compatibility could be hard.  If you
>  don''t, well, who cares?  That''s the beauty of Git: he
can maintain his
>  own repos of the code, you can maintain yours.
This is, indeed, the beauty of distributed source control, and
experimentation with ActiveModel should be encouraged.  However it''s
missed the 2.1 boat, so lets not get too worried about what is and
isn''t yet fit for the core of the framework.  We have until (2.1).next
to worry about such things.
>  Also, I think perhaps you''re getting ahead of yourself, since I
don''t
>  see your name on http://rubyonrails.org/core (at least not yet :)).
>  I''d like to get Rick Olson''s take on it (and I think
Rick Bradley has
>  been involved), since I know he has taken a look at this stuff
>  previous to this ML message.
I know rick''s been tinkering with ActiveModel in the past, but
I''m not
sure how ''in anger'' the use has been.  Though you''re
probably in a
better position to know whether or not the entp projects are doing
anything like this.
>  As for myself, I think this stuff is really cool.  I had someone ask
>  me about something like this (or, well, a little more than
>  this...closer to DataMapper I guess) at MySQLConf, so it''s cool
to see
>  something materializing.  I''m going to start toying around with
this
>  and ActiveRelation once it''s substantial enough to tinker with. 
I''m
>  really excited to see where the model layer in Rails is going...
I''m also looking forward to giving active record a bit of a kicking,
bi-directional associations and an identity map for starters, but I
see ActiveModel as something else entirely.  I''m having trouble seeing
it materialise into something useful until we have an alternative
method of persistence to target.  ActiveResource got by fine without
it,  perhaps we need active document, active flat-file, active
in-memory-thing or something similar to get a feel for what''s needed.

>  On Thu, Apr 24, 2008 at 1:24 AM, Josh Peek <joshpeek@gmail.com>
wrote:
>  >
>  >  I think you''re getting a little ahead of yourself. We still
haven''t
>  >  made any real decisions about the direction of ActiveModel. Its
pretty
>  >  experimental at this point.
>  >
>  >  Please feel free to continue to play around but don''t
assume we are
>  >  going be taking your direction.
>  >
>  >  Also, I think we are going go w/ rspec too.
>  >
>  >
>  >
>  >  On Apr 23, 2:12 pm, August Lilleaas <augustlille...@gmail.com>
wrote:
>  >  > Hello, World!
>  >  >
>  >  > I''ve been doing some hacking on ActiveModel, and
I''m pretty satisfied
>  >  > with the results. Mmost of the validations stuff is finished.
>  >  > Callbacks and observing is yet to come (though Rick Olson has
done
>  >  > some work on the observers).
>  >  >
>  >  > Here''s one of the tests, which mocks an active record
implementation
>  >  > of AtiveModel:http://pastie.org/185638
>  >  >
>  >  > It lets you overwrite default validation settings. It detects
if the
>  >  > implementation defines new_record?, if it does, ActiveModel
activates
>  >  > new/existing record differences. If it doesn''t, stuff
like :on
>  >  > => :update is ignored.
>  >  >
>  >  > The API is pretty clean, and yes, the tests pass ; )
I''m poking around
>  >  > with error messages now, trying out various approaches. I think
the
>  >  > basic idea of Errors < Hash is DHH''s, and I really
based my stuff on
>  >  > his approach, just tweaking it a bit. For instance, instead of
>  >  > user.errors[:base] << "foo", I''ve done
user.errors << "Foo" (which was
>  >  > to be honest Pratik''s idea). Also, instead of
user.errors[:base] for
>  >  > yielding them, I''m doing user.errors.on_base.
It''s a very different
>  >  > kind of error than the attribute-based errors you add with
>  >  > foo.erros[:bar], so I think it makes sense to have the api
different
>  >  > for those as well.
>  >  >
>  >  > Certain things makes backwards compability hard, though.
I''ve changed
>  >  > it so that adding errors on base causes the record to be
invalid,
>  >  > which as far as I know breaks backwards compability (this is
the first
>  >  > time I hack around whith in-deep rails stuff like this, so do
arrest
>  >  > me on this if I''m wrong). Therefore, aiming for
ActiveModel being a
>  >  > none backwards compatible 3.0 thing would make sense. As
mentioned, it
>  >  > would really easen the process of coding it, and makes it less
hacky.
>  >  > And it really affects active record as well, involving a lot of
re-
>  >  > writing, so the 3.0 badge would indeed be deserved for a
release like
>  >  > this.
>  >  >
>  >  > So, that''s it. My work so far is available on
github,http://github.com/leethal/rails/tree/activemodel_cleanup/activemodel.
>  >  > I hope you like what I''ve done so far, I''ve
really enjoyed hacking on
>  >  > this. Comments appreciated =)
>  >  >
>  >
>
>
>
>  --
>  http://jeremymcanally.com/
>  http://entp.com
>
>  Read my books:
>  Ruby in Practice (http://manning.com/mcanally/)
>  My free Ruby e-book (http://humblelittlerubybook.com/)
>
>  Or, my blogs:
>  http://mrneighborly.com
>  http://rubyinpractice.com
>
>
>
>  >
>


-- 
Cheers

Koz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey peeps,

Glad you find my stuff at least semi-sensible =)

The reason I''m hacking on it, is beacuse after asking about
it''s
status in #rails-contrib Rick Olson suggested that I''d start hacking
away on it. It was he hat suggested posting this mailing list as
well.

The way I see it, ActiveModel is about tearing apart various libs
inside ActiveRecord and making them stand-alone, so that 1. the active
record code itself gets a lot cleaner, and that 2. people can include
ActiveModel libs in their own code, without having to use active
record. E.g. databaseless models in a rails app that has validations
and callbacks in them.

Rick Olson has been saying all along that this wouldn''t get into 2.1,
so that has never been my goal anyway. DHH also said he was okay with
making Active Model a 3.0 thing (in #rails-contrib), so I guess that
makes sense then.

But really, I''ve just been playing with this, and I''m not a
super
experienced Ruby coder (which you can tell from the
read_inheritable_attribute stuff in the validation settings part of my
hacks =P), so I''m not having any high hopes of the core team embracing
my ideas and hacks from day one.

On Apr 24, 10:09 am, "Michael Koziarski" <mich...@koziarski.com>
wrote:
> >  I didn''t really see where he was getting ahead of himself.
 He''s done
> >  a lot of hacking on this and he was saying that if you take his
> >  patches/changes then backwards compatibility could be hard.  If you
> >  don''t, well, who cares?  That''s the beauty of Git:
he can maintain his
> >  own repos of the code, you can maintain yours.
>
> This is, indeed, the beauty of distributed source control, and
> experimentation with ActiveModel should be encouraged.  However
it''s
> missed the 2.1 boat, so lets not get too worried about what is and
> isn''t yet fit for the core of the framework.  We have until
(2.1).next
> to worry about such things.
>
> >  Also, I think perhaps you''re getting ahead of yourself,
since I don''t
> >  see your name onhttp://rubyonrails.org/core(at least not yet :)).
> >  I''d like to get Rick Olson''s take on it (and I
think Rick Bradley has
> >  been involved), since I know he has taken a look at this stuff
> >  previous to this ML message.
>
> I know rick''s been tinkering with ActiveModel in the past, but
I''m not
> sure how ''in anger'' the use has been.  Though
you''re probably in a
> better position to know whether or not the entp projects are doing
> anything like this.
>
> >  As for myself, I think this stuff is really cool.  I had someone ask
> >  me about something like this (or, well, a little more than
> >  this...closer to DataMapper I guess) at MySQLConf, so it''s
cool to see
> >  something materializing.  I''m going to start toying around
with this
> >  and ActiveRelation once it''s substantial enough to tinker
with.  I''m
> >  really excited to see where the model layer in Rails is going...
>
> I''m also looking forward to giving active record a bit of a
kicking,
> bi-directional associations and an identity map for starters, but I
> see ActiveModel as something else entirely.  I''m having trouble
seeing
> it materialise into something useful until we have an alternative
> method of persistence to target.  ActiveResource got by fine without
> it,  perhaps we need active document, active flat-file, active
> in-memory-thing or something similar to get a feel for what''s
needed.
>
>
>
> >  On Thu, Apr 24, 2008 at 1:24 AM, Josh Peek <joshp...@gmail.com>
wrote:
>
> >  >  I think you''re getting a little ahead of yourself. We
still haven''t
> >  >  made any real decisions about the direction of ActiveModel. Its
pretty
> >  >  experimental at this point.
>
> >  >  Please feel free to continue to play around but don''t
assume we are
> >  >  going be taking your direction.
>
> >  >  Also, I think we are going go w/ rspec too.
>
> >  >  On Apr 23, 2:12 pm, August Lilleaas
<augustlille...@gmail.com> wrote:
> >  >  > Hello, World!
>
> >  >  > I''ve been doing some hacking on ActiveModel, and
I''m pretty satisfied
> >  >  > with the results. Mmost of the validations stuff is
finished.
> >  >  > Callbacks and observing is yet to come (though Rick Olson
has done
> >  >  > some work on the observers).
>
> >  >  > Here''s one of the tests, which mocks an active
record implementation
> >  >  > of AtiveModel:http://pastie.org/185638
>
> >  >  > It lets you overwrite default validation settings. It
detects if the
> >  >  > implementation defines new_record?, if it does,
ActiveModel activates
> >  >  > new/existing record differences. If it doesn''t,
stuff like :on
> >  >  > => :update is ignored.
>
> >  >  > The API is pretty clean, and yes, the tests pass ; )
I''m poking around
> >  >  > with error messages now, trying out various approaches. I
think the
> >  >  > basic idea of Errors < Hash is DHH''s, and I
really based my stuff on
> >  >  > his approach, just tweaking it a bit. For instance,
instead of
> >  >  > user.errors[:base] << "foo", I''ve
done user.errors << "Foo" (which was
> >  >  > to be honest Pratik''s idea). Also, instead of
user.errors[:base] for
> >  >  > yielding them, I''m doing user.errors.on_base.
It''s a very different
> >  >  > kind of error than the attribute-based errors you add with
> >  >  > foo.erros[:bar], so I think it makes sense to have the api
different
> >  >  > for those as well.
>
> >  >  > Certain things makes backwards compability hard, though.
I''ve changed
> >  >  > it so that adding errors on base causes the record to be
invalid,
> >  >  > which as far as I know breaks backwards compability (this
is the first
> >  >  > time I hack around whith in-deep rails stuff like this, so
do arrest
> >  >  > me on this if I''m wrong). Therefore, aiming for
ActiveModel being a
> >  >  > none backwards compatible 3.0 thing would make sense. As
mentioned, it
> >  >  > would really easen the process of coding it, and makes it
less hacky.
> >  >  > And it really affects active record as well, involving a
lot of re-
> >  >  > writing, so the 3.0 badge would indeed be deserved for a
release like
> >  >  > this.
>
> >  >  > So, that''s it. My work so far is available on
github,http://github.com/leethal/rails/tree/activemodel_cleanup/activemodel.
> >  >  > I hope you like what I''ve done so far,
I''ve really enjoyed hacking on
> >  >  > this. Comments appreciated =)
>
> >  --
> >  http://jeremymcanally.com/
> >  http://entp.com
>
> >  Read my books:
> >  Ruby in Practice (http://manning.com/mcanally/)
> >  My free Ruby e-book (http://humblelittlerubybook.com/)
>
> >  Or, my blogs:
> >  http://mrneighborly.com
> >  http://rubyinpractice.com
>
> --
> Cheers
>
> Koz
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---