AW: where to put handlers?
devin_asay at byu.edu
Wed Feb 6 13:12:32 EST 2008
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
>> 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
>> 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.
Humanities Technology and Research Support Center
Brigham Young University
More information about the Use-livecode