[finally reviewing some older messages]
[moved from dabo-users]
On 1/16/11 6:27 AM, Ed Leafe wrote:
> Hmmm... I'm glad you pointed this out. I answered the previous question
> without really looking at the code, but in most cases, you are correct:
> returning any boolean True value will prevent the save() from occurring.
> Looking at the code, though, shows that there are a lot of irregularities.
> For example, the wiki states:
>
> beforeInit() - fires before the __init__() code executes. Returning False
> from this method will prevent the object from instantiating. It also gives
> you a chance to declare any object attributes that subsequent code may rely
> upon.
>
> However, the return value of beforeInit() is discarded, so that either
> the code or the docs are wrong. I much prefer that we standardize this
> behavior; that was part of the original design of these hook methods. I'll
> look into updating these so that they are consistent throughout the framework.
We should standardize this framework-wide.
Checking for a returned message from before*() and interpreting that as a
failure is
a nifty way to handle things, but its disadvantage is that it is the boolean
opposite
of what one would expect:
if beforeAction():
afterAction()
would be wrong, it would have to be:
if not beforeAction():
afterAction()
because a return value (the message) indicates failure.
I suppose we really need to leave it this way because the most commonly-used
beforeHooks use this convention, and we don't want to break people's code.
Plus, I
think it is the most sensible approach. [1]
So we need to change, for example, beforeInit() to return boolean False (None,
'',
etc.) if it is supposed to succeed, and boolean True ("This is why we can't
start the
form", True, etc.) if it is supposed to fail. And we need to fix it to actually
fail
in those cases if it doesn't already.
Lots of work, but consistency in hook method behavior seems important to me,
too.
Any volunteers?
Paul
[1] Exceptions would require much more user code. Multiple return values like
(False,
"Here's why") would also require much more user code, and there's not really a
use-case for a message in the True case.
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/[email protected]
