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