2006/4/27, Paul Robinson <[EMAIL PROTECTED]>: > On 27 Apr 2006, at 12:41, Eduardo Rocha wrote: > > > redirect (DoubleRenderError), the only way I see is to copy n' paste > > the method and change the redirect line. Is there anything else I can > > do to avoid copy n' paste? > > Copy and paste is the way you should do it. If you're changing the > behaviour of what happens at the end of the method, don't you want to > make sure that unexpected things don't get checked into /vendor/ > plugins and start messing your code up? > > Copying and pasting is not only the only way to do it to my > knowledge, but it's the most sensible way to do it, IMHO. You either > want the default engine behaviour, or you want your behaviour, but > you don't want an unpredictable and volatile mix of the two that > could change in nature every time somebody checks a patch in to the > engines' repository.
I think the best protection is a new test, exercising the change I made. Doing that, I could update the login_engine and if new code breaks what I've written, my test would tell me. At the same way, if login_engine improves some functionality, I would not get it 'automagically'. My main aim was to avoid code duplication, code that maybe was not necessary. By the way, do you know a trick to just override the redirect_to? > > > My other doubt is about the model. If I do not use email notification > > and do not use a email field, the second user signup is made > > impossible, since it complains that 'Email has already been taken'. > > That is, the model validates the uniqueness of Email, even if email > > notification is disabled. Is that a bug, right? > > Hmmm, not really. The model says that emails need to be present and > unique. If you are changing the nature of the model so that they > don't need to be present and unique (by not capturing one at all in > your view), you need to change the model. > > Are you saying that you've removed the need for the presence of the > email but the uniqueness check is in there tripping up over multiple > null values? I can see how that might be considered a bug, but if you > think about it, it's behaving exactly how it is documented as an > ActiveRecord method. > It seems to be an inconsistent feature of login_engine, ActiveRecord just plays right: I can disable mail verification (config :use_email_notification, false) so that's no need for email at all, but the email still needs to me unique. Here a simple ":if" clause in validates_uniqueness would do the trick and if you agree I can open a ticket. > > Even being a bug, it would be nice to be able to override the model, I > > mean, there could be a way of not using some of the default > > validators. > > You can over-ride the model, it's just not as easy as over-riding a > method. It is documented though. However, it gets a bit more > complicated with user_engine because there is a shedload of code in > lib that needs copying over and then tweaking. > Exactly. Since including AuthenticatedUser gives me all that validations right away, there is no easy way of override them. Engines is all about code reuse with easy configuration/customization, and what I am claiming here is an easier way of doing that in login_engine. > -- > Paul Robinson Paul, thanks for your fast reply and sorry for me being late :( _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
