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

> Kevin Day wrote:
>>
>> 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.
>>
>>
>
> Hi Kevin,
>
> hope i understood you correctly. JSR 296 supports accelerator injected by
> resource files: <name>.Action.accelerator=<value> (control O)
>
> this is done in org.jdesktop.application.ApplicationAction that extends
> .javax.swing.AbstractAction
>
> Just a little note, i looks like the resource injection in JSR 296 was inspired
> by the fuse framework:
>
> - https://fuse.dev.java.net/
> - http://www.javalobby.org/articles/swing-fuse/
>
> In previous post there was the idea to make the anything "resource-injectable"
> perhaps with the use of annotations.
>
> Fuse give us really good hints on about it could be achieved:
>
> [Quote from fuse.dev.java.net]
>
> By default, Fuse generates a key to reference each resource and looks up this
> key in the resource set. This key uses the following format: ClassName.fieldName
> where ClassName is the name of the object's class without the package prefix.
> This default behavior might provoke namespace collisions if two of your
> components have the same name in different packages. You may also want to map a
> resource to a name of your own. To do this, you can use one of the two naming
> parameters offered by the @InjectedResource  annotation:
>
> * key: Defines the key that maps the resource value in the properties set.
> * name: Defines the name used in lieu of the field name to map the resource
> value in the properties set.
>
> Here is an example of how to use those two parameters:
>
> class RectangleComponent extends JComponent {
>  @InjectedResource(key="Common.backgroundColor")
>  private Color rectColor;
>
>  @InjectedResource(name="text")
>  private Color textColor;
> }
>
> These resources will map to the following entries in the resource file (using
> the PropertiesResourceLoader):
>
>  Common.backgroundColor=#FF0000
>  RectangleComponent.text=#00FF00
>
> As you can see, the parameter name affects only the right part of the key name.
> If you define both parameters at the same time, only the key parameter will be
> taken into account and the name parameter ignored, since the key value also
> contains the name in it.
>
> When a property name cannot be found and a key parameter is not declared, Fuse
> will try to fall back to a resource named *.id where id is either the field name
> or the name parameter. This lets you create global resources very easily:
>
> class RectangleComponent extends JComponent {
>  @InjectedResource
>  private Color background;
>
>  @InjectedResource(name="foreground")
>  private Color foregroundColor;
> }
>
> [End of Quote from fuse.dev.java.net]
>
> The support for resources references is also helpfull:
>  Common.textColor=#000000
>  TitleComponent.textColor={Common.textColor}
>
> Another nice idea in fuse is to have an interface to encapsulate the loading of
> resource properties from within various formats (such as XML, properties, JDBC,
> etc...)
>
>
> It looks like there is pretty much no activity on the fuse project, so I don't
> think spring-desktop should support and or use fuse_ (We never used it on a real
> live project in our company), but the ideas on naming resources ,resources
> references and resource loaders are quite nice.
>
> hope it helps
>
> _
> Claudio
>
>
>
>>
>> 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
>>
>> ----------------------- *Original Message* -----------------------
>>
>> *From:* Kevin Day <kevin@...> <mailto:kevin@...>
>> *To:*  springframework-rcp-dev-request@...
>> <mailto:springframework-rcp-dev-request@...>
>> <springframework-rcp-dev@...>
>> <mailto:springframework-rcp-dev@...>
>> *Cc:*
>> *Date:* Thu, 17 Jul 2008 13:53:48 -0700
>> *Subject:  Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop]
>> @Command style *
>>
>> 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
>>
>> ----------------------- *Original Message* -----------------------
>>
>> *From:* "Peter De Bruycker" <peter.de.bruycker@...>
>> <mailto:peter.de.bruycker@...>
>> *To:*  springframework-rcp-dev@...
>> <mailto:springframework-rcp-dev@...>
>> *Cc:*
>> *Date:* Thu, 17 Jul 2008 20:12:39 +0200
>> *Subject:  Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop]
>> @Command style *
>>
>>
>>
>>
>> Great idea, I'll update my code to reflect this. In addition to being
>> compatible, we also have extra functionality: labels containing mnemonic
>> info and accelerator info (&Save@Ctrl-S => label = Save, mnemonic=S,
>> accelerator = Ctrl-S)
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>
>
>
>
> -------------------------------------------------------------------------
> 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
>