|
From: Luan O'C. <lua...@gm...> - 2008-07-18 09:53:33
|
And with Hans Muller's move to Adobe it looks like JSR 296 is dead in the water too. 2008/7/18 Claudio Romano <cla...@li...>: > 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 <ke...@tr...> <mailto:ke...@tr...> >> *To:* spr...@li... >> <mailto:spr...@li...> >> <spr...@li...> >> <mailto:spr...@li...> >> *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" <pet...@gm...> >> <mailto:pet...@gm...> >> *To:* spr...@li... >> <mailto:spr...@li...> >> *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 >> Spr...@li... >> 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 >> Spr...@li... >> 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 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > |