On Jan 6, 2009, at 2:54 AM, Karsten Lentzsch wrote:

Karsten,

I've been setting up a lot of Actions and have thought up a simpler implementation than this that still provides the same level of flexibility.

Instead of having this in the properties file:

Preferences.Action.text=${Preferences.Action.text.[$os]} Preferences.Action.text.default=Preferences... Preferences.Action.text.win=&Options Preferences.Action.accelerator=${Preferences.Action.accelerator.[$os]} Preferences.Action.accelerator.default=${null} Preferences.Action.accelerator.mac=command COMMA

I can reduce it to :

Preferences.Action.text=Preferences... Preferences.Action.text.win=&Options Preferences.Action.accelerator.mac=command COMMA

The way this would work is, first, the "os" variable, (the same one as you currently use) can be both set/retrieved explicitly , as well as automatically initialized by the framework. Next, the framework already "knows" about the common values this variable can take on (e.g., "mac", "win", "solaris", etc.

By allowing it to be explicitly set, you provide the ability to expand the framework in case a user has some particular variation not initially thought of.

But the real difference comes in the implementation of the Action property injector. This would now use the concept of "the most specific platform attribute". So in the case of say the "text" property, if the application is running on the Windows platform, the value of Preferences.Action.text.win is used. On all other platforms, the value of Preferences.Action.text would be used.

Now say we run the same app on Mac OS. Since there is no specific "Preferences.Action.text.mac" property specified, the "Preferences.Action.text" property is used. Thus overriding properties for specific platforms becomes just a matter of providing for that specific value. That avoids having to have a "default" variant; the default would be just the base attribute (Preferences.Action.text), and a more specific variant is used only when such a variant is specified AND running on that platform.

Note there is no "Preferences.Action.accelerator" property specified. Thus, there is no default accelerator for this Action, so on most platforms there would not be an accelerator associated with this Action. But, on the Mac, this action would get the command-COMMA accelerator.

Also note, "command" would be synonymous with "meta", and it's trivially easy to add this functionality. Mac developers are so used to working with "command" key, and not so much "meta", that seems more natural. Of course, this could be written as "meta COMMA" and produce the exact same result.

I really think you should consider this approach, because after having defined 30 Actions now using your notation, my properties files seem very cluttered with a lot of boilerplate "scripting" , whereas the approach I'm suggesting seems a lot more streamlined and easier to read.

Let me know what you think!