On 27 Apr 2006, at 23:57, Eduardo R. 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 R.
