Reusability: Importing existing stacks

[Chipp Walters]

Gordon wrote:

 > Sorry to keep harping on the reusability thing, but I
 > still have a question or two on reusing stacks in
 > other applications ...

Hi Gordon,

This is of course something everyone thinks of doing right away when 
starting with RR-- how to write 're-usable' code which can then be 
inserted into other stacks.

There are a number of considerations to consider for this to work.

I'll talk about this in 3 parts: SplashStack, Plugins, and Libraries.

1. SplashStack

You may find it convenient, as many of us already do, to create a basic 
'splash stack' which represents the engine and minimum code necessary to 
  load the 'other' business logic 'Main' stack. There are quite a few 
very good reasons to consider this approach:

1.1 Once you build it as a standalone, you rarely have to edit it. You 
then spend most of your time editing the Main stack, Libraries and 
Plugins, and updating them.

1.2 You can use the splash stack to actually update the Main stack if 
you like. Just have it check a URL for the latest version of the stack.

1.3. Because the splash stack is the executable (and we know we can't 
write to executables), the business logic 'Main' stack can be 'saved' 
with data intact-- though personally I *NEVER* save a business logic or 
Main GUI stack in runtime. I rather use external files or invisible 
'data' stacks to store data.

1.4 Your splash stack can do things like check for an internet 
connection, pass on environment variables, etc.. to your 'Main' stack.

Some notes about designing you Splash stack.

1.5 Consider keeping it simple as possible. Do NOT put your basic 
libraries in it as you will then need to keep updating your standalone 
everytime you want to update your library.

1.6 Add a nice 'About' screen and image to it, and show the screen when 
launching. After launching, and opening the 'main' stack, delete the 
Splash stack from memory. In that way you can be sure no handlers are 
running or can be called. The splash stack should have NO OTHER 
relationship with the main stack other than to launch it. It keeps it 
simple this way.

1.7 Have the SplashStack launch only 1 other 'main' stack, not a bunch 
of them. If your main app has 'other' stacks (I call 'plugins') then 
launch them from the main stack.

2. Plugins

Plugins as referred to here are not meant to be 'RunRev' plugins, but 
rather plugins to the 'Main' stack. These are other GUI type stacks 
which have a 'segmented' function. An Address stack could be such a 
stack. The main stack can launch these stacks with a click of the button 
and the new stack is opened. Users interface directly with these stacks.

Plugins are a great way to add functionality and deal with the ever 
growing complexity of large projects. See "The Hemingway Approach" for 
more information and some examples of how plugins may be used:

http://www.altuit.com/webs/altuit2/RunRevCaseStudies/Hemingway.htm

3. Libraries

Libraries are common code routines you want to make available to your 
projects. Typically, they have no GUI or interface, and can be called 
from any of the stacks in your application. I generally have several 
libraries in my projects. For instance, I wrote a library called 
"altInternetLib" (I preface all my libraries with 'alt'-- as Scott Rossi 
seems to prefer it that way). altInteretLib has all my routines for 
getting data to and from any internet server. It deals with proxy 
servers, etc.. In this way, anytime I need to access the internet, I can 
call a function like:

put altPost("getList.asp","listName=friends&MaxRows=6") into tData

and it will take care of all of the error handling, domain management 
etc.. for the request.

Libraries are very powerful, and sometime do have a GUI. For instance, I 
have a "Registration Library" stack which I can use to 'time-limit' 
demos and prompt users for purchase.

I hope this helps.

best,

Chipp