Wouldn't it be more appropriate to reword this "mission statement" to
say "Java Swing GUI layout" then? I mean, a GUI without behavior is
just a G. There's no UI. It seems to me that Swixml has caused a lot
of confusion among users because it claims to be a GUI generation
language, but all it does is layout.
Might it also make sense for those that are interested to make a second
project that is intended to work *with* SWIXML layout files to add GUI
behaviors? Swixml wouldn't have to change *one bit*. It can remain
completely focused. Those that want a binding language (to connect
widgets to existing classes/objects), or a scripting language (for
business logic & behaviors), or sensitivity settings for widgets (as
proposed by the original author of this thread), could use this new
format, should we choose to build it? There really is no inherent
conflict between Swixml and using other technologies for
scripting/binding/gui behavior. After all, Swixml is just a Swing GUI
layout definition language.
-dan
Wolf Paulus wrote:
At this point I would rather not put event definitions into the
XML-descriptors. Like pointed out on the swixml.org site:
"SWIXML does Java Swing GUI generation and that is all. The dynamic behavior
of the user interface, defining the application's business rules, has to be
coded in Java."
