Best Practices in Rev development

[Devin Asay]

Hi Mark,

On Jun 21, 2007, at 8:20 AM, Mark Wieder wrote:

> Devin-
>
> Wednesday, June 20, 2007, 5:04:05 PM, you wrote:
>
>> I tend to agree on this one. My rule-of-thumb is "2-3"; in other
>> words, if I need to execute the same code 2 or more times and that
>> code is more than about 3 lines, I'll break the code out into another
>> handler.
>
> ...that's pretty much my rule-of-thumb as well, but that's a separate
> topic (albeit a good one for discussion).
>
> My point was more about decoupling the bulk of the actual code from
> the on-screen object event handlers: mouseUp, returnInField, etc. I
> don't always do this, but if the handler grows to more than a couple
> of lines I'll usually break it out.

I think I understand where you were coming from--it may be best to  
leave the standard event handlers looking clean and easy to follow by  
breaking out logically discrete blocks of code into handlers with  
functionally descriptive names. I think I have a learned resistance  
to this technique from my HyperCard days. Back then we were always  
looking for speed tweaks, and somebody once ran some benchmarks that  
determined that you took an ever-so-slight speed hit when calling  
another handler as opposed to keeping all statements inline in the  
existing handler. Add to that the absence of script-local variables  
in HC--thus, the need to pass all data to the other handler as params  
or declare bunches of global vars--and you have a behavioral aversion  
to the technique. Which is not to say it's not a good practice. In  
fact, I've used this approach when teaching students about custom  
handlers.

Of course now, as of Rev 2.8.x, I can teach them that 'on <event>'  
and 'command' handlers are two different things: use 'on' to trap  
standard event messages and 'command' to write your own handlers. I'm  
still pondering whether this distinction would gain me anything when  
I'm teaching new Rev programmers. Do I gain anything by emphasizing  
the somewhat artificial distinction between messages and commands?

Regards,

Devin

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University