> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
