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 tDataand 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 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
