Storing and saving a setting in a stand alone

Richard Gaskin ambassador at fourthworld.com
Thu Jan 15 19:40:30 EST 2015


Kay C Lan wrote:
> * It would probably be wise for RunRev to remove any mention of the Splash
> Stack method on their how-to site as it is clearly not an approach that
> should be used any more.

On the contrary, as the rest of your post points out, it's increasingly 
useful as OS file system permissions get ever more restrictive.

The only question is where to put the stack.

I could dig up my user data path handlers and post 'em, but I'd figured 
everyone already had their own.

But even with that there's the larger question of whether we really want 
to be saving data bound to the UI.

The anchor stack (as we called it back in the early '90s in the 
SuperCard world) design pattern is any standalone that contains only 
enough code to find some other stack that contains most of the UI.

Even when the UI is stored external to the app (a majority of the 
projects I'm working on now store the UI stacks on a server), the 
question of whether to bind data to the UI or store it in a separate 
file remains.

There are many reasons to separate data from UI, not the least of which 
is the freedom to update your app's UI without encumbering the user with 
a complicated export/import.

In our local user group we discussed how we might craft a library to 
make it easy for folks accustomed to storing data in UI stacks to 
externalize that data.

But not far into it we realized we all store data differently. 
Sometimes it's a delimited text file, sometimes it's in custom props in 
a stack file, sometimes it's in a database, other times in encoded array 
files.

Each method requires different handling methods, though we could 
conceivably craft a library to help populate a UI and manage data 
binding a la MVC, with each data store as a sort of plugin to handle the 
storage-specific mechanics in this framework.

And not far into that we realized no one wanted to even document such a 
system, let alone write it.  :)  It's very easy to craft ad hoc 
solutions for data, and orders of magnitude harder to craft a 
generalized solution for all possible apps.

But looking at the small corners of this, if a couple handlers for 
knowing the path to store files on OS X, Win and Linux would be helpful 
I can dig mine up.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list