[jsword-devel] i18n and Actions

[Joe Walker]

DM Smith wrote:
> The advantage I see with Actions is that an Action is an abstraction of 
> the behavior that an application needs to perform regardless of how it 
> is presented to the user. Further a single behavior can have multiple, 
> visible representations (menu item, button, check box, radio button, and 
> even multiple menu locations)

Also (although less importantly) they can be re-used between situations. 
The config stuff is able to supply any app with a "Tools->options" menu 
action ready for use.

> The problem with putting behavior in Actions is that when a button is 
> pressed perhaps several different objects need to act to do different, 
> independent things.

Agreed, Some of the hassle in Desktop is getting cut/copy/paste and 
various other options to know which part of the app they should be 
copying from.

> The other basic problem is that it is hard to manage 
> internationalization of actions. The first problem is the representation 
> of an action in a properties file is all strings, but these need to be 
> converted into Icon, boolean, Integer and KeyStroke. This can be done in 
> a base class using getClass().getName() for the lookup mechanism. The 
> second problem is that for a robust application that has a couple dozen 
> (e.g. 24) actions and is targeted initially to 5 locales that there will 
> need to be over 120 properties files.

> A simpler solution to the property files is to create an ActionFactory. 
> The ActionFactory property file holds the properties for all actions 
> that it creates. Now there are only 5 property files for the actions. 
> This seems to be much better to me.

> But the drawback is that the Actions now don't have behavior. This can 
> be solved in several ways, but perhaps the simplest is for 
> ActionListeners implement the behavior. This can be in separate Behavior 
> classes or as in Andy's example, a single class that interogates the 
> ActionEvent and responds to it appropriately. It really does not matter 
> to me which of these two approaches are taken.

The pros and cons that I can think of:
methods
- leaner
- so classloads faster
action listeners
- reusable
- less monolithic
- can be moved to more appropriate package

> I am working on an ActionFactory which can be subclassed to provide 
> different collections of actions. I am almost done with it, since I have 
> done it before. Joe, you can decide if you wish to use it. I think you 
> will like it.

Sounds interesting, thanks.

Joe.