Menu
▾
▴
Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] @Command style
|
From: Kevin D. <ke...@tr...> - 2008-07-18 17:04:21
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>From what I see here, it looks like Fuse is geared towards injection into fields that have been annotated. What I like about the JSR 296 implementation is that these tags are not necessary for the setting of properties on UI components and Actions. It uses convention instead of explicit annotations, and that makes things much cleaner. Interestingly, the ability to inject resources into object fields using explicit tags (which is supported by JSR 296) is the one area that I thought wasn't all that useful. This may be short-sited on my part, but I just don't see myself specifying a color in a resource file and injecting it into an object, but not make that color be exposed as a property of the object.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Now back to my comment about type conversion during resource injection: The JSR 296 approach works fine for Strings. And it has some special String->Object handling for certain types of objects (for example, it can convert a string of form '##RRGGBB' into a Color object). I'm not sure that they have created support for converting the string 'S' from a resource file into a KeyStroke object (which would be required for setting the various *_KEY properties of Action - these properties don't accept simple strings - they need to be KeyStroke objects). I'll have to do some digging into their code to tell for sure.</DIV>
<DIV> </DIV>
<DIV>This isn't that hard to implement, but it would require intelligent parsing (i.e. if the key is of form *.Action.acceleratorKey, then convert the value to KeyStroke prior to setting the value on the Action.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>As I see it, the trick to auto-injection of resource properties is always in determining the object ID. For JComponents, we can use the name property. For actions that are created from annotations, we can create a name or id property on the generated action. For the general case, if the resource injection is the same for all instances of a given class, then an id can be specified in an annotation on the class. For object instances that need to have different resource injection, some form of id/name property will be required - OR the object will need to be registered in such a way that id/name meta data can be associated with the object.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>The bigger design question on all of this is how to get those resources injected automagically. Right now JSR 296 requires explicit injection calls - and the temptation to put those calls directly into the object itself via the Application singleton is high. I've already seen that the Jigloo GUI builder does this. This may be one of those scenarios where whiteboard comes into play:</DIV>
<DIV> </DIV>
<DIV>Create object</DIV>
<DIV>Register the object with the service manager (possibly with an optional name/id property specified???)</DIV>
<DIV>Service manager notifies listeners that an object of class Foo has been registered</DIV>
<DIV>A resource injector service (which set itself up to listen for registration of classes that it should be doing injections for) gets notified, and does it's work</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>There's still the trick of locating the service manager - perhaps a discussion for another post...</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Claudio Romano <A href="mailto:cla...@li..."><FONT color=#0000ff><cla...@li...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Fri, 18 Jul 2008 09:49:50 +0000 (UTC)</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] @Command style</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Tahoma size=2>
<DIV>Kevin Day wrote:<BR>> <BR>> After I wrote this, I did some more research, and I now see that Action <BR>> actually has built in property strings for ACCELERATOR_KEY, <BR>> ACTION_COMMAND_KEY, MNEMONIC_KEY. I don't know that the JSR296 resource <BR>> injector takes care of translating values for this (for example, the <BR>> ACCELERATOR_KEY property needs to be set to an instance of the KeyStroke <BR>> class). It does some types of conversion (colors, for example), but <BR>> maybe not at that level.<BR>> <BR>> <BR><BR>Hi Kevin,<BR><BR>hope i understood you correctly. JSR 296 supports accelerator injected by<BR>resource files: <name>.Action.accelerator=<value> (control O)<BR><BR>this is done in org.jdesktop.application.ApplicationAction that extends<BR>.javax.swing.AbstractAction<BR><BR>Just a little note, i looks like the resource injection in JSR 296 was inspired<BR>by the fuse framework: <BR><BR>- <A href=
"https://fuse.dev.java.net/"><FONT color=#0000ff>https://fuse.dev.java.net/</FONT></A><BR>- <A href="http://www.javalobby.org/articles/swing-fuse/"><FONT color=#0000ff>http://www.javalobby.org/articles/swing-fuse/</FONT></A><BR><BR>In previous post there was the idea to make the anything "resource-injectable"<BR>perhaps with the use of annotations. <BR><BR>Fuse give us really good hints on about it could be achieved:<BR><BR>[Quote from fuse.dev.java.net]<BR><BR>By default, Fuse generates a key to reference each resource and looks up this<BR>key in the resource set. This key uses the following format: ClassName.fieldName<BR>where ClassName is the name of the object's class without the package prefix.<BR>This default behavior might provoke namespace collisions if two of your<BR>components have the same name in different packages. You may also want to map a<BR>resource to a name of your own. To do this, you can use one of the two naming<BR>parameters offered by the @InjectedRes
ource annotation:<BR><BR>* key: Defines the key that maps the resource value in the properties set.<BR>* name: Defines the name used in lieu of the field name to map the resource<BR>value in the properties set.<BR><BR>Here is an example of how to use those two parameters:<BR><BR>class RectangleComponent extends JComponent {<BR> @InjectedResource(key="Common.backgroundColor")<BR> private Color rectColor;<BR> <BR> @InjectedResource(name="text")<BR> private Color textColor;<BR>}<BR><BR>These resources will map to the following entries in the resource file (using<BR>the PropertiesResourceLoader):<BR><BR>Common.backgroundColor=#FF0000<BR>RectangleComponent.text=#00FF00<BR><BR>As you can see, the parameter name affects only the right part of the key name.<BR>If you define both parameters at the same time, only the key parameter will be<BR>taken into account and the name parameter ignored, since the key value also<BR>contains the nam
e in it.<BR><BR>When a property name cannot be found and a key parameter is not declared, Fuse<BR>will try to fall back to a resource named *.id where id is either the field name<BR>or the name parameter. This lets you create global resources very easily:<BR><BR>class RectangleComponent extends JComponent {<BR> @InjectedResource<BR> private Color background;<BR> <BR> @InjectedResource(name="foreground")<BR> private Color foregroundColor;<BR>}<BR><BR>[End of Quote from fuse.dev.java.net]<BR><BR>The support for resources references is also helpfull:<BR>Common.textColor=#000000<BR>TitleComponent.textColor={Common.textColor}<BR><BR>Another nice idea in fuse is to have an interface to encapsulate the loading of<BR>resource properties from within various formats (such as XML, properties, JDBC,<BR>etc...)<BR><BR><BR>It looks like there is pretty much no activity on the fuse project, so I don't<BR>think spring-deskto
p should support and or use fuse_ (We never used it on a real<BR>live project in our company), but the ideas on naming resources ,resources<BR>references and resource loaders are quite nice.<BR><BR>hope it helps <BR><BR>_<BR>Claudio<BR><BR><BR><BR>> <BR>> The javax.swing.text.KeyMap class is what takes care of mapping actual <BR>> keystrokes to actions - it appears that they do *not* translate between <BR>> keystrokes and actionmap entry names (I implied otherwise in my post <BR>> below). They map directly between keystrokes and actions. And the <BR>> KeyMap is generally held by a container object. Oh yes, and KeyMaps can <BR>> chain up the component hierarchy, delegating to parent containers, <BR>> etc... as necessary.<BR>> <BR>> The Action's property (for MNEMONIC_KEY, for example) is a bound <BR>> property, so when it changes, it fires a change into the ButtonModel. <BR>> The ButtonModel has a similar
property, which is bound to the parent <BR>> container when the button is added to the parent. So the parent <BR>> maintains the KeyMap, and it can respond to changes in the properties of <BR>> the Action by re-arranging the KeyMap when property change events are fired.<BR>> <BR>> <BR>> So this raises an interesting question in my mind: It seems like Swing <BR>> has done a huge amount of the heavy lifting here - and AbstractAction <BR>> has pretty much all of the functionality that is being discussed. Is it <BR>> just a matter of extending the resource injection to support these <BR>> additional properties, or is there something about Swing's approach that <BR>> is lacking?<BR>> <BR>> - K<BR>> <BR>> ----------------------- *Original Message* -----------------------<BR>> <BR>> *From:* Kevin Day <A href="mailto:ke...@tr..."><FONT color=#0000ff><kevin@trumpetinc
.com></FONT></A> <A href="mailto:ke...@tr..."><FONT color=#0000ff><mailto:ke...@tr...></FONT></A><BR>> *To:* <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A> <BR>> <A href="mailto:spr...@li..."><FONT color=#0000ff><mailto:spr...@li...></FONT></A> <BR>> <A href="mailto:spr...@li..."><FONT color=#0000ff><spr...@li...></FONT></A> <BR>> <A href="mailto:spr...@li..."><FONT color=#0000ff><mailto:spr...@li...></FONT></A><BR>> *Cc:* <BR>> *Date:* Thu, 17 Jul 2008 13:53:48 -0700<BR>> *Subject: Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] <BR>> @Command style *<BR>> <BR>> One thing that may not be immediatel
y evident about the Action class is <BR>> that it supports any arbtrary 'property' via putValue(). So you can use <BR>> the Action object as is to add any extra properties.<BR>> <BR>> <BR>> One approach to consider: In JSR 296, the prefered way of setting a <BR>> label and msemonic for an action would be via resource injection, <BR>> instead of hard coding those values into the source. The resource file <BR>> contains entries with the following convention:<BR>> <BR>> <name>.Action.<propertyname>=<value><BR>> <BR>> So, there would be:<BR>> <BR>> save.Action.label=Save<BR>> save.Action.mnemonic=S<BR>> <BR>> <BR>> This opens the possibility for I18N. I could see where having those <BR>> properties in the annotation itself would be useful for someone doing <BR>> quick and dirty work where messing with resource files isn't desirable.<BR>&
gt; <BR>> <BR>> Finally, I know that most Swing components already have keyboard <BR>> accelerator support - I haven't done enough with that to comment on <BR>> whether their approach is good or not - but it is something that's <BR>> already there. I believe that they build a map between accelerators and <BR>> actionmap entry names - so the accelerator looks up the *name* of the <BR>> action. Then they look the actual action up in the actionmap of the <BR>> container and invoke it. This decouples the accelerator implementation <BR>> from the action implementation (separation of concerns and all). <BR>> The advantage of that separation is that it sets the stage for user <BR>> defined keyboard mappings, etc... It would be hard to achieve that if <BR>> the accelerator is associated directly with the action (at least without <BR>> a lot of close coupling).<BR>> <BR>> - K <BR>> <
BR>> ----------------------- *Original Message* -----------------------<BR>> <BR>> *From:* "Peter De Bruycker" <A href="mailto:pet...@gm..."><FONT color=#0000ff><pet...@gm...></FONT></A> <BR>> <A href="mailto:pet...@gm..."><FONT color=#0000ff><mailto:pet...@gm...></FONT></A><BR>> *To:* <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A> <BR>> <A href="mailto:spr...@li..."><FONT color=#0000ff><mailto:spr...@li...></FONT></A><BR>> *Cc:* <BR>> *Date:* Thu, 17 Jul 2008 20:12:39 +0200<BR>> *Subject: Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] <BR>> @Command style *<BR>> <BR>> <BR>> <BR>> <BR>> Great idea, I'll update my code to reflect this. In addition to
being <BR>> compatible, we also have extra functionality: labels containing mnemonic <BR>> info and accelerator info <A href="mailto:&Save@Ctrl-S"><FONT color=#0000ff>(&Save@Ctrl-S</FONT></A> => label = Save, mnemonic=S, <BR>> accelerator = Ctrl-S)<BR>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> -------------------------------------------------------------------------<BR>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<BR>> Build the coolest Linux based applications with Moblin SDK & win great <BR>> prizes<BR>> Grand prize is a trip for two to an Open Source event anywhere in the world<BR>> <A href="http://moblin-contest.org/redirect.php?banner_id=100&url=/"><FONT color=#0000ff>http://moblin-contest.org/redirect.php?banner_id=100&url=/</FONT></A><BR>> <BR>> _______________________________________________<BR>> Springframework-rcp-dev m
ailing list<BR>> <A href="mailto:Spr...@li..."><FONT color=#0000ff>Spr...@li...</FONT></A><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev</FONT></A><BR>> <BR>> <BR>> <BR>> ------------------------------------------------------------------------<BR>> <BR>> -------------------------------------------------------------------------<BR>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<BR>> Build the coolest Linux based applications with Moblin SDK & win great prizes<BR>> Grand prize is a trip for two to an Open Source event anywhere in the world<BR>> <A href="http://moblin-contest.org/redirect.php?banner_id=100&url=/"><FONT color=#0000ff>http://moblin-contest.org/redirect.php?banner_id=100&url=/</FONT></A><BR>> <
BR>> <BR>> ------------------------------------------------------------------------<BR>> <BR>> _______________________________________________<BR>> Springframework-rcp-dev mailing list<BR>> <A href="mailto:Spr...@li..."><FONT color=#0000ff>Spr...@li...</FONT></A><BR>> <A href="https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev</FONT></A><BR><BR><BR><BR><BR>-------------------------------------------------------------------------<BR>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge<BR>Build the coolest Linux based applications with Moblin SDK & win great prizes<BR>Grand prize is a trip for two to an Open Source event anywhere in the world<BR><A href="http://moblin-contest.org/redirect.php?banner_id=100&url=/"><FONT color=#0000ff>http://moblin-contest
.org/redirect.php?banner_id=100&url=/</FONT></A><BR>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR><A href="mailto:Spr...@li..."><FONT color=#0000ff>Spr...@li...</FONT></A><BR><A href="https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev</FONT></A><BR><BR></DIV></FONT></BODY></HTML>
|
