Andre Garzia wrote:
As I read on this quick email, it appears that you have some
massive amount of data to store, I'd use some database engine for
that, it's easier to query then the file system and you can make
better data relationships than simply storing files. Some database
engines support transactions, using them you can avoid the problem
of one user fiddling with the other users data. You could use an
embedable database engine such as altSQLite or Valentina.
This is an excellent suggestion. I was planning the db move for the
next version (after I come across at least one or two persons
interested in using it) but got sloppy about it. I am storing data in
custom properties for now... and have to say that I have not been
motivated to change my code because of performance issues yet (with
about 500 entries already in the app).
But my main concern was to make sure I would avoid the following
scenario: A user download it on a computer where there are multiple
accounts. On a mac, it install the rev stack in the application
folder. It starts storing its data. Another user spots the
application in the Application folder, start using it, erase the
list, enter new data.
It seems to me that whether I store the data in files or databases, I
should always follow Mark's (Smith) recommendation:
and you could easily store the user's name in it to identify it.
I guess I can easily extract it from one of the special path detailed
on Ken Ray's site:
<http://www.sonsothunder.com/devres/revolution/tips/file010.htm>
Any parsing precaution to take when parsing special paths and dealing
with non English Languages? I am French speaking but all my system is
in English, so I cannot really easily test for it.
Dave wrote:
Using pathToUsersDocumentsFolder would therefore be a better
approach, but I don't really want to create a file within this
folder as the file is in a completely adhoc format that would
puzzle anybody who come across it.
It's not uncommon to see folder and files created by various
applications in the OS X Documents folder (specialFolderPath
("docs")). In mine I see the following folders:
Acrobat User Data
Adobe Reader
AppleWorks User Data
If you check out, the Acrobat User Data are only made of their legal
license. Other applications use this folder to store cache documents.
Nothing really important. Here I want to store data collected over
weeks and months. If for some reason the user don't really understand
what he folder or file is for and decides to trash it... I will get a
*very* angry user to deal with. Sure that will be one mishap for 100
users, perhaps less, but I prefer to avoid to take the risk.
Jim Ault wrote:
Data could be stored in custom properties and
written/sent/memorized before quitting the app. A single write
operation is
actually quite fast. Filtering is very fast.
Thanks for the tip. That's exactly what I do. Data are not that big
as it is only text, with each entries storing a bookmark. I don't
really expect more than 1000-5000 entries to be provided.
Richard Gaskin wrote:
Whenever I'm working in Rev stack files are my favorite format -
here are some enticing tips for that:
<http://lists.runrev.com/pipermail/use-revolution/2002-July/
006149.html>
Thanks for the link. This is useful. I may give a try to this.
Substack with a new card created for each user, data that I presently
save as custom properties of a field in the main stack being rather
saved as custom properties of a card (with the user name) in the
substack. The advantage of this is that the data remains with the
application, even if the user changes of platform.... A danger,
however, is that this works only as long as the user has the same
user name on the different machines. I guess I have to take the
precaution to check for the existence of a card with the user name
and if don't find it, I should present a dialog box with the
usernames I have and let the user choose one of these.
Marty Knapp wrote:
While we're on the subject of saving data from a standalone, there
seems to be an intermittent bug on a Mac OSX version of a
standalone where the closeStackrequest and shutdownRequest handlers
are ignored. So if you trap for those expecting to give your user
the opportunity to save data (in whatever way you choose) you may
be in for a disappointment. At least this has been my experience.
Anybody else?
I had a similar problem. I tried to rely on closeStackRequest and
shutdownRequest but discovered them to be unreliable. I didn't test
this thoroughly though, you will need to get others confirm this.
Thanks all!
Marielle
------------------------------------------------------------------------
--------
Marielle Lange (PhD), Psycholinguist
Alternative emails: [EMAIL PROTECTED],
Homepage
http://homepages.widged.com/mlange/
Easy access to lexical databases http://
lexicall.widged.com/
Supporting Education Technologists http://
revolution.widged.com/wiki/
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
