I thought I'd let everyone know that devise-1.1 will be released very soon (like 1-2 weeks from now) and Jose Valim explicitly called out to different ORM users to provide patches to make devise compatible with everyone's ORM of choice. Surely we want DM to be compatible with devise since it's a very popular authentication solution for rails (built on warden and thus rack) that many people trying to make the switch from AR to DM on rails3 will want to keep on using.
I've started a fork [1] that tries to get things to work within the tight time "constraints" we have. Unfortunately I won't be able to spend very much time on it myself, so I'd appreciate any kind of help I can get. I've started by getting things to the point where the testsuite at least runs, unfortunately, lots of tests still fail.
It'd be really cool if we could say that we're compatible with rails3 and devise by the time devise-1.1 comes out. Who knows, maybe devise's release is just in time for another rails3 beta or RC.
Your help is very much appreciated! If someone steps up I'd be happy to discuss action plans either here, or in #datamapper on irc.freenode.net. Providing patches to my fork will be easy, since serious motivation means instant commit access :P
I've done a bit of work today on getting DM to pass tests on devise
[1]. The majority of the remaining failing tests fall into the
following two categories:
1. DateTime properties in DM verses Time attributes in AR.
Specifically, tests raise an error when trying to call #gmtime on a
DateTime object (as opposed to Time); at least one test also checks
that the attribute is_kind_of? Time.
2. Translations of validation messages. When devise adds errors to a
resource, it gives the message argument as a symbol. In AR (actually,
I think it's in ActiveModel), a symbol cues it to perform a
translation, whereas DM keeps the symbol as is. The devise tests check
against the expected translated string, so DM fails these tests. I'm
inclined to think the best approach here would be to have devise
handle all translations directly instead of relying on the ORM--I'll
probably open a ticket on devise to discuss that possibility, but
wondered if anyone has thoughts on if there's a reasonable way to have
DM translate the validation errors (Maybe using
DM::V::ValidationErrors.default_error_messages= ?).
If anyone has thoughts on the best ways to address these two issues,
I'd appreciate it.
> I thought I'd let everyone know that devise-1.1 will be released very
> soon (like 1-2 weeks from now) and Jose Valim explicitly called out to
> different ORM users to provide patches to make devise compatible with
> everyone's ORM of choice. Surely we want DM to be compatible with
> devise since it's a very popular authentication solution for rails
> (built on warden and thus rack) that many people trying to make the
> switch from AR to DM on rails3 will want to keep on using.
An update for anyone interested in using devise with DM: my dm-
compatibility branch [1] is working and passing all tests. However, to
generate expected validation errors, I monkey-patch dm-validations'
ValidationErrors [2] and I feel it's rather brittle, so I will be
working to improve this (any recommendations are very welcome) before
it's brought into the official repository.
Sorry I don't have much time myself to contribute a lot, your efforts are *very* much appreciated! What about hopping into #datamapper on irc.freenode.net so that we can discuss i18n validation errors a bit? To briefly skim the topic, "hacks" are fine for now, we probably want to initially come up with some dm-devise helper gem (the place to put the hacks) that does the dirty work for being compatible with devise's i18n validation message needs. Just to have something devise can depend on initially. Eventually, we will of course need to come up for "full" i18n support for dm-validations, but we probably won't be able to come up with that within the present time constraints.
On Mon, Jun 28, 2010 at 22:49, Jared Morgan <jmor...@morgancreative.net> wrote: > An update for anyone interested in using devise with DM: my dm- > compatibility branch [1] is working and passing all tests. However, to > generate expected validation errors, I monkey-patch dm-validations' > ValidationErrors [2] and I feel it's rather brittle, so I will be > working to improve this (any recommendations are very welcome) before > it's brought into the official repository.
> -- > You received this message because you are subscribed to the Google Groups "DataMapper" group. > To post to this group, send email to datamapper@googlegroups.com. > To unsubscribe from this group, send email to datamapper+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
Martin,
Sorry to not reply earlier, I haven't done much on dm/devise this
week. I'm not having any errors with the i18n stuff, I was just
concerned about how hackish is was. Jose Valim just asked that we
create a dm-devise gem similar to what you suggested (I think his
thought is a bit different than what you may have had in mind, but
same benefit of isolating the hacks -- see
http://github.com/plataformatec/devise/issues#issue/143). I'm going to
start a dm-devise gem today; hopefully it shouldn't take much work
now.
For anyone interested in using devise with datamapper, I have a
project up at http://github.com/jm81/dm-devise . It is fully
functional (works with Rails 3 and Devise masters only), so everything
you can do with Devise in Active Record should work the same in
DataMapper. There's an option for using either dm-validations or
ActiveModel validations, depending on your preference (ActiveModel
includes I18n support, so I thought I'd give it a try and after some
help from José Valim, it works). More info and installation
instructions are in the README. If you try it out, I'd appreciate any
feedback.
As an aside, if you're interested, I got I18n working with dm-
validations at http://github.com/jm81/devise/blob/dm-compatibility/lib/devise/orm/da... (bottom of the file), but for ease of maintenance in the dm-devise
gem, I decided just to set default_error_messages to the message
formats expected by devise, at least for now.
