HC to Rev conversion help needed

Bill Marriott wjm at wjm.org
Tue Dec 30 02:11:36 EST 2008


Hi Dale,

> If someone could repair (or guide me to repair) the scripts in this  stack 
> plus add a new Field of Stacks to search and eliminate the  additional 
> cards it creates because HC had limited field capacity I  would donate the 
> stack to the Rev community. And maybe clean up its  appearance a bit. Any 
> comments on this would be greatly appreciated.  The stacks are located 
> here:

In many ways, your challenge is a "pathological" example of a 
HyperCard-to-Revolution conversion. You have a system which was very nicely 
optimized for the strengths of HyperCard at the time, which included the 
ability to have free-form data structures (stacks) which could have any 
arbitrary information on each card, combined with a Find command which was 
blazingly fast across that data structure. The Revolution world is a little 
bit different.

Just for starters, there are the scores of ancillary stacks which are a part 
of this system, and depending on what kind of scripting is in them, that 
could be a chore in and of itself just to get them to run without errors in 
Revolution. (If there's no scripting in them, perhaps not so tough.) But 
once you've migrated those, you have the challenge of the master 
Index/Searching system itself.

The strategy I would use here is to

- have a "magic" folder where all your content stacks are stored. It could 
be called "HyperVibes Content" for example.
- Give each content stack a "profile" card (or set of custom properties) 
with things like a PNG image of how it should appear on the bookshelf, cover 
art, its plain-English title and author, a version number, date, tiny icon, 
big icon, short description, long description, whatever.
- Then, upon startup of the gateway stack, you scan this folder for new, 
deleted, or changed items.
- When those are found, I would "index" them using an SQL Lite database as 
the storage medium.

- This would involve walking through the new/updated stack content, 
object-by-object, collecting the text that was found, and storing it in the 
SQL Lite database with location information. e.g.:

stackID: 132
stackFile: Vibrations Explained.rev
cardNum: 13
objectRef: field id 1006 of card id 1013 of stack "Vibrations"
textContent: Lorem ipsum dolor sit...

- Your main, gateway stack then becomes an interface to the SQL Lite 
repository. You can perform extremely fast searches within the "textContent" 
field across the entire system, perhaps faster than even HyperCard (much as 
though it were indexed via Google), present a list of the "hits," and 
provide a way for users to navigate to the content.
- Once you solved these issues, adding new content is as simple as dropping 
a new stack into the magic folder, with no re-coding or modification of the 
master stack required. It could appear on the bookshelf automatically; users 
could perhaps even re-arrange the books on their own to suit their own 
personal needs.

Yes, as others have hinted at, this is a re-architecture of the system and 
not simply catching a few places where things need to be tweaked. But in the 
long run you'll gain benefits:

- increased performance
- more easily maintained
- works with Rev's strengths, not against its weaknesses
- more robust/reliable

You can refine the scheme by adding fields to the SQL Lite database that 
provide context (page title, stack name, chapter, etc.) if those can be 
standardized; paying attention to the dontSearch property of a field; 
date/time stamps; authors; captions for images; page/article tags; indexed 
keywords; etc.

You could even envision a system where users download only the master 
gateway application, perform their searches against a networked MySQL 
database, and download the content stacks only when needed.

I know "SQL" is an intimidating term for a lot of us, but there are really 
only a handful of commands you'll need to know (indeed, only a handful 
supported by SQL Lite), and they're truly not that difficult.

Seems like a project with a lot of potential ... worthy of the effort, and 
something that could be of interest to a lot of people -- both from a 
programming and content point-of-view. Hope this helps...

- Bill 






More information about the use-livecode mailing list