[jsword-devel] i18n and Actions

[DM Smith]

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)

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.

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.

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.

Joe Walker wrote:
>
>Hi Andy,
>
>I think the biggest difference between our coding styles is that you prefer 
>a minimalist approach, but my approach aims to be more generic.
>
>The reason I tend toward a more generic approach is that usually you can 
>turn a generic but slow solution into a faster minimalist solution, but it 
>is harder to generalize a highly tuned minimalist solution, however I can 
>understand that this approach is frustrating for developers that need to 
>get at the more minimalist approach during development.
>
>The 2 examples in your mail (Actions and I18N) both fit into this pattern. 
>We can easily run some eclpise refactorings or ant macros across the JSword 
>source to convert the generic Msg i18n solution into a minimalist String 
>based i18n solution, but the reverse is not possible. Similar arguments 
>work for JSwordGUI vs. Desktop.
>
>There are plenty of things we can do to make JSword faster, but for me 
>making it function properly is more important right now so my vote is to 
>continue to be generalist until the cries of "xyz is too slow for me" drown 
>out the cries of "xyz doesn't work".
>
>Sorry to be a stick-in-the-mud.
>
>Joe.
>
>Aleksander Rozman - Andy wrote:
>
>>At 2.4.2004, you wrote:
>>
>...
>>
>>I have already told that this way of creating Actions is not good... When 
>>you create application you should use as little as possible action 
>>classes, but instead implement one ActionListener for more actions. Here 
>>is sample how I did it (I started makeing changes on JSword some time 
>>ago). Also included is my file for I18N..., which is used by this class.
>>
>>I also mentioned about I18N, but I couldn't convince the boss that my way 
>>is better even if it's used by almost all other java programmers...
>>
>>Andy
>
>
>_______________________________________________
>jsword-devel mailing list
>jsword-devel@crosswire.org
>http://www.crosswire.org/mailman/listinfo/jsword-devel

_________________________________________________________________
Check out MSN PC Safety & Security to help ensure your PC is protected and 
safe. http://specials.msn.com/msn/security.asp