Design: how to handle temporary data with Rev?

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
mluka
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 73
Joined: Sun Jun 17, 2007 12:08 am

Design: how to handle temporary data with Rev?

Post by mluka » Sun Aug 12, 2007 3:26 pm

Hi, all.

I'm in the planning stages for a "counter" application (order entry, delivery, payment, etc.) in a dry-cleaning store. The user interface will be done in Revolution, the data will be kept in MySQL databases.

One of the design questions I'm facing is this: in the process of "building" an order, a common practice is to build up the order in a temporary file, allowing the counter person to add items to the order, modify them, etc. until the order is complete.

Then, on the click of a button, all the relevant tables (customer, order header, order details, product statistics, etc.) are updated and then the temporary file is wiped clean in preparation for the next order. There may be several orders being buit up at the same time (networked environment).

My question is this: in the Revolution environment, what would be the recommended approach on where to keep the "temporary" order: a MySQL table, a substack, a background in the main stack?

A more general question: are there, on the Web, Revolution design guidelines?

Thanks for your ideas and suggestions!
Michel
Montréal, Canada

Mark Smith
Posts: 179
Joined: Sat Apr 08, 2006 11:08 pm
Contact:

Re: Design: how to handle temporary data with Rev?

Post by Mark Smith » Mon Aug 13, 2007 12:42 am

Well, you have many choices!

The approach I usually take with 'temporarily persistent' data is to store it in the form of an element of a script local array variable, and have setter and getter handlers to get at it.

So in the script of the main stack I might have:

Code: Select all

local sTempData

function getTempOrder pOrderID
  return sTempData[pOrderID]
end getTempOrder

on setTempOrder pOrder
  <code to build the id, or pass an ID as a second param>
  put pOrder into sTempData[tID]
end setTempOrder

and then, when you've committed the order to the DB

on deleteTempOrder pOrderID
  delete variable sTempData[pOrderID]
end deleteTempOrder
But you could do similar things with customProperties, files etc.

Best,

Mark

glen930
Posts: 4
Joined: Mon Jul 24, 2006 5:28 pm

Post by glen930 » Thu Aug 16, 2007 2:51 pm

Hi Mluka,

Another approach is to keep your "template" in a field then dump it to a variable or other field, do any modifications, and submit that data.

Put place holders in your template (i.e. some unique string) that you could use "replace" on to build your query.

Crude and simple, but its works for me.

Glen

mluka
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 73
Joined: Sun Jun 17, 2007 12:08 am

Post by mluka » Sun Aug 19, 2007 7:35 pm

Hi Glen (and welcome to the forum!) and Mark.

Thanks for your ideas. Just goes to show that there are indeed many ways to skin a cat!
Michel
Montréal, Canada

Post Reply