AW: where to put handlers?

[Devin Asay]

On Feb 6, 2008, at 10:24 AM, Richard Gaskin wrote:

> Devin Asay wrote:
>> I have two objections to placing all handlers high in the message   
>> hierarchy.
>> 1. It destroys the modularity/object-oriented-ish-ness of  
>> Revolution  stacks. If I create a particularly brilliant object  
>> (or at least a  complicated object that is "good enough") I often  
>> want to re-use it  in other projects. If I've separated the  
>> scripting from the objects  it becomes much more difficult.
>
> But sometimes that modest effort can pay big dividends down the road.
>
> For example, I have a table object that I use throughout many of  
> the apps I write.  It has a lot of code, and parts are rather  
> tricky, so if I replicated it I'd have a lot of replicated code and  
> if I need to change it I'd have a lot of work applying those  
> changes to each instance.
>
> So instead I have as little code as possible in the group itself,  
> and put most of the code in a library.  There's only one copy of  
> the code, and maintaining and enhancing it is a breeze.

Well said and well-argued, as usual, Richard. But I don't think we're  
saying two widely different things. When you put code that is  
specific to certain objects or groups into a library, you have still  
made it modular and easily portable. This is lots different than  
hunting down a handler or handlers in a huge stack or card script and  
hoping you have copied and pasted everything you need into the other  
project.
>
>
>> 2. As a project grows in complexity, a stack script that  
>> contained  all handlers in the stack could easily swell to several  
>> thousand  lines. In this case it actually becomes *harder* to  
>> maintain, as you  must scroll or search through a huge script to  
>> find the handler  you're looking for.
>
> True, so I break my code up into separate libraries, each dealing  
> with a particular area of functionality (menu commands, file  
> management, etc.).
>
> In fact, menu commands are a good example of the benefit of  
> centralizing code, since having them all in one shared library  
> makes it easy to add contextual menus at any time.  If the code for  
> menu handling were in the menu bar I'd either have to replicate it  
> in the context menu, or use a lot of send commands.
>
> Finding handlers is a job best left for the computer.  My script  
> editor has had handler definition lookup for years, and Jerry's  
> does too.  I'm sure Rev will catch up sooner or later as well.
>
> So I agree with just about everything you wrote, but I'm not sure  
> there's a One Size Fits All answer to this question.
>
> Jerry's axiom is helpful, but the definition of "necessary" will  
> change from context to context. ;)

Absolutely. One of the strengths of Rev, and what makes it such an  
adaptable tool for developers' differing approaches, is the ability  
it gives you to structure a project any way that makes sense to you.  
Of course, that doesn't mean it will make sense to the next guy that  
looks at it. ;-)

Still, the idea of completely self-contained "objects" is very  
appealing to me--think Shao's or Sarah's calendar objects/stacks, for  
example. Many of these modular "objects" are so specialized that  
generalizing the code into libraries might not make sense. I think  
there's an important difference between reusable, modular, "objects"  
and libraries of common handlers and functions.

Cheers,

Devin

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University