Reusability: Importing existing stacks

J. Landman Gay jacque at hyperactivesw.com
Tue Nov 23 00:41:37 EST 2004


On 11/22/04 6:19 PM, Gordon wrote:

> Suppose I want to write e.g. a generic kind of stack
> for entering and storing somebody's name, address and
> contact details - exactly the kind of stack you could
> imagine one might wish to use in a whole host of
> business applications for example. Now supposing I
> want to use that stack in my whizzy e-business app for
> recording my client's details - is there some safe and
> easy mechanism by which the main (container) app can
> apprise itself of all the variables, functions etc. in
> my name/address stack so that they are available
> throughout the main app, or do I have to declare all
> my name/address variables again as globals in my main
> app? 
> 
> It seems like this would be a very tedious and
> uncertain way to combine stacks in a big, complex app,
> since any stuff I forget to declare again (or mistype)
> will be lost to the main app. That's why I'm sure that
> the HyperCard brainiacs have already come up with a
> way to do this that is way less moronic than I'm
> proposing here. Yes?

You shouldn't have to worry about the variables that are used in the 
address stack; those should be used only by that stack itself. The key 
is to write your address stack so that it is self-contained, so that the 
Big App stack doesn't have to know anything about how the address stack 
obtains or stores information.

To do that, put command handlers and/or functions in your address stack 
to deal with all the info that you might want to access from elsewhere. 
Functions return data to whatever script requests it, so for an address 
stack something like this might be common:

function personData thePerson
-- do here whatever the stack needs to do to locate thePerson's record;
-- that might be finding the card and reading the fields,
-- accessing a database, reading a global variable, etc.
-- Once the data is obtained, put it into a variable and
-- return the info. Here, the data has presumably been placed
-- into a variable called "theData":
   return theData
end personData

The Big App stack doesn't have to know how the address stack got the 
data for that particular person. It doesn't need to know about any of 
the variables the address stack may have used, or the values of any of 
the fields or objects. The Big App stack just needs to know the name of 
the function that will return the data it wants. So all the Big App 
stack has to do is this:

  put personData("Bob Smith") into theRecord

Then Big App goes on its way and uses the information stored in 
theRecord however it needs to.

Make sure that the address stack is in the message hierarchy so the 
function can be found (that is, put the stack in use or insert the 
script into the front or back.)

I'm sure others here can talk more about self-contained code. This is 
the basic idea for building all library stacks, too.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com


More information about the use-livecode mailing list