Home : FreeCard : UserStories

Message-Passing Hierarchy

A FreeCard document is a container, called a "stack", that has properties and contains backgrounds. A background is, in turn, a container that contains cards that have properties in common. The "card" is the basic unit and metaphor of the GUI. It contains the widgets ("parts") that make up the GUI, such as buttons, fields, images, media players, etc.

FreeCard is an event-based program. Its main-event-loop waits for an event, and reacts to this event according to the script of the object that receives and/or passes-on the event. When the FC user does something, or something happens in the interface (ultimately triggered by the user), the appropriate event is generated by the FC-engine and it is sent to the "target" object in the form of a message.

When the object that receives a message has a handler for that message, then it handles this message. When a message is handled, it ends there ; unless the handler explicitly passes the message along to the object that it is contained by. This is accomplished by using the "pass" command.

When the object that receives a message does not have a handler for it, then it implicitly passes the message along to the meta-object that contains the current object (hierarchy). The trajectory of the message through the message-passing hierarchy corresponds to the containment hierarchy described in the first story. It starts with the target object that is activated by the user's activity, commonly a button or a field (a part). If this part doesn't have the appropriate handler for the message, then it is passed to the object that contains the part ( the card ). If this card doesn't have the handler for this message, then it passes the message along to the background that contains this card. Then it goes to the stack of this background. If the message is still not handled, then it optionally passes through the stacks currently inserted into the message-passing hierarchy (the "stacksInUse"), ending up either way in the obligatory "Home" stack. Conceptually, "Home" is the stack that contains all of the other stacks. If the message is still not handled after traversing all of these containers, then the FreeCard engine handles it. If the message is a native event, then the engine merely discards it, else a dialog rants that there is "no such handler".

Users can create messages of their own, by invoking custom handlers (commands and functions), or by explicitly sending messages to objects with the "send" and "request" commands. If the target object of these latter commands does not have the handler, then the message goes up the hierarchy from that point on. Either way, all of these custom messages must be handled by at least one of the objects in the message-passing hierarchy ; otherwise, the FreeCard engine rants that there is "no such handler".

The native functions and commands of FreeCard also trigger messages that traverse the message-passing hierarchy. They can therefore be overloaded, e.g. intercepted and redefined locally and/or passed on to the higher levels for some increasingly generic post-processing.

Other containers

• Variables

• Arrays

• Custom properties

• Files

• URLs

Architecture of FreeCard

All of the GUI's dialogs, palettes, menus, etc ... are stacks. As such, the GUI can be modified by any user who can use of the program. FreeGUI? is already an excellent example of this architecture, albeit it is currently based on the MetaCard engine. FreeCard will further enhance this by creating the global properties that will allow any user to select which component he wants by setting the corresponding property.

Examples

set the ScriptEditor? to <stack_reference>

set the ControlBrowser to <stack_reference>

set the StackInfoDialog to <stack_reference>

Scenarios

You can use FreeCard to create a database by making a background with labels and fields that are shared by all of the cards of this background. Each card then corresponds to one "record" of the database, and the bkgnd fields contain the specific content and values of each record. There are facilities for searching, sorting, and so on. Everything you normally expect from a moderate DBMS. You can also craft relational databases with FreeCard, by using several stacks at once and linking them via scripted references.

You can rapidly prototype any kind of interface because FreeCard provides all the necessary widgets and facilities to create state-of-the-art GUIs?. These stacks can then be invoked and used as stacks, palettes, dialogs, menubars, etc ... without any coding changes.

Web applications far better than anything LAMP can pull off. Craft servers as well as clients, for any platform, for any Internet protocol, within days.

Agents that are networked via the Internet.

IDE for Java, Python, JudoScript, JavaScript, and a few other languages ; all at once!

Typical use scenarios

When the user launches the FreeCard application, the Home stack appears by default. When the user launches a FreeCard document (stack), then the FreeCard application starts up and displays the stack that was launched.

When all stacks are closed, the Home stack reappears by default because there must always be at least one stack open at all times. This is how it was done in HyperCard. In MetaCard, closing the last stack quits the application. There is nothing wrong with an application running with no open documents, so we are flexible in this regard.

To use a stack, the user interacts with the widgets of the GUI. He fills in fields, clicks on buttons. He selects items from a scrolling list, or from popup menus, or from dropdown menus. Just like any GUI provides for. Text in the fields can contain hypertext-links to other cards, in the current stack as well as any other stacks, thus achieving the main feature of web browsers : hypertext browsing. Forms to fill are a gimme, of course. Submitting these forms to web servers is also available given that FC is web-savvy. There is a search-and-replace feature for locating content in the current stack, whose scope can be easily be extended via scripting.

Every object has a 'script' property. Scripting in FreeCard, as in all of the other xCards, is very distributed. Short scripts are associated with each object. They are omposed of message handlers that react to events, and a message-passing hierarchy that manages the flow of the events. Example: a mouseUp handler in a button's script, an openCard handler in the card's script to set this screen upon entering it, an openStack handler to set things up when the stack is opened, etc.

Every object has a 'scriptingLanguage' property that allows the user to set the scriptingLanguage of the object's script one of the scriptingLanguages provided within FreeCard. More than half-a-dozen of them so far, including FreeScript (ours), HyperTalk (HC), MetaTalk (MC), Transcript (RR), JavaScript, JudoScript, Java and Python. The typical FreeCard user will mainly use FreeScript.

Web-savvy scenarios

Web developers will prefer the last four languages. Since the fileFormat/etc of FreeCard is XML, and because it supports JavaScript, it will be rather easy to save a FreeCard stack as the equivalent XHTML scripted in JavaScript. Java developers will favour Java, of course, as well as its cousin JudoScript. They can therefore use FC as a RAD environment for prototyping Java-based GUIs? and as an 'agile' environment for experimenting with new Java libs/etc.

FreeCard, via a Java Lib, will have an API to all of the protocols of the Internet. It will also have all of the source code necessary to support XML, XML-RPC (blogs, wikis, CMS, etc), Jabber (chats/IM}, and so on. FreeCard will even have its own DTD (custom markup language), and will support : RDF, XSL, the Semantic Web, Web Services, etc.

Secure communication via https, certificats, signatures, secure sockets, encryption, P2P? architecture. We have all of the Java libs necessary. Christian Fleury will hopefully help us with his understanding of secure telecommunications. He used to work for Zero Knowledge Inc, and he single-handedly crafted the Macintosh version of ZK's world-reknown "Freedom" software: state-of-the-art tamper-proof security for everything web-related.

Other scenarios

Telephony.

Digital Television.

Because FreeCard is a Java application, it can be used on the server-side, as well as the client-side, on most of the operating systems that are available today : Microsoft Windows, Mac OS X, Linux, UNIX, SPARC, etc. This allows multi-platform solutions to be deployed from one platform-independent codebase w/o using the Internet for networking.