Helping newcomers anticipate that standalones can't save to themselves

[Richard Gaskin]

kee nethery wrote:

 > I use the launcher/updater with the script/data stack model so my
 > standalones can save changes into it’s stacks. Wonder if it would
 > make sense to have a standard version of that launcher/updater so
 > that newbies can just grab it and use it.

In a sense, that suggestion is for a type of application template, 
likely very much a good thing esp. when we consider how frequently folks 
mention that something they miss from HyperCard was its collection of 
prefab components.

It may be worth pursuing, perhaps even as a community effort, which 
would allow us to have what we want right now without having to take 
resources away from the engine team.

But if we were to go down the route, we'd probably want to deliver a 
collection of such templates rather than just one, so folks can better 
appreciate the many different ways LiveCode can be used, some of which 
are very important to use for some applications, while other methods are 
important for other apps.

For example, while saving a stack file is convenient, it's only 
convenient for one version.  If a future version of your app has an 
opportunity to display the data in a different UI, how do you update the 
UI when it's been saved in stacks made with an older version?

In most languages there isn't much of an opportunity to save the UI with 
the data, or at least not as temptingly easy as it is in LC, so the 
common convention is to externalize data from its presentation, 
something most frameworks provide strong support for.

For many apps externalizing data is only beneficial for future UI 
enhancements, and as useful as that is there's another set of 
considerations as well with LC:  What do we do in circumstances where 
the collection of data if stored on cards may grow over time to a number 
of cards no longer practical in LC?

Fortunately LC includes very strong database support, and at this point 
most of us who manage sizable collections of data use those or similar 
means of managing persistent data outside of our apps.

But which storage method is best for the app you're working on right 
now?  And will it be the best choice for the app you're working on tomorrow?

Thinking about this with a breadth that admittedly may lend itself to 
oversimplification, we might think of apps as falling into three categories:

- Utilities: usually a single window, no documents, and the only
   persistent data is prefs.  A calculator is a good example.

- Databases:  usually a single window, though it may have secondary
   windows for specific views or tasks, which need prefs as well as
   a database file of some kind usually in a fixed location.  iTunes,
   Address Book, and RhythmBox are good examples.

- Document-centric:  multiple windows in which each window is a view
   to data store in a separate file located in a place of the user's
   choosing.  Word processors, spreadsheets, drawing programs, etc.

So if we were to make templates, it may be helpful to make at least three.

What other types might we need?

And given the complexity inherent in maintaining the relationship 
between document files and the view of document data in a window, how 
might we do this simply in a way that avoids the complexity an high 
learning curve of a framework?

And for all three types, we have both the opportunity and the risk 
(depending on whether you're an optimist or a pessimist <g>) of a much 
deeper issue:  what's the simplest way to arrive at a generalized MVC 
pattern for LiveCode so we can manage the relationship between a data 
store and views of the data easily?

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