Hi Graham,
So for me the issue is how to reach this point from where I am today.
Has anyone any advice about shifting my existing code into libraries
without having to massively restructure my existing apps?
First, you have my sincere condolences.
Second, you've made a wonderful case for the need for library stacks
Third, it will be a pain in the arse; but the longer you wait, the
worse things will get and the greater the task will become.
So far all I have thought of is to remove the 'common' code to a
library but to retain the handler that was in the original app simply
as a wrapper - a wrapper handler would look like
on myOldHandler para1, para2
do myLibraryStuff para1,para2
end myoldHandler
A little good news: unless your scripts contain declared local
variables, there's a good chance this step is not necessary.
Given a control with a script including
on mouseUp
put field "Quantity" into para1
put field "Unit Cost" into para2
myOldHandler para1,para2
put the result into field "Total Cost"
end mouseUp
on myOldHandler para1,para2
global taxRate,shippingTable
get para1*para2
set the numberFormat to "#.00"
add (it*taxRate) to it
repeat for each line shippingRate in shippingTable
if item 1 of shippingRate >= it then
add item 2 of shippingRate to it
-- assumes last line of shipping table covers largest
possible amount
return it
end if
end repeat
end myOldHandler
, all you have to do is copy myOldHandler to the library stack, remove
it from the control's script, and start using the library stack when
the stack containing the control opens.
However I have been (I suppose) rather careless with ways of passing
values, using various techniques including setting globals, specific
fields etc. If the library is not to have too many side effects then I
have to generalise those routines too, and that's the bit which I
would like to do as efficiently as possible. Maybe it's just a messy
job and that's all there is about it, but I'd like to know what other
people think.
I hate to confirm what you don't want to hear; but, yes, it ends up
being a messy job for the reasons you identified: creating a
generalized handler from two or more similar handlers in different
stacks often means changing the scripts in both. To the extent that
your common handlers are generic, you might adopt your controls to use
handlers in existing rev libraries rather than generalizing your
handlers as well as the scripts of controls that call them. Serendipity
Library <http://wecode.org/serendipity/> includes handlers for data
validation & formatting, date & time handlers, and list handlers in
addition to SDB database handlers.
The good news: when you are finished, the efficiency you will gain is
worth much more than the effort involved.
Rob Cozens
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
_______________________________________________
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
