Re: [spring-desktop] Re: [Desktop] @Command style

After I wrote this, I did some more research, and I now see that Action actually has built in property strings for ACCELERATOR_KEY, ACTION_COMMAND_KEY, MNEMONIC_KEY.  I don't know that the JSR296 resource injector takes care of translating values for this (for example, the ACCELERATOR_KEY property needs to be set to an instance of the KeyStroke class).  It does some types of conversion (colors, for example), but maybe not at that level.

 

 

 

The javax.swing.text.KeyMap class is what takes care of mapping actual keystrokes to actions - it appears that they do *not* translate between keystrokes and actionmap entry names (I implied otherwise in my post below).  They map directly between keystrokes and actions.  And the KeyMap is generally held by a container object.  Oh yes, and KeyMaps can chain up the component hierarchy, delegating to parent containers, etc... as necessary.

 

The Action's property (for MNEMONIC_KEY, for example) is a bound property, so when it changes, it fires a change into the ButtonModel.  The ButtonModel has a similar property, which is bound to the parent container when the button is added to the parent.  So the parent maintains the KeyMap, and it can respond to changes in the properties of the Action by re-arranging the KeyMap when property change events are fired.

 

 

So this raises an interesting question in my mind:  It seems like Swing has done a huge amount of the heavy lifting here - and AbstractAction has pretty much all of the functionality that is being discussed.  Is it just a matter of extending the resource injection to support these additional properties, or is there something about Swing's approach that is lacking?

 

- K

 

One thing that may not be immediately evident about the Action class is that it supports any arbtrary 'property' via putValue().  So you can use the Action object as is to add any extra properties.

 

 

One approach to consider:  In JSR 296, the prefered way of setting a label and msemonic for an action would be via resource injection, instead of hard coding those values into the source.  The resource file contains entries with the following convention:

 

<name>.Action.<propertyname>=<value>

 

So, there would be:

 

save.Action.label=Save

save.Action.mnemonic=S

 

 

This opens the possibility for I18N.  I could see where having those properties in the annotation itself would be useful for someone doing quick and dirty work where messing with resource files isn't desirable.

 

 

Finally, I know that most Swing components already have keyboard accelerator support - I haven't done enough with that to comment on whether their approach is good or not - but it is something that's already there.  I believe that they build a map between accelerators and actionmap entry names - so the accelerator looks up the *name* of the action.  Then they look the actual action up in the actionmap of the container and invoke it.  This decouples the accelerator implementation from the action implementation (separation of concerns and all).  The advantage of that separation is that it sets the stage for user defined keyboard mappings, etc...  It would be hard to achieve that if the accelerator is associated directly with the action (at least without a lot of close coupling).

 

- K 

 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev