Thanks to a “post(Swing Action Architecture)”:http://jroller.com/page/bhagvank/20040222#swing_action_architecture over at Bhagvan K’s blog, I found a link to an article covering an “action architecture for Swing(An Easy Architecture for Managing Actions)”:http://www.javadesktop.org/articles/actions/index.html. Of special interest to me is that fact that the code defines an XML format for storing action information:
It also defines groups of actions, for example for use on a menu:
SwingCommandFactory needs to be able to load this kind of information – the
id of the actions will probably resolve to the names of the XWork defined actions (I am unsure how/if to handle xwork namespaces as yet). Assuming the code is opensource, I might use the XML format and parsing code for my framework – although I’d like to combine this kind of configuration with
xwork.xml, it will at least be a good stop gap solution.
9 Responses to “Swing Action configuration goodness”
WHY would you want to use XML for this? No only do you loose strong typing, but you’ll also have to work to keep the XML file synchronized with the Java classes.
Firstly, for internationalisation issues. The names of actions will change from language to language – as will things such as keyboard mnemonics and keyboard shortcuts (what if a keyboard map is different). Secondly, flexibility. Users with different roles for example might get different config files which hide those actions it makes no sense to give them (e.g. hide admin options from non-admin users). It also lets you customise an interface to a users own requirements – you can allow them to change their keyboard shortcuts, position on menus etc., the result of which will be a user specific xml file stored in their profile.
I’d admit you loose complie-time checking capabilities, but here I think its a justified tradeoff.
I think your different roles / functions are the answer to how to use XWork namespaces… We use them in WebWork to map paths, which can be used for declarative security.
Do you have to configure your actions multiple times under each namespace?
I use standard .properties files for this same stuff. Then just use ResourceBundle to locate the locale-appropriate .properties file. Using XML here is way overkill.
It’s always surprised me that Swing doesn’t have built in support for ResourceBundles. Making every developer create their own i18n solution is just wrong.
I’m not sure I agree. I’m not just setting the display name of the action here – I’m also defining an icon, keyboard shortcut, mnemonic, and logical grouping (e.g. menu x has these actions). You can do all that with property files? Property files work greate for flat simple string data – but for more compelx datatypes and hirearchical structure, XML is a better choice IMHO.
Doing all this with property files is doable (and perhaps more readable), but the handling should take care of rebuilding a tree. I’ve a project from 1999 which does this. Here is a sample of one of the property files :
# Toolbar définition
toolbar= rt – il routage
rtTooltip=Modifie le routage
routageTooltip=Ajouter une gamme
# Statusbar definition
statebar=un deux trois quatre cinq six sept
# Actions behaviour
modifiers= creer efface_mac
creerTooltip=Créer une machine
creerNec=RIEN NO_MAC NO_FLUX
creerNecAide=RIEN NO_MAC NO_FLUX
efface_macTooltip=Effacer la machine
efface_macNec=RIEN DROIT CTRL
The last section is conditions for an Action to be applicable, described as a set of necessary (Nec) conditions, and a set of vetoed conditions (Rej). Conditions refer to the UI (CTRL, DROIT refer to the mouse) or to the domain model (NO_MAC, NO_FLUX, RIEN).
More readable? Perhaps, but you are displaying fundamentally hirearchical data in a flat format. A nice compomise might be to use something like YAML (http://www.yaml.org/), which I would consider if there was a mature parser out there. YAML looks like this:
date : 2001-01-23
given : Chris
family : Dumars
458 Walkman Dr.
city : Royal Oak
state : MI
postal : 48046
Whitespace is used to define grouping as opposed to wrapping everything with tags.
We lose the hierarchical vision with a flat format, but compared with XML as a (twisted) tree-model, there’s less fluff. And the structure for a menu is generally 2-levels deep at most. In 1999, YAML didn’t exist, but it’s interesting to see a specification for this.