Someday, there will be a proper set of web pages here.
In the meantime, here's a brief description of what MetaMenu is:
MetaMenu (MM) is a framework for creating menu-based applications. The framework centers around the concept of a state machine. Each state usually corresponds to a panel in a menu-based application (but you can have output-less states as well, of course). All I/O is handled by MM, which allows applications using MM to run in a variety of environments, such as: text-based, GUI, web, command-line, XML, etc.
Central to the concept of the menu/state-based engine is the concept of "previous" and "next" action buttons that can be used to navigate between panels/states. As such, MM, in a short and detail-bereft description is: a generic history-based menu framework for higher-level applications.
For more detail, see our SourceForge project
page, and/or joint the mm-devel
mailing list.
Specifically, applications that use MM supply a set of custom states, and then invoke the MM state machine engine. The MM engine will invoke all the states (in a defined order), and provide all the necessary I/O services (obtaining data requirements from the application, prompting the user for those data requirements, marshalling them and feeding them back to the application, etc.). Since the application is merely a set of states, MM can execute these states in a variety of environments (as mentioned above) in a "native" manner. For example:
mm
command are used) will likely also be provided. This makes all
MM-based applications highly scriptable. See below.
The first few I/O environments are suitable for interactive user use (e.g., text-based menus, GUI panels, and web pages). The other environments are suitable for scripting in non-interactive environments as well as providing a scriptable interface to higher-level applications.
What makes this work (particularly the examples where multiple invokcations are necessary) is a global data registration model that provides persistence of state data across multiple invocations. Hence, one can imagine a command-line scenario as follows:
mm
is invoked to get the data requirements for the
initial statemm
to get the list of data requirements for that statemm
again, and
passes in the data that it just collected to fill the
requirementsmm
will then return the requirements for the data
for the next statemm
to get the list of data requirements for that stateMM is currently written in Perl. States must currently be written in Perl, as well. Someday we may expand that such that states can be written in other languages, but there are currently no plans to do so.