On 27 Apr 2006, at 23:57, Eduardo Rocha wrote: > I think the best protection is a new test
But imagine this: you write your code, use svn:externals to grab the engines, you distribute it, somebody does a svn update, doesn't bother running the tests but something has changed and.... Yeah, trust me, you don't want to do that. If you need to change the behaviour of a method just copy the whole method and adapt it. What would be interesting is if there was a way of creating a new class that inherits from, say, User, then doing #super without it throwing out the redirect or any renders, before running your own code. That could get awkward though. I'm not even sure how you would go about doing 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? 'Avoid Code Duplication' is a guide to writing efficient code, not a fascist mantra that should be observed when there is a good reason to duplicate. :-) Remember, you're not duplicating yourself - you're replacing somebody else's code with a more suitable version, and you're only copying the bits you absolutely have to in order to remain syntactically correct within the language you're working with. No, I know of no way to over-ride just the redirect_to. I promise you, that whilst I truly admire your technique and resistance to doing things the wrong way, in my opinion you are doing NOTHING wrong by copying just the methods you want to change and adapting them, and you are doing it the CORRECT and AGILE and RAILS way. You are not duplicating yourself. You are changing somebody else's code. You are doing the right thing. Stop feeling guilty! :-) If you want to change the way this works in the future, think about how you could adapt the engines so that it would be easier to do what it is you want. There are various ways I can think of, but whilst you're over-riding existing code, this is The Correct Way. :-) > 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. Well, you don't need my agreement - I'm just this guy on a mailing list who uses user_engine and login_engine a lot. :-) I think you're right though. You know what would be better than just opening a ticket? Try coding it yourself - it's a pretty easy fix - and then submit a patch. You'll feel all important if you do, I promise. ;-) > 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. Yeah, you're probably right, that needs another think about it. I've recently had to take on a project where the role a user is actually assigned depending on both the user and the project - i.e. a user has one role for one project, another role for another project. I did find a work-around eventually, and I'll try and create a new engine based on it, but what was annoying was that I basically had to copy the entirety of vendor/plugins/user_engine/lib/* to my own /lib and tweak it just to add half a dozen well-chosen lines. That said, at least the code was pre-written for me and I didn't have to start from scratch. :-) -- Paul Robinson _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
