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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
