This is what I must figure out next, and what must surely lie upon the path of anyone looking to make remarkable web applications with Laszlo on Rails.
Views and their contained sub-views must be able to choreograph movements between themselves in a predictable and consistent manner. If I click on an iconified representation of a sub-view, say an address book in a mail application, this application must be able to query the currently focused view to see if it can yield that focus to the address book sub-view, or if it needs to prompt the user for confirmation about saving data, or something, first. Then, the currently focused view must be told to perform whatever changes in visual state are required to yield, and the newly focused address book must animate itself from inconified representation, to full bloom.
None of this is new to those of us who have been programming windowed and multi-media interfaces outside of the constraints of HTML. I have, in fact, developed frameworks for view and state management on practically every development platform I have worked on, in DOS (FoxPro), Windows (Delphi, Visual Basic), Macromedia Director (Lingo) and Java. This seemed especially well implemented in IFC, the Internet Foundation Classes which were the (much more elegant) forerunners of Swing.
In terms of implementation, it seems obvious that a subclass of the lzx View class would fit the bill. Add some state variables, perhaps a hash of values, and generic query(x) and perform(y) methods, and off you go. Nick was kind enough to provide me with code that already does much of this, which I am free to use for inspiration. Thanks, Nick.
What's important is that you need to feel comfortable that as long as your super-views, I prefer to call them Scenes (in a nod to the desire to create cinematic user experiences as described so eloquently by Brenda Laurel in "Computers as Theater") — as long as they obey a few simple rules then the user is free to drive their own plot from Scene to Scene and our application will remain in a consistent and predictable state.
Objects need to be persistent. In the world of Laszlo, Dataset objects provides some remarkable capabilities in that regard. How can we extend that to all objects so that, again through inheritance or prototype mixins, all of our objects can persist themselves? The first application I see for this is the Scenes themselves — when a user returns to my application I want them to find it exactly as they left it. The application itself projects a sense of permanence. Of course, "business objects" and other non-visual things could be similarly persisted.
I understand there has already been some work done in this direction. Oliver Steel has written an lzx JSON implementation that rides on top of datasets. Max Carlson has some kind of MVC functionality built on top of datasets — essential for shared data between users that can update in pseudo-realtime — anything from chat to site-wide notifications to games or other shared virtual world data. This stuff gets pretty heady pretty fast because it is so pregnant with possibilities. So, not just persistence but persistence with publisher/subscriber queues on the server so that data can be shared immediately by users.
A ballet of views and data. A dance with the user. Let's start with that.