State/history/undo-redo support in Rev Apps

[verlsnake]

How is UI state management handled in Rev Apps ? In the context of web browser based
software one speaks of history management and back/forward/refresh buttons to tackle this
topic. In more traditional desktop software one speaks of state management and undo/redo
functionality. So how can this important user experience be provided in Rev Apps ?

[BvG]

No idea what you mean, but you can do "go to next card"etc. There's a property "the recentcards", which you can also circumvent with "the lockRecent" property.

As for undo you're mostly on your own, unless the "undo" command covers what you want to do.

[FourthWorld]

Ah, Undo. Few things look so simple to the end-user yet are so complex under the hood.

Rev provides a wide variety of properties and methods to access and store those properties to accommodate nearly any form of state management needed. These include both data relating to the appearance of objects and the user's selection, both of which will be needed when implementing Undo.

But the specifics of what will be needed for undo will vary broadly from app to app, and even within an app from undoable action to undoable action.

Actions which might be useful to provide undo for can range from moving objects to editing text, and Rev's built-in undo command handles both of those for us pretty well automatically.

But most apps will need a lot more to fully implement undo for the specific actions a given app supports, and while Rev's scripting makes much of this easier than in other languages, the nature of the task requires an algorithmic process similar to how undo is handled in nearly any language.

While there are many different methods of implementing undo, the one I settled on requires that we structure our code so that every user action is translated to a corresponding handler depending on the context (the Delete key and Edit-Cut both trigger "DeleteNode" in a concept-mapping app we build when a node is selected). Before the node is actually deleted we store the info we'll need to recreate it, as well as any other affected elements such as lines which may connect to that node, along with information for reestablishing the user's selection.

These are stored in an array which includes a references to the stack in which the action is happening. In an app which supports multiple windows, each window will need its own undo queue to avoid doing an action in one window, bringing another to the front, and then undoing the action in the wrong window.

Then for each of these action handlers we have a corresponding Undo handler complimenting them (UndoDeleteNode), which uses the info we've stored in the action handler to recreate objects and restore the selection.

Yeah, it's a bit of work, but Undo usually is in just about any language.

We've discussed this periodically on the user-rev discussion list over the years, and while we'd appreciate having more of this handled for us by the engine we've been unable to come up with proposals that will satisfy the range of tasks people need to undo across the variety of apps they build.

If you have suggestions on ways the engine could provide enhanced assistance for implementing undo I'd be glad to help advocate them. While those of us who've pondered this thus far haven't come up with good ones yet, I believe the opportunity still exists and is well worth the pursuit.