Re: Q. data stacks and app design
Jeanne A. E. DeVoto wrote: At 10:56 AM -0700 10/4/2002, Alex Rice wrote: Is there any way to get Rev to save out only selected substacks into seperate files? It would clean up my installation a little bit if everything was in the standalone app, except the data substack. Sure. The canonical way to do this, if your app will be creating its own documents, is: In think Alex meant that the button move substacks to separate folder in the distribution builder moves all substacks. But you don't have to use this. Stick any stacks you like in the data folder manually and reference them from the app using the defaultFolder /data/ yourStackName. Then just don't click the button and you can have some stacks in the data folder and others (not save-able) retained in the standalone file. Is that what you meant? mark mitchell Japan ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
On Thursday, October 3, 2002, at 11:11 PM, Ken Ray wrote: The other thing that seems to me to be easier to maintain in custom props is data that needs to be in an array form. Since custom props already are basically arrays, you can take advantage of that without having to worry about data delimiters you'd have in files/databases/cloned stacks. That's my $0.02, anyone else want to chime in? This is awesome, guys. I just read Richard's post from July too, thanks! But, I'm not understanding the differences/trade-offs between cloning stacks vs. put/set the data to a stack's custom props. (as in Richard's post) Sounds like custom props is the way to go for my app! I've made a big database based only on external text files. It runs very fast but this is limited to MAC only because of the ASCII code -- Greetings. Yves COPPE Email : [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design -thanks
Thanks Richard and Ken From: Richard Gaskin [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Thu, 03 Oct 2002 21:45:02 -0700 To: [EMAIL PROTECTED] Subject: Re: Q. data stacks and app design Ron wrote: Would you care to comment on the pro/cons of maintaining a data file or a preference file as an external text file rather than, say, a user prop of a data/pref stack? http://lists.runrev.com/pipermail/use-revolution/2002-July/006141.html -- Richard Gaskin Fourth World Media Corporation ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
yves COPPE wrote: I've made a big database based only on external text files. It runs very fast but this is limited to MAC only because of the ASCII code Which ASCII code? Remeber you have macToISO and ISOToMac, as well as the replace command and other ways to manipulate text. -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 2.0: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Q. data stacks and app design
This is a fascinating topic. Seems that if you do it right, you can implement some aspects of databases. For example, I was thinking about creating a foreign language dictionary which relates English words to words of the other language, including links between synonyms. Anyone have suggestions on a good way do implement this? -- D -Original Message- From: Richard Gaskin [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 12:45 AM To: [EMAIL PROTECTED] Subject: Re: Q. data stacks and app design Ron wrote: Would you care to comment on the pro/cons of maintaining a data file or a preference file as an external text file rather than, say, a user prop of a data/pref stack? http://lists.runrev.com/pipermail/use-revolution/2002-July/00 6141.html -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 2.0: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
On Thursday, October 3, 2002, at 08:40 PM, Sarah wrote: If you are going to be reading your saved data from another stack, the easiest thing is probably to save a copy of the data stack somewhere. Then your reader stack can just open the saved data stack at any stage. When you build your app, make sure it saves the substacks into separate files. This will allow your data stack to be saved (so long as it isn't the mainStack) either to it's default location or to your storage location. Is there any way to get Rev to save out only selected substacks into seperate files? It would clean up my installation a little bit if everything was in the standalone app, except the data substack. Thanks, Alex Rice, Software Developer Architectural Research Consultants, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
At 10:56 AM -0700 10/4/2002, Alex Rice wrote: Is there any way to get Rev to save out only selected substacks into seperate files? It would clean up my installation a little bit if everything was in the standalone app, except the data substack. Sure. The canonical way to do this, if your app will be creating its own documents, is: 1. Include a document-template stack in your stack file. 2. To create a document, use the clone command: clone stack Template -- makes a copy of the substack set the name of stack it to Untitled1 -- or whatever 3. To save that cloned stack, use the save command: set the name of stack Untitled to Saved Stack Name save stack Saved Stack Name -- brings up standard Save dialog or else save stack Saved Stack Name as /Disk/Folder/MyStack.rev This saves the stack without bringing up the dialog box. (Depends on whether this is a user document, or something like a prefs file that the user doesn't need to set the location and name for.) There is an example in the Employee Database stack that's discussed in the Independent Study tutorial. The Employee Database creates its own documents and lets the user save them in this fashion. -- Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] Runtime Revolution Limited - The Solution for Software Development http://www.runrev.com/ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Q. data stacks and app design
I am writing an app which is a long survey followed by a couple of long reports. I want to save the state of the survey to disk and have different projects which the user names/saves/restores. Each project is just the set of answers to the survey questions. A SQL database is not needed. In the SQL mindset, this data would have a handful of rows and maybe too many columns to deal with-- many hundreds. I'm sure it could be normalized better, but there is not enough data to warrant a SQL database. Even the Serendipity Library SDB database looks like overkill for this app. So I think I need to use a data stack. What's the most elegant way to get cards and/or stacks to write all it's state out to disk, which I can go check on later from another stack, and write a report from the responses? I hope this question isn't too vague. I'd be glad to tell more about the application if it's not clear what I'm asking. Thanks in advance! Alex Rice, Software Developer Architectural Research Consultants, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
If you are going to be reading your saved data from another stack, the easiest thing is probably to save a copy of the data stack somewhere. Then your reader stack can just open the saved data stack at any stage. When you build your app, make sure it saves the substacks into separate files. This will allow your data stack to be saved (so long as it isn't the mainStack) either to it's default location or to your storage location. Sarah On Friday, October 4, 2002, at 10:55 am, Alex Rice wrote: I am writing an app which is a long survey followed by a couple of long reports. I want to save the state of the survey to disk and have different projects which the user names/saves/restores. Each project is just the set of answers to the survey questions. A SQL database is not needed. In the SQL mindset, this data would have a handful of rows and maybe too many columns to deal with-- many hundreds. I'm sure it could be normalized better, but there is not enough data to warrant a SQL database. Even the Serendipity Library SDB database looks like overkill for this app. So I think I need to use a data stack. What's the most elegant way to get cards and/or stacks to write all it's state out to disk, which I can go check on later from another stack, and write a report from the responses? I hope this question isn't too vague. I'd be glad to tell more about the application if it's not clear what I'm asking. Thanks in advance! Alex Rice, Software Developer Architectural Research Consultants, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
Alex, Why don't you just maintain the data in an external text file? Then, you can read and write it as simply as: put url (file: tFileName) into tData and put tData into url (file: tFileName) Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: Alex Rice [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 7:35 PM Subject: Q. data stacks and app design I am writing an app which is a long survey followed by a couple of long reports. I want to save the state of the survey to disk and have different projects which the user names/saves/restores. Each project is just the set of answers to the survey questions. A SQL database is not needed. In the SQL mindset, this data would have a handful of rows and maybe too many columns to deal with-- many hundreds. I'm sure it could be normalized better, but there is not enough data to warrant a SQL database. Even the Serendipity Library SDB database looks like overkill for this app. So I think I need to use a data stack. What's the most elegant way to get cards and/or stacks to write all it's state out to disk, which I can go check on later from another stack, and write a report from the responses? I hope this question isn't too vague. I'd be glad to tell more about the application if it's not clear what I'm asking. Thanks in advance! Alex Rice, Software Developer Architectural Research Consultants, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
On Thursday, October 3, 2002, at 08:40 PM, Sarah wrote: If you are going to be reading your saved data from another stack, the easiest thing is probably to save a copy of the data stack somewhere. Then your reader stack can just open the saved data stack at any stage. When you build your app, make sure it saves the substacks into separate files. This will allow your data stack to be saved (so long as it isn't the mainStack) either to it's default location or to your storage location. What is a data stack, just a hidden stack with a big Field in it? Alex Rice, Software Developer Architectural Research Consultants, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
It is a separate stack and can be hidden or visible. The main point is that it is not the mainStack of the file. When you build an application, you can either have it all in one file, or put the substacks in separate files. If the application is all in one file, it is read-only and no data can be saved as part of the application (you can always use external files to save). If you make an application with separate substacks, all but the main stack are writable and can store your data. Sarah On Friday, October 4, 2002, at 01:22 pm, Alex Rice wrote: On Thursday, October 3, 2002, at 08:40 PM, Sarah wrote: If you are going to be reading your saved data from another stack, the easiest thing is probably to save a copy of the data stack somewhere. Then your reader stack can just open the saved data stack at any stage. When you build your app, make sure it saves the substacks into separate files. This will allow your data stack to be saved (so long as it isn't the mainStack) either to it's default location or to your storage location. What is a data stack, just a hidden stack with a big Field in it? Alex Rice, Software Developer Architectural Research Consultants, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
Why don't you just maintain the data in an external text file? Then, you can read and write it as simply as: put url (file: tFileName) into tData and put tData into url (file: tFileName) Ken Ray Sometimes this is a good solution, but there is a possible problem you have to keep in mind: When you develop for a multi-platform app and the text file is brought from one platform to another, you have to keep in mind that the text can contain upper-ascii chars (international chars, etc.). They are automatically taken care of when in a field, but you have to do that 'yourself' (call the MacToISO or the ISOToMac function) when the text is in a text file (or in a custom prop). But if a text is already ISO encoded and you use MacToISO, you get output that is incorrect on any platform. So you have to know where the text comes from to do this right. And that is not always obvious. Terry ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
Ken, and others, Would you care to comment on the pro/cons of maintaining a data file or a preference file as an external text file rather than, say, a user prop of a data/pref stack? Is it simply a matter of 'style' or are there distinct advantages to each? Thanks Ron From: Ken Ray [EMAIL PROTECTED] Organization: Sons of Thunder Software Reply-To: [EMAIL PROTECTED] Date: Thu, 3 Oct 2002 21:42:28 -0500 To: [EMAIL PROTECTED] Subject: Re: Q. data stacks and app design Alex, Why don't you just maintain the data in an external text file? Then, you can read and write it as simply as: put url (file: tFileName) into tData and put tData into url (file: tFileName) Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: Alex Rice [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 7:35 PM Subject: Q. data stacks and app design So I think I need to use a data stack. What's the most elegant way to get cards and/or stacks to write all it's state out to disk, which I can go check on later from another stack, and write a report from the responses? I hope this question isn't too vague. I'd be glad to tell more about the application if it's not clear what I'm asking. Thanks in advance! Alex Rice, Software Developer ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
On Thursday, October 3, 2002, at 11:11 PM, Ken Ray wrote: The other thing that seems to me to be easier to maintain in custom props is data that needs to be in an array form. Since custom props already are basically arrays, you can take advantage of that without having to worry about data delimiters you'd have in files/databases/cloned stacks. That's my $0.02, anyone else want to chime in? This is awesome, guys. I just read Richard's post from July too, thanks! But, I'm not understanding the differences/trade-offs between cloning stacks vs. put/set the data to a stack's custom props. (as in Richard's post) Sounds like custom props is the way to go for my app! Alex Rice, Software Developer Architectural Research Consultants, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
on 10/3/02 8:19 PM, Alex Rice at [EMAIL PROTECTED] wrote: What is a data stack, just a hidden stack with a big Field in it? -- Hi Alex, I'm a newbie too, although I've done some developing in HyperCard over the years, and am close to releasing some adaptive/freeware for the Mac written in HC and designed specifically for older machines. For a number of reasons I haven't gotten into Rev's more complex UI (I'm not a pro-programmer), but I'm redeveloping my programming philosophy to work with it, and to include the advantages of using data stacks, even in HC. Two main examples: 1) Feature options and preferences -- You can design your stack to add more of these as plugins later, thus effectively updating it without rewriting the main UI. 2) Saved data -- You can design your stack to save data it uses to work with separately. This way you can just back up the text, numbers, images, sounds, or whatever, elsewhere, so if you have a crash, all your work will be safe instead of being lost with the app. What it means is using the basic RR/MC model. You develop a main stack and some substacks as a UI, a front-end which is mainly just menus, button controls, and indexes that manipulate and display stuff you store in other stacks. Hope this makes sense to you. Ken N. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Q. data stacks and app design
Alex Rice wrote: But, I'm not understanding the differences/trade-offs between cloning stacks vs. put/set the data to a stack's custom props. (as in Richard's post) Two different animals: cloning creates user interface elements on the fly. Props store data. You can store data in cloned stacks that also have a UI, with the potential draw back that your documents now also contain code, so if you need to update code you have to not only change the code in your app, but als in all of your user's documents. On the flipside, moving data from data-only stacks into UI stacks for dsplay may be more trouble than its worth for some circumstances. What are you making? -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 2.0: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
