Many Cards vs. Lists vs. XML

[Sivakatirswami]

(sitting here cranking out PDFs... got time...)

Like Richard said: depends on your project.

For die-hard "only language I know or ever want to learn..." xTalkers... 
"many cards" still works for read only, single editor at a time projects 
with relatively small data sets where an open source back end is not a 
requirement.

I have several projects that use stacks with 3000-5000 cards. They have 
the advantage that you stay entirely in a Revolution environment, 
rapidly code the UI, easily distribute to volunteers (bundle with a 
standalone loader)  etc.. your GUI *is* your data base... you don't have 
to build a data base and then build another application to "talk" to 
it... they are one and the same.  You can just drop this stack on your 
web server and talk to it with a CGI, "as easy as pecan pie" . This is 
very sweet.

accessing the data then becomes as simple as

start using stack "my4000CardStack.rev"

The key to doing this efficiently, at least in my "baby xTalk" way of 
doing things
is to make sure that the primary key (ID, etc... whatever you are using) 
is not only 1 of the fields in the records, but you also set the card 
name to that same value.

Then the internal global "the card names of this stack" becomes a super 
fast index to your data. And you can do all kinds of smart stuff, very 
easily, with marking cards to create sets etc... build arrays from the 
data in the cards...blinding fast search and displays and you never  
actually "go to card x" except for data entry.

e.g. the back end data container for this little dictionary:

http://www.himalayanacademy.com/resources/lexicon/

is a stack with about 3,500 hundred cards...

Everything works almost instantaneously. Putting all the data into 
custom properties also works if you prefer a 1 card "single window on my 
data" approach to stackware...

The Pros and the limitation of this model comes from fact that the 
entire stack is loaded into memory. I have one stack that contains 
73,000 records (simple name and address and a few more pieces of info 
for each person) in a single custom property. That stack is 10 
megabytes... this is a threshold where the disk I/O starts to feel a 
little sluggish if you have to do a lot of open and saves... but even at 
this size, if  you load it once and the rest of usage is primarily just 
reading the data... it sparkles. It's pretty much a free form dbase with 
pipe delimiter "|" between each records... With Revolution's text 
parsing power I can write complex queries against that custom 
property... in just 10-15 line of code...

To do the same thing with SQLite and dbase drivers and all that... oh 
boy..... why bother when you can do the same thing in 20-30 lines of code?

Of course there's the "nag" that says "its so much cooler to use open 
source"  "Web 2.0 MySql SQLLite  and Dbase drivers and javascript and 
ajax... but if  you were  weaned on Hypercard as a "kid" and know the 
simplicity of the stack-cards model, why go down a path that's going to 
take upmpteen hours when you can do the same thing in 30 minutes? Just 
because it is open source, offical "database" doesn't mean it's a better 
or more efficient way to get the job done.

 I see a lot of things that are "moving forward" but from a production 
manager's point of view (that's me).. .are moving backward in terms of 
productivity... 

End of Revolution (or hypercard or supercard..)

"stacks and cards are still a 2nd Millenium gold standard for lots of 
projects"

Advocacy...

Björnke von Gierke wrote:
> If no one else needs to read your files, you can use return delimited 
> lists, and enter htmltext there. Rev doesn't care if there's returns 
> between the </p><p> tags, so you can just strip it. Added bonus: 
> Styled text is preserved.
>
>
> On 16 Feb 2008, at 22:04, Russell Martin wrote:
>
>> So, I've been reading up on Rev's XML features and I'm wondering if
>> that isn't a better route to go than using lists? Any thoughts?
>>
>> Also, for those that use lists to store data, how do you handle placing
>> multiline data into your list structure?
>>
>> And, what do you do to deal with data that might contain instances of
>> your delimiter before you place it in your list? Or, is there some
>> perfect delimiter that I just haven't thought of?
>
>