2006/4/27, Paul Robinson <[EMAIL PROTECTED]>: > 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. :-) >
I bet you once felt as guilty as me and just learned let it go! :) Thanks for conving me on this one, I really needed some support here :) > > 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. ;-) > I will try. > > 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. > Nice to know. I was kind of struggling with DRY DRY DRY all over my head, and honestly I am looking forward being more pragmatic and know better how to balance these concerns. I feel Rails has this kind of culture, DHH once wrote a controversial post about 'reuse is overrated' and I am still getting to grips with thoughts like that. Surely this email will help me, thanks a lot! > 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 > _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
