Introducing JavaStates - a new API for state based GUI development in Swing

Question

JavaStates partially implements the semantics of D Harel' statecharts.
It is currently hosted as source forge project:
[https://sourceforge.net/projects/javastates/]
, and has been used for several years for teaching Java Swing and the specification of man machine interfaces at ESIL
[http://www.esil.univmed.fr]
[http://laurent.henocque.com]
The project provides several demos, including a full fledged swing text editor, and is stable.
Details can be found here too:
[http://javastates.posterous.com/]
I'd be very happy to interact with both experts and users.
I claim that Javastates tremendously improve the quality and speed of GUI development.
Do you agree?
Edited by: lhenocque on Mar 4, 2010 4:18 AM

Answer 1

Thanks for the good practise hint, and many more thanks for your interest.
I haven't tried anything but don't you get an explosion of states?
explosion of states is controlled by concurrent regions. Two states in two concurrent regions can be active at the same time.
There can be no 'explosion' anyway since the states are programmer declared. The list is finite, and under control.
For example the program I'm working on has a table and actions are enabled based on:
-no selection/single selection/multi selection
-top/bottom row selected (move up/down action)
-user read/write permission
-properties of the object of the selected row
The situation you describe is handled by (at least) four concurrent regions.
The typical error is usually forgetting a particular one which result in action being enabled/disabled when the shouldn't. Currently solving that by having a callback method which enables all the action correctly and gets called whenever there is a selection/security/etc update.
Javastates cares for both setting the properties of the states (including the callbacks to fire) and for the cleanup. Using this allows for defect free interfaces in the sense that nothing can be left over.
Using Javastates helps you to separate your logic in the same way as object programming with virtual functions does. You should end up replacing a code with many if/thens by separate listeners, dynamically set by callbacks.
Also fluent interface method chaining is nice until it becomes a flood in my opinion - similar to how GroupLayout is better handled by Matisse GUI builder than by hand, JavaStates might benefit more from a graphical tool.
You are right. Both apis exist. The fluent api is provided for simplicity, since it prevents from declaring useless local variables.
Also for a GUI builder. I created the foundation of Javastates for an interpreted language called WIZ in the IDE Openside around 1990 (that was in C).
Then later I implemented a subset of the current Java features in C++, that were interfaced in the GUI Builder called ILOG Views.
So yes I agree a GUI can help, but anyway the Java code resulting from using states is mare more concise and structured than it would otherwise.