Menu
▾
▴
springframework-rcp-dev — Spring Rich Client developer list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(37) |
Jun
(141) |
Jul
(111) |
Aug
(91) |
Sep
(79) |
Oct
(151) |
Nov
(161) |
Dec
(93) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(40) |
Feb
(60) |
Mar
(43) |
Apr
(90) |
May
(31) |
Jun
(114) |
Jul
(35) |
Aug
(112) |
Sep
(305) |
Oct
(151) |
Nov
(122) |
Dec
(103) |
| 2006 |
Jan
(65) |
Feb
(57) |
Mar
(475) |
Apr
(276) |
May
(482) |
Jun
(134) |
Jul
(127) |
Aug
(188) |
Sep
(271) |
Oct
(220) |
Nov
(74) |
Dec
(41) |
| 2007 |
Jan
(121) |
Feb
(50) |
Mar
(36) |
Apr
(11) |
May
(31) |
Jun
(12) |
Jul
(73) |
Aug
(41) |
Sep
(59) |
Oct
(33) |
Nov
(60) |
Dec
(111) |
| 2008 |
Jan
(139) |
Feb
(49) |
Mar
(87) |
Apr
(43) |
May
(10) |
Jun
(25) |
Jul
(114) |
Aug
(17) |
Sep
(25) |
Oct
(199) |
Nov
(94) |
Dec
(45) |
| 2009 |
Jan
(36) |
Feb
(14) |
Mar
(29) |
Apr
(32) |
May
(49) |
Jun
(18) |
Jul
(68) |
Aug
(34) |
Sep
(34) |
Oct
(11) |
Nov
(10) |
Dec
(14) |
| 2010 |
Jan
(35) |
Feb
(12) |
Mar
(23) |
Apr
(17) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
(10) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(8) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
(5) |
Jun
(1) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(15) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Kevin D. <ke...@tr...> - 2008-07-18 19:23:44
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1> <DIV dir=ltr>Comments below with my initials. My lack of deep experience with Spring is probably making me bring up points that I shouldn't be - my apologies! Hopefully there's some wheat in the chaffe.</DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="MARGIN-RIGHT: 0px"> <DIV><BR>We can do this using PropertyEditors (the conversion mechanism used by Spring). That way you can auto inject icons/images/text/..., in fact anything that can be translated by a registered PropertyEditor.</DIV></BLOCKQUOTE> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>KD - very nice. Sounds like it's just the thing.<BR> </DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><FONT face=Arial size=2> <DIV></DIV> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <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></BLOCKQUOTE></FONT></BLOCKQUOTE> <BLOCKQUOTE class=gmail_quote dir=ltr style="MARGIN-RIGHT: 0px"> <DIV><BR>When your object is a spring managed bean, it has a name, so that can be used.<BR></DIV></BLOCKQUOTE> <DIV class=gmail_quote dir=ltr>KD - I was thinking along these lines as well. The meta data is associated with the object by spring. </DIV> <DIV class=gmail_quote dir=ltr> </DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><FONT face=Arial size=2> <DIV></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></FONT></BLOCKQUOTE> <DIV class=gmail_quote dir=ltr><BR> If we create a custom BeanPostProcessor, then the injection can be triggered from there. This would handle all spring managed beans (views, actions, ...)<BR><BR> for all other cases, the resource injection will have to be called manually.</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr> <DIV class=gmail_quote dir=ltr>KD : I'm thinking about situations where a newly created object could be registered with the framework ( as opposed to having the framework create the object in the first place). It's something of a middle ground between the pure spring IOC approach (i.e. do not expose the framework at *all* into the application) and the current rcp approach (which has lots of artificial dependencies exposed via the Application singleton).</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>Instead of requiring manual resource injection (and manual selectionProvider injection, and manual XXX injection, etc...), the whiteboard pattern (more on that below) suggests reversing the problem by having the object get generically registered once. Then have registration listeners take care of processing the object as they need to.</DIV><BR> </DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV><FONT face=Arial size=2> <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></FONT></DIV></BLOCKQUOTE> <DIV class=gmail_quote dir=ltr><BR> What do you mean by "Service manager"?</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>KD: This is a part of the whiteboard pattern - using a centralized object registration system that provides a listener interface so that other objects can learn about objects as they are registered and deregistered. This is something like the BeanPostProcessor - but allows for dynamic processing of objects. My understanding is that BeanPostProcessor is targeted at *configuration* of a given object soon after it is constructed by the Spring framework. The whiteboard approach would treat configuration of the object as just one of many services that might be interested in a newly registered object.</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>One service may do resource injection (which is just part of initial configuration, and could be done with bean post processing - but why not just have the post processor register the bean with the service manager and be done with it?).</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>Another service could do action injection into views (this opens the possibility of dynamically creating a view in code instead of having to use a named object specified in an external configuration file). This could be done using BeanPostProcessor. Although how do we handle situations where we want several views of the same class, but each having different actionmaps and/or beans associated with them? Maybe a bean editor view where the user is able to open up dialogs for each of 5 or 10 or 15 beans that they've selected...</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>Another service may track current global selection by listening for registration of objects that expose a 'selectionProvider' interface. This is outside the scope of initial configuration, altogether.</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>This starts to create a situation where Spring IOC is used primarily for configuring the registration listeners, then registering objects that are initially created by the framework. But it does not preclude the possibility of new objects being created and registered (and unregistered), and manual creation (and removal) of registration listeners as the application runs.</DIV> <DIV class=gmail_quote dir=ltr><BR> </DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV><FONT face=Arial size=2> <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 class=Ih2E3d> <DIV><FONT face=Tahoma size=2><BR><BR> </DIV></DIV></DIV></DIV></BLOCKQUOTE></FONT></BODY></HTML> |
|
From: Peter De B. <pet...@gm...> - 2008-07-18 18:31:37
|
On Fri, Jul 18, 2008 at 7:04 PM, Kevin Day <ke...@tr...> wrote: > 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. > > > 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. > > 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. > > We can do this using PropertyEditors (the conversion mechanism used by Spring). That way you can auto inject icons/images/text/..., in fact anything that can be translated by a registered PropertyEditor. > > 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. > When your object is a spring managed bean, it has a name, so that can be used. > > > 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: > > If we create a custom BeanPostProcessor, then the injection can be triggered from there. This would handle all spring managed beans (views, actions, ...) for all other cases, the resource injection will have to be called manually. > Create object > Register the object with the service manager (possibly with an > optional name/id property specified???) > Service manager notifies listeners that an object of class Foo has been > registered > 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 > > What do you mean by "Service manager"? > There's still the trick of locating the service manager - perhaps a > discussion for another post... > > - K > > ----------------------- *Original Message* ----------------------- > > *From:* Claudio Romano <cla...@li...><cla...@li...> > *To:* spr...@li... > *Cc:* > *Date:* Fri, 18 Jul 2008 09:49:50 +0000 (UTC) > *Subject: Re: [Springframework-rcp-dev] [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 @InjectedRes ource 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 nam e 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-deskto p 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@trumpetinc .com> <ke...@tr...> > <mailto:ke...@tr...> <ke...@tr...> > > *To:* spr...@li... > > <mailto:spr...@li...><spr...@li...> > > <spr...@li...><spr...@li...> > > <mailto:spr...@li...><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 immediatel y 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. > & gt; > > > > 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 > > < BR>> ----------------------- *Original Message* > ----------------------- > > > > *From:* "Peter De Bruycker" <pet...@gm...><pet...@gm...> > > <mailto:pet...@gm...> <pet...@gm...> > > *To:* spr...@li... > > <mailto:spr...@li...><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 <&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 m ailing 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=/ > > < BR>> > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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=/<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 > > |
|
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>
|
|
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 > |
|
From: Claudio R. <cla...@li...> - 2008-07-18 09:50:10
|
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 |
|
From: Kevin D. <ke...@tr...> - 2008-07-17 21:28:30
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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?</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> Kevin Day <A href="mailto:ke...@tr..."><FONT color=#0000ff><ke...@tr...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A> <A href="mailto:spr...@li..."><FONT color=#0000ff><spr...@li...></FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Thu, 17 Jul 2008 13:53:48 -0700</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] @Command style</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Arial size=2>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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:</DIV>
<DIV> </DIV>
<DIV><name>.Action.<propertyname>=<value></DIV>
<DIV> </DIV>
<DIV>So, there would be:</DIV>
<DIV> </DIV>
<DIV>save.Action.label=Save</DIV>
<DIV>save.Action.mnemonic=S</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>- K </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> "Peter De Bruycker" <A href="mailto:pet...@gm..."><FONT color=#0000ff><pet...@gm...></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> Thu, 17 Jul 2008 20:12:39 +0200</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] @Command style</U></B></DIV>
<DIV> </DIV></DIV>
<DIV dir=ltr><BR><BR>
<DIV class=gmail_quote>
<DIV><BR>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)<BR><BR> </DIV>
<BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV><FONT face=Arial size=2>
<DIV></DIV>
<DIV></FONT><FONT face=Tahoma size=2><BR> </DIV></DIV></BLOCKQUOTE></DIV></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>-------------------------------------------------------------------------<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>http://moblin-contest.org/redirect.php?banner_id=100&url=/<BR><BR></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Kevin D. <ke...@tr...> - 2008-07-17 20:53:59
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2> <DIV>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.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>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:</DIV> <DIV> </DIV> <DIV><name>.Action.<propertyname>=<value></DIV> <DIV> </DIV> <DIV>So, there would be:</DIV> <DIV> </DIV> <DIV>save.Action.label=Save</DIV> <DIV>save.Action.mnemonic=S</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>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).</DIV> <DIV> </DIV> <DIV>- K </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> "Peter De Bruycker" <A href="mailto:pet...@gm..."><FONT color=#0000ff><pet...@gm...></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> Thu, 17 Jul 2008 20:12:39 +0200</DIV> <DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] @Command style</U></B></DIV> <DIV> </DIV></DIV> <DIV dir=ltr><BR><BR> <DIV class=gmail_quote> <DIV><BR>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)<BR><BR> </DIV> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV><FONT face=Arial size=2> <DIV></DIV> <DIV></FONT><FONT face=Tahoma size=2><BR> </DIV></DIV></BLOCKQUOTE></DIV></DIV></FONT></BODY></HTML> |
|
From: Peter De B. <pet...@gm...> - 2008-07-17 18:12:44
|
On Thu, Jul 17, 2008 at 7:10 PM, Kevin Day <ke...@tr...> wrote: > Here are my thoughts on jsr 296: > > 1. The @action annotation is extremely convenient > Indeed! This is definitely the road we need to take: we need to make it extremely convenient for developers to create feature rich desktop applications. > 2. Resource injection from properties files (both for control properties, > and Action properties) is convenient > This is what I'm working on now. Anything is "resource-injectable", as long as the correct interfaces are implemented. Perhaps we can try to apply annotations in this domain also? > 3. Their approach to long running tasks is a good start - although I'm not > sure that the JSR 296 implementation is as feature rich as it should be (for > example, how do we make sure that tasks can get registered with a monitoring > sub-system?) > > The centralized caching mechanisms and singletons are not at all good (but > the jsr 296 implementation doesn't force you to actually use those > singletons - you can create the injectors individually). > > > I think that it is desirable to make Spring-Desktop be *compatible* with > the JSR 296 approach to resource injection (i.e. use the same properties > file, naming convention and file locations) so that users of 296 will find > it easier to transition. > > 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) > I'm a bit less certain of the importance of compatability on the @action > annotation side of things (i.e. using the same annotation tags, etc...) - > although having similar capabilities will be important (including bound > Action properties in the annotations). > > I agree, we need our own annotation, but being similar (in appearance and behaviour) would be a good thing. regards, Peter > > - K > > ----------------------- *Original Message* ----------------------- > > *From:* "Peter De Bruycker" <pet...@gm...><pet...@gm...> > *To:* spr...@go... > *Cc:* > *Date:* Thu, 17 Jul 2008 18:48:29 +0200 > *Subject: [spring-desktop] Re: [Desktop] @Command style* > > You're correct when you say we need to take a look at jsr 296, but we must > also realize that the swing app framework is not very active for the moment > (and I also doubt it will become active again in the near future). > > The jsr has some great ideas, but also some serious limitations > (singletons, etc). > > regards, > > Peter > > On Thu, Jul 17, 2008 at 4:39 PM, Larry Streepy <lst...@au...> > wrote: > >> I can't applaud this effort enough. I think it's really important that we >> take a look at JSR 296 and see how we can interoperate with it. There's no >> reason to create our own solutions if they've already done something good in >> 296. Mainly, let's not be different just because we didn't take a look. >> >> Thanks Claudio. >> >> Larry. >> >> >> Claudio Romano wrote: >> >> While looking at the new code in the adi-based-views branch I was >> wondering whether it would function with JSR 296. >> (https://appframework.dev.java.net/). >> So I started a little prototype based on the adi-based-views branch. I >> uploaded the prototype so everybody can get an idea how it could work:http://groups.google.com/group/spring-desktop/web/adi-based-views-jsr296.zip >> >> I'm not sure if it makes sense to try to adopt JSR 296 as there are >> some limitation on the current (JSR 296) codebase. Although I'm sure >> that most of them will be fixed in future releases. I was just curious >> to see >> if it could work for a prototype. I also wanted to figure out how they >> solved the issues Action/Resources/Views/Livecycle... >> >> One of the most disturbing things on JSR 296 are the singletons for >> the ActionManager and the ResourceManager in the ApplicationContext, >> this looks like spring-rcp singleton implementation. But I think this >> could be avoided somehow. >> >> I managed to make it work almost like the adi-base-views, the only >> feature I was not able to develop is the possibility to attach the >> View as a parameter to the action methods. But looking at the code it >> seems as they have such a feature, but it only supports one parameter >> per action method. the allowed parameter types are like: ActionEvent, >> Action, ActionMap, ResourceMap, Application, ApplicationContext ... >> >> The hole action/task part seems to be very robust and easy to >> understand. It may help for the initial jump on the spring-deskop >> action. >> >> I now will try to make the current spring-desktop trunk work with JSR >> 296. If there is some interest I can post the results here. .... If I >> will get any results actually ... ;) >> >> I hope this little prototype will help to understand the similarities >> and differences between spring-desktop and the JSR 296. >> Claudio >> >> On Jul 16, 11:29 pm, "Peter De Bruycker" <pet...@gm...> <pet...@gm...> >> wrote: >> >> >> On Wed, Jul 16, 2008 at 12:33 AM, Jim Moore <moo...@gm...> <moo...@gm...> wrote: >> >> >> Thanks for the link, Kevin. I like parts of what I glanced at, and am not >> crazy about others, but it's certainly worth a much closer look. I >> definitely like the Task support. >> >> >> This definitely looks nice! I think it can be implemented using Spin (http://spin.sourceforge.net/). >> >> >> >> >> >> The primary reason for not using javax.swing.Action is really ignorance of >> JSR 296. That kind of functionality is known as Commands in Spring RC, so >> just going with that terminology. It looks like there may be reasons for >> not using @Action (such as using Spring's auto-detection support), but it >> will take closer investigation before making that determination. (It's well >> worth the bother of trying to be JSR 296 compliant as much as possible.) >> >> >> Right now -- if I'm understanding it correctly -- @Action would be more of >> a replacement for what we are currently using @Invoker for inside of views, >> not for defining external general commands/actions (such as "help" or >> "exit"). How does JSR 296 handle running view-external events? >> >> >> -Jim Moore >> >> >> On Tue, Jul 15, 2008 at 3:21 PM, Kevin Day <ke...@tr...> <ke...@tr...> wrote: >> >> >> If anyone hasn't taken a look at JSR 296, I recommend reading (http://java.sun.com/developer/technicalArticles/javase/swingappfr/) - the >> Actions and Tasks section of that page is pertinent to the current >> discussion. Especially the ability of a declared action to return a >> background processing thread... >> >> >> Also, is there any reason that we are using Command instead of >> javax.swing.Action ? I'm sure there is historical significance, and I >> wanted to make sure I understood. >> >> >> - K >> >> >> >> >> >> > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "Spring-Desktop" group. > To post to this group, send email to spr...@go... > To unsubscribe from this group, send email to > spr...@go... > For more options, visit this group at > http://groups.google.com/group/spring-desktop?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > ------------------------------------------------------------------------- > 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 > > |
|
From: Kevin D. <ke...@tr...> - 2008-07-17 17:11:06
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2> <DIV>Here are my thoughts on jsr 296:</DIV> <DIV> </DIV> <DIV>1. The @action annotation is extremely convenient</DIV> <DIV>2. Resource injection from properties files (both for control properties, and Action properties) is convenient</DIV> <DIV>3. Their approach to long running tasks is a good start - although I'm not sure that the JSR 296 implementation is as feature rich as it should be (for example, how do we make sure that tasks can get registered with a monitoring sub-system?)</DIV> <DIV> </DIV> <DIV>The centralized caching mechanisms and singletons are not at all good (but the jsr 296 implementation doesn't force you to actually use those singletons - you can create the injectors individually).</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>I think that it is desirable to make Spring-Desktop be *compatible* with the JSR 296 approach to resource injection (i.e. use the same properties file, naming convention and file locations) so that users of 296 will find it easier to transition.</DIV> <DIV> </DIV> <DIV>I'm a bit less certain of the importance of compatability on the @action annotation side of things (i.e. using the same annotation tags, etc...) - although having similar capabilities will be important (including bound Action properties in the annotations).</DIV> <DIV> </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> "Peter De Bruycker" <A href="mailto:pet...@gm..."><FONT color=#0000ff><pet...@gm...></FONT></A></DIV> <DIV><B>To:</B> <A href="mailto:spr...@go..."><FONT color=#0000ff>spr...@go...</FONT></A></DIV> <DIV><B>Cc:</B> </DIV> <DIV><B>Date:</B> Thu, 17 Jul 2008 18:48:29 +0200</DIV> <DIV><B>Subject: <U>[spring-desktop] Re: [Desktop] @Command style</U></B></DIV> <DIV> </DIV></DIV> <DIV dir=ltr>You're correct when you say we need to take a look at jsr 296, but we must also realize that the swing app framework is not very active for the moment (and I also doubt it will become active again in the near future).<BR><BR>The jsr has some great ideas, but also some serious limitations (singletons, etc).<BR><BR>regards,<BR><BR>Peter<BR><BR> <DIV class=gmail_quote>On Thu, Jul 17, 2008 at 4:39 PM, Larry Streepy <<A href="mailto:lst...@au...">lst...@au...</A>> wrote:<BR> <BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV text="#000000" bgcolor="#ffffff">I can't applaud this effort enough. I think it's really important that we take a look at JSR 296 and see how we can interoperate with it. There's no reason to create our own solutions if they've already done something good in 296. Mainly, let's not be different just because we didn't take a look.<BR><BR>Thanks Claudio.<BR><FONT color=#888888><BR>Larry.</FONT> <DIV> <DIV></DIV> <DIV class=Wj3C7c><BR><BR>Claudio Romano wrote: <BLOCKQUOTE type="cite"><PRE>While looking at the new code in the adi-based-views branch I was wondering whether it would function with JSR 296. (<A href="https://appframework.dev.java.net/" target=_blank>https://appframework.dev.java.net/</A>). So I started a little prototype based on the adi-based-views branch. I uploaded the prototype so everybody can get an idea how it could work: <A href="http://groups.google.com/group/spring-desktop/web/adi-based-views-jsr296.zip" target=_blank>http://groups.google.com/group/spring-desktop/web/adi-based-views-jsr296.zip</A> I'm not sure if it makes sense to try to adopt JSR 296 as there are some limitation on the current (JSR 296) codebase. Although I'm sure that most of them will be fixed in future releases. I was just curious to see if it could work for a prototype. I also wanted to figure out how they solved the issues Action/Resources/Views/Livecycle... One of the most disturbing things on JSR 296 are the singletons for the ActionManager and the ResourceManager in the ApplicationContext, this looks like spring-rcp singleton implementation. But I think this could be avoided somehow. I managed to make it work almost like the adi-base-views, the only feature I was not able to develop is the possibility to attach the View as a parameter to the action methods. But looking at the code it seems as they have such a feature, but it only supports one parameter per action method. the allowed parameter types are like: ActionEvent, Action, ActionMap, ResourceMap, Application, ApplicationContext ... The hole action/task part seems to be very robust and easy to understand. It may help for the initial jump on the spring-deskop action. I now will try to make the current spring-desktop trunk work with JSR 296. If there is some interest I can post the results here. .... If I will get any results actually ... ;) I hope this little prototype will help to understand the similarities and differences between spring-desktop and the JSR 296. Claudio On Jul 16, 11:29 pm, "Peter De Bruycker" <A href="mailto:pet...@gm..." target=_blank><pet...@gm...></A> wrote: </PRE> <BLOCKQUOTE type="cite"><PRE>On Wed, Jul 16, 2008 at 12:33 AM, Jim Moore <A href="mailto:moo...@gm..." target=_blank><moo...@gm...></A> wrote: </PRE> <BLOCKQUOTE type="cite"><PRE>Thanks for the link, Kevin. I like parts of what I glanced at, and am not crazy about others, but it's certainly worth a much closer look. I definitely like the Task support. </PRE></BLOCKQUOTE><PRE>This definitely looks nice! I think it can be implemented using Spin (<A href="http://spin.sourceforge.net/" target=_blank>http://spin.sourceforge.net/</A>). </PRE> <BLOCKQUOTE type="cite"><PRE>The primary reason for not using javax.swing.Action is really ignorance of JSR 296. That kind of functionality is known as Commands in Spring RC, so just going with that terminology. It looks like there may be reasons for not using @Action (such as using Spring's auto-detection support), but it will take closer investigation before making that determination. (It's well worth the bother of trying to be JSR 296 compliant as much as possible.) </PRE></BLOCKQUOTE> <BLOCKQUOTE type="cite"><PRE>Right now -- if I'm understanding it correctly -- @Action would be more of a replacement for what we are currently using @Invoker for inside of views, not for defining external general commands/actions (such as "help" or "exit"). How does JSR 296 handle running view-external events? </PRE></BLOCKQUOTE> <BLOCKQUOTE type="cite"><PRE>-Jim Moore </PRE></BLOCKQUOTE> <BLOCKQUOTE type="cite"><PRE>On Tue, Jul 15, 2008 at 3:21 PM, Kevin Day <A href="mailto:ke...@tr..." target=_blank><ke...@tr...></A> wrote: </PRE></BLOCKQUOTE> <BLOCKQUOTE type="cite"> <BLOCKQUOTE type="cite"><PRE> If anyone hasn't taken a look at JSR 296, I recommend reading ( <A href="http://java.sun.com/developer/technicalArticles/javase/swingappfr/" target=_blank>http://java.sun.com/developer/technicalArticles/javase/swingappfr/</A>) - the Actions and Tasks section of that page is pertinent to the current discussion. Especially the ability of a declared action to return a background processing thread... </PRE></BLOCKQUOTE></BLOCKQUOTE> <BLOCKQUOTE type="cite"> <BLOCKQUOTE type="cite"><PRE>Also, is there any reason that we are using Command instead of javax.swing.Action ? I'm sure there is historical significance, and I wanted to make sure I understood. </PRE></BLOCKQUOTE></BLOCKQUOTE> <BLOCKQUOTE type="cite"> <BLOCKQUOTE type="cite"><PRE>- K </PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><PRE> </PRE></BLOCKQUOTE><BR><BR></DIV></DIV></DIV><BR></BLOCKQUOTE></DIV><BR></DIV><BR>--~--~---------~--~----~------------~-------~--~----~<BR>You received this message because you are subscribed to the Google Groups "Spring-Desktop" group. <BR>To post to this group, send email to spr...@go... <BR>To unsubscribe from this group, send email to spr...@go... <BR>For more options, visit this group at http://groups.google.com/group/spring-desktop?hl=en <BR>-~----------~----~----~----~------~----~------~--~---<BR><BR></BODY></HTML> |
|
From: Kevin D. <ke...@tr...> - 2008-07-17 14:55:39
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD> <BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2> <DIV>Does anything need to be done at this phase to ensure support for an undo/redo handler downstream? Probably not, but I wanted to ask.</DIV> <DIV> </DIV> <DIV>Swing uses a class called ActionMap to group actions together, and to provide hierarchical groupings of Actions. The functionality here may or may not have applicability (the problems it attempts to solve may be addressed by Spring). The interceptor may cover the need for hierarchical groupings (and make things more decoupled). I'm just bringing this up in case there are any lessons that can be learned from that approach.</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> "Peter De Bruycker" <A href="mailto:pet...@gm..."><FONT color=#0000ff><pet...@gm...></FONT></A></DIV> <DIV><B>To:</B> <A href="mailto:spr...@go..."><FONT color=#0000ff>spr...@go...</FONT></A></DIV> <DIV><B>Cc:</B> </DIV> <DIV><B>Date:</B> Thu, 17 Jul 2008 06:41:18 +0200</DIV> <DIV><B>Subject: <U>[spring-desktop] Action module design</U></B></DIV> <DIV> </DIV></DIV> <DIV dir=ltr>Here are some thoughts on the action module:<BR><BR><BR>The rcp commands are too complicated. Take a look at the org.springframework.richclient.command package and you'll see what I mean (I think this is one of the areas Keith was referring too when he said we need to simplify).<BR><BR>Action vs Command<BR>---------------------------<BR>The command framework was modeled after the Eclipse command system, hence the class names. I don't really remember why we didn't model it using javax.swing.Action, but I guess it has to do with the CommandGroup. I looked at the code, and I don't see any real reasons not to use Action. I also don't see any problems injecting the resources.<BR><BR>The Action interface defines the "ACTION_COMMAND_KEY" property that we can map to the bean name.<BR><BR>This means we can also handle arbitrary Action implementations loaded in the application context (using @Component, definition in the app context, ...), intercept them using a custom Bea nPostProcessor, and inject resources/dependencies into them, ...<BR><BR><BR>CommandInterceptor<BR>-----------------------------<BR>Allows interception of command execution, ... a keeper.<BR>This would become ActionInterceptor.<BR><BR><BR>CommandGroup<BR>----------------------<BR>Also a keeper. (would become ActionGroup + ActionGroupMember)<BR>It allows logical grouping of (related) commands/actions. Combined with a CommandGroupModelBuilder, it can be used to create a menubar with populated menus, a toolbar, popupmenu, button bar, ...<BR><BR><BR>Task<BR>------<BR>jsr 296 defines the Task concept, to spawn a background thread to execute long actions. Combined with Spin (<A href="http://spin.sf.net">http://spin.sf.net</A>) you can have transparant background threading<BR>You can also build a "TaskManager" or task watcher, that gives you a list of running/finished tasks, allowing you to cancel tasks, ...<BR><BR><BR>I don't know who will take the lead of the action module (I thin k Lieven may be interested), but it's important to have a (working) prototype asap.<BR><BR><BR>regards,<BR><BR>Peter<BR><BR></DIV><BR>--~--~---------~--~----~------------~-------~--~----~<BR>You received this message because you are subscribed to the Google Groups "Spring-Desktop" group. <BR>To post to this group, send email to spr...@go... <BR>To unsubscribe from this group, send email to spr...@go... <BR>For more options, visit this group at http://groups.google.com/group/spring-desktop?hl=en <BR>-~----------~----~----~----~------~----~------~--~---<BR><BR></BODY></HTML> |
|
From: Peter De B. <pet...@gm...> - 2008-07-16 08:15:31
|
On Mon, Jul 14, 2008 at 4:58 PM, Jim Moore <moo...@gm...> wrote:
> It might work, but I was thinking about being able to do something like:
>
> AppWindow.buildMenuBar() {
> List<Command> cmds = getCurrentView().getCommands();
> //...
> }
>
> Which you wouldn't be able to do lazily unless there was something that
> registered the list of everything that the view would want ahead of time.
>
> How about this compromise?
>
> @View class SampleView {
> @Command public void cmd1() { ... }
> @Command public void cmd2() { ... }
> protected List<String> getCommandNames() { ... }
> }
>
> where initCommands(..) returns back the commands that are defined in the
> class or its ancestors, along with any commands that are defined in
> getCommandNames() for "external" commands. Even do some automatic
> namespacing for the commands in the class, like "sampleView.cmd1".
>
> Obviously there still needs to be a command decorator that sets the icon,
> description, etc. on the Command instances from properties files and/or the
> information in the @Command annotation...
>
The command decorator you're talking about is the next thing on my list: a
bunch of custom BeanPostProcessors that handle injection of these resources
(label, title, tooltip, icon, ...).
These infrastructure classes are also needed for
applications/views/dialogs/...
>
> -Jim Moore
>
>
>
> On Mon, Jul 14, 2008 at 4:56 AM, Peter De Bruycker <
> pet...@gm...> wrote:
>
>> Some more thoughts:
>>
>> I think you need to get rid of the AbstractView.getCommandNames method.
>> It's another method you need to update when adding a new command. The
>> createButton method should lazily fetch command instances when needed,
>> possibly caching them somewhere.
>>
>> wdyt?
>>
>> Peter
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
|
|
From: Claudio R. <cla...@li...> - 2008-07-15 09:26:22
|
Jim Moore <moore.jim <at> gmail.com> writes: > > For whatever reason, if you give <at> Command a <at> Target of > ElementType.METHOD in addition to ElementType.TYPE then the > auto-scan breaks. > So I guess it's staying with <at> Invoker, which is fine.I added the > auto-namespacing support, and updated the test cases and sample. I also > renamed the method to getExternalCommandNames() to better identify its new > role.If people think this looks good, I can start migrating this into the > trunk. (And I'm copying spring-desktop <at> googlegroups.com for good > measure >to get this kind of discussion moved into the correct list. > -Jim Moore > Hi Jim, your implementation looks quite good! What about something like this: @Invoke(enableProperty="enabled") ? This annotation parameter would bind the enabled state of the @Invoke to the current value of a property? (Like JSR 296 btw) If the this would make sense for you then it would be another annotation parameter: "selectedProperty" . This additional parameter would toggle the selected state of the action. just my ... Claudio ps: What is the correct list for this disscussion, google group or the spring-rich mailinglist? |
|
From: Jim M. <moo...@gm...> - 2008-07-15 01:53:25
|
For whatever reason, if you give @Command a @Target of ElementType.METHOD in
addition to ElementType.TYPE then the auto-scan breaks. So I guess it's
staying with @Invoker, which is fine.
I added the auto-namespacing support, and updated the test cases and
sample. I also renamed the method to getExternalCommandNames() to better
identify its new role.
If people think this looks good, I can start migrating this into the trunk.
(And I'm copying spr...@go... for good measure to get
this kind of discussion moved into the correct list. :-)
-Jim Moore
On Mon, Jul 14, 2008 at 10:58 AM, Jim Moore <moo...@gm...> wrote:
> It might work, but I was thinking about being able to do something like:
>
> AppWindow.buildMenuBar() {
> List<Command> cmds = getCurrentView().getCommands();
> //...
> }
>
> Which you wouldn't be able to do lazily unless there was something that
> registered the list of everything that the view would want ahead of time.
>
> How about this compromise?
>
> @View class SampleView {
> @Command public void cmd1() { ... }
> @Command public void cmd2() { ... }
> protected List<String> getCommandNames() { ... }
> }
>
> where initCommands(..) returns back the commands that are defined in the
> class or its ancestors, along with any commands that are defined in
> getCommandNames() for "external" commands. Even do some automatic
> namespacing for the commands in the class, like "sampleView.cmd1".
>
> Obviously there still needs to be a command decorator that sets the icon,
> description, etc. on the Command instances from properties files and/or the
> information in the @Command annotation...
>
> -Jim Moore
>
>
>
> On Mon, Jul 14, 2008 at 4:56 AM, Peter De Bruycker <
> pet...@gm...> wrote:
>
>> Some more thoughts:
>>
>> I think you need to get rid of the AbstractView.getCommandNames method.
>> It's another method you need to update when adding a new command. The
>> createButton method should lazily fetch command instances when needed,
>> possibly caching them somewhere.
>>
>> wdyt?
>>
>> Peter
>
>
>
|
|
From: Jim M. <moo...@gm...> - 2008-07-15 01:35:17
|
Arne, I considered something like that, but the kicker was the need for a
getComponent() method for Views. Since there's no reasonable way (I could
come up with) to do that without implementing an interface, Views may as
well use interfaces and inheritance. Besides, @View(externalCommands =
{"ext1", "ext2"}) feels too much like trying to "program" with annotation
rather than letting them just provide meta-data. If someone can show me a
reasonable way to do getComponent() via annotations that isn't more of a
hassle/confusing than an interface, then I'd love to make them "pure POJOs".
On Mon, Jul 14, 2008 at 2:15 PM, Arne Limburg <Arn...@ar...> wrote:
> Hi Jim,
>
> what about something like this:
> @View(externalCommands = {"ext1", "ext2"})
> public class SampleView {
> }
>
> Regards,
> Arne
>
> Jim Moore schrieb:
> > It might work, but I was thinking about being able to do something like:
> >
> > AppWindow.buildMenuBar() {
> > List<Command> cmds = getCurrentView().getCommands();
> > //...
> > }
> >
> > Which you wouldn't be able to do lazily unless there was something
> > that registered the list of everything that the view would want ahead
> > of time.
> >
> > How about this compromise?
> >
> > @View class SampleView {
> > @Command public void cmd1() { ... }
> > @Command public void cmd2() { ... }
> > protected List<String> getCommandNames() { ... }
> > }
> >
> > where initCommands(..) returns back the commands that are defined in
> > the class or its ancestors, along with any commands that are defined
> > in getCommandNames() for "external" commands. Even do some automatic
> > namespacing for the commands in the class, like "sampleView.cmd1".
> >
> > Obviously there still needs to be a command decorator that sets the
> > icon, description, etc. on the Command instances from properties files
> > and/or the information in the @Command annotation...
> >
> > -Jim Moore
> >
> >
> > On Mon, Jul 14, 2008 at 4:56 AM, Peter De Bruycker
> > <pet...@gm... <mailto:pet...@gm...>>
> wrote:
> >
> > Some more thoughts:
> >
> > I think you need to get rid of the AbstractView.getCommandNames
> > method. It's another method you need to update when adding a new
> > command. The createButton method should lazily fetch command
> > instances when needed, possibly caching them somewhere.
> >
> > wdyt?
> >
> > Peter
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> >
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
|
|
From: Renaee <Ren...@io...> - 2008-07-15 01:19:28
|
Iranian government declares war on West http://ermistrading.com/main.html |
|
From: Arne L. <Arn...@ar...> - 2008-07-14 18:15:19
|
Hi Jim,
what about something like this:
@View(externalCommands = {"ext1", "ext2"})
public class SampleView {
}
Regards,
Arne
Jim Moore schrieb:
> It might work, but I was thinking about being able to do something like:
>
> AppWindow.buildMenuBar() {
> List<Command> cmds = getCurrentView().getCommands();
> //...
> }
>
> Which you wouldn't be able to do lazily unless there was something
> that registered the list of everything that the view would want ahead
> of time.
>
> How about this compromise?
>
> @View class SampleView {
> @Command public void cmd1() { ... }
> @Command public void cmd2() { ... }
> protected List<String> getCommandNames() { ... }
> }
>
> where initCommands(..) returns back the commands that are defined in
> the class or its ancestors, along with any commands that are defined
> in getCommandNames() for "external" commands. Even do some automatic
> namespacing for the commands in the class, like "sampleView.cmd1".
>
> Obviously there still needs to be a command decorator that sets the
> icon, description, etc. on the Command instances from properties files
> and/or the information in the @Command annotation...
>
> -Jim Moore
>
>
> On Mon, Jul 14, 2008 at 4:56 AM, Peter De Bruycker
> <pet...@gm... <mailto:pet...@gm...>> wrote:
>
> Some more thoughts:
>
> I think you need to get rid of the AbstractView.getCommandNames
> method. It's another method you need to update when adding a new
> command. The createButton method should lazily fetch command
> instances when needed, possibly caching them somewhere.
>
> wdyt?
>
> Peter
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ------------------------------------------------------------------------
>
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
|
|
From: Jim M. <moo...@gm...> - 2008-07-14 14:58:28
|
It might work, but I was thinking about being able to do something like:
AppWindow.buildMenuBar() {
List<Command> cmds = getCurrentView().getCommands();
//...
}
Which you wouldn't be able to do lazily unless there was something that
registered the list of everything that the view would want ahead of time.
How about this compromise?
@View class SampleView {
@Command public void cmd1() { ... }
@Command public void cmd2() { ... }
protected List<String> getCommandNames() { ... }
}
where initCommands(..) returns back the commands that are defined in the
class or its ancestors, along with any commands that are defined in
getCommandNames() for "external" commands. Even do some automatic
namespacing for the commands in the class, like "sampleView.cmd1".
Obviously there still needs to be a command decorator that sets the icon,
description, etc. on the Command instances from properties files and/or the
information in the @Command annotation...
-Jim Moore
On Mon, Jul 14, 2008 at 4:56 AM, Peter De Bruycker <
pet...@gm...> wrote:
> Some more thoughts:
>
> I think you need to get rid of the AbstractView.getCommandNames method.
> It's another method you need to update when adding a new command. The
> createButton method should lazily fetch command instances when needed,
> possibly caching them somewhere.
>
> wdyt?
>
> Peter
|
|
From: Jim M. <moo...@gm...> - 2008-07-14 14:40:35
|
Looks great!
On Mon, Jul 14, 2008 at 4:03 AM, Peter De Bruycker <
pet...@gm...> wrote:
> Jim,
>
> I checked some changes in to allow invoker methods directly on the view.
> Take a look at the SampleView class,
>
> regards,
>
> Peter
>
>
> On Mon, Jul 14, 2008 at 8:08 AM, Peter De Bruycker <
> pet...@gm...> wrote:
>
>> Jim,
>>
>> this looks good!
>>
>> Some questions/remarks inline:
>>
>> On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moo...@gm...> wrote:
>>
>>> I've fleshed out my prototype a little bit more in the "adi-based-views"
>>> branch. Here's the sample application in its entirety (minus imports and
>>> the like). It's only 4 classes (one bootstrap, one view, two commands) and
>>> a config file, but it show the ideas reasonably well:
>>>
>>> ----------
>>>
>>> public class App {
>>> public static void main(String[] args) {
>>> ClassPathXmlApplicationContext ctx = new
>>> ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
>>> final Application app =
>>> (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
>>> app.start(new String[0]);
>>> }
>>> }
>>
>>
>> I defined an DesktopApplicationContext interface + implementations
>>
>>
>>>
>>>
>>> <beans>
>>> <context:component-scan
>>> base-package="org.springframework.desktop.samples"
>>>
>>> scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver"
>>> />
>>>
>>> <bean
>>> class="org.springframework.desktop.core.support.DefaultApplication"
>>> p:startingWindowName="theWindow" />
>>>
>>> <bean name="theWindow"
>>> class="org.springframework.desktop.core.support.DefaultApplicationWindow"
>>> p:startingViewName="sampleView" />
>>> </beans>
>>>
>>> @View
>>> public class SampleView extends AbstractApplicationWindowView {
>>> protected JComponent createComponent() {
>>> JPanel panel = new JPanel();
>>> panel.add(createButton("noarg"));
>>> panel.add(createButton("myViewCommand"));
>>> return panel;
>>> }
>>>
>>> protected List<String> getCommandNames() {
>>> return Arrays.asList("noarg", "myViewCommand");
>>> }
>>> }
>>>
>>
>>
>> Do you think it would be possible to have the @Command annotation on
>> methods also? This would mean less code.
>>
>>
>>
>>>
>>> @Command("noarg")
>>> public class MyStandAloneCommand {
>>> @Invoker
>>> public void showDialog() {
>>> JOptionPane.showMessageDialog(null, "Stand Alone");
>>> }
>>> }
>>>
>>> @Command
>>> public class MyViewCommand {
>>> @Invoker
>>> public void showDialog(SampleView view) {
>>> JOptionPane.showMessageDialog(view.getComponent(), "This is for " +
>>> view);
>>> }
>>> }
>>>
>>> ------
>>>
>>> That's it. Some things to be sure to notice:
>>>
>>> * The XML only contains two definitions (besides the component-scan):
>>> the Application and starting ApplicationWindow. And that is only because I
>>> wanted to use default implementations but configure them externally.
>>> Everything else is wired up by the component-scan.
>>>
>>> * Views and Commands are created using "prototype" scoping from the
>>> ApplicationContext. The "DesktopAnnotationScopeMetadataResolver" in the
>>> config is what handles that for us so the user doesn't need to put a
>>> @Scope("prototype") at the top of all of their classes. (Obviously we need
>>> to hide this behind a custom namespace element.)
>>> - It's currently set up so that ApplicationWindows own Views which
>>> own Commands, and ApplicationWindows own Commands. This effectively gives
>>> us "window" and "view" scopes without the complicated event processing and
>>> ThreadLocal magic that would be needed to do custom Scope implementations.
>>>
>>> * The view merely has to say what commands it needs and they are
>>> available to it. In a more realistic application you'd want to do
>>> name-spacing of some sort...
>>>
>>> * The super nifty part is that commands don't have to extend or
>>> implement anything as long as they are annotated with @Command and @Invoker,
>>> using the same kind of adapter-pattern magic that SpringMVC does when you
>>> use @Controller and @RequestMapping. Methods that are marked as @Invoker
>>> get the same kind of "well known types" support that @RequestMapping methods
>>> do, so if you want the View, put it in the signature and it will
>>> automatically be handed to you. (Note as well that it's not just some
>>> generic View -- static/strong typing applies so I can ask for specifically
>>> SampleView in the signature.) If you don't care, don't have it in the
>>> signature. Right now only Views are supported, but there's nothing stopping
>>> us from adding other "well known types" like ApplicationWindow, JFrame,
>>> JDialog, SecurityContext, etc. (A great place to see the "magic" happen for
>>> the commands and how it works is in CommandAnnotationAdapterTests.)
>>>
>>>
>>> Hopefully that helps show what some of the possibilities are. Please let
>>> me know if you have any questions/comments.
>>>
>>> -Jim Moore
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________
>>> Springframework-rcp-dev mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>>
>>>
>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
|
|
From: Jim M. <moo...@gm...> - 2008-07-14 14:39:46
|
On Mon, Jul 14, 2008 at 2:08 AM, Peter De Bruycker <
pet...@gm...> wrote:
> Jim,
>
> this looks good!
>
> Some questions/remarks inline:
>
> On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moo...@gm...> wrote:
>
>> I've fleshed out my prototype a little bit more in the "adi-based-views"
>> branch. Here's the sample application in its entirety (minus imports and
>> the like). It's only 4 classes (one bootstrap, one view, two commands) and
>> a config file, but it show the ideas reasonably well:
>>
>> ----------
>>
>> public class App {
>> public static void main(String[] args) {
>> ClassPathXmlApplicationContext ctx = new
>> ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
>> final Application app =
>> (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
>> app.start(new String[0]);
>> }
>> }
>
>
> I defined an DesktopApplicationContext interface + implementations
>
>
I tried XmlDesktopApplicationContext, but it has a bug that doesn't allow
@Autowired. Swap it out and you'll see what I mean. Haven't taken the time
to track down why.
|
|
From: Jim M. <moo...@gm...> - 2008-07-14 14:37:12
|
For what you described, there's no need for any custom autowiring support.
Just change @I18N to @Autowired and Spring 2.5 will inject it. See the
reference documentation on @Autowired.
With the DefaultViewDesciptor you can only use the no-arg constructor. If
you want more capabilities simply provide your own ViewDescriptor.
On Sun, Jul 13, 2008 at 10:21 AM, Peter Karich <pe...@ya...> wrote:
> Hi Jim,
>
> I took a look at your source. Maybe my question is a little bit
> off-topic, but the stuff you have written is interesting and, yes, a
> little bit too complicate for me :-)
>
> So, could you please list the steps which are necessary to implement my
> own autowiring stuff?
>
> I want to have an instance of the translator in a class. How could I do
> this? E.g. to reach the following:
>
> @I18N
> Translator tr;
>
> public void showDialog() {
> JOptionPane.showMessageDialog(null, tr.getMessage("Stand Alone"));
> }
>
>
> Another question for SpringRC (!) is: how can I inject something into
> the view created through the DefaultViewDescriptor:
>
> <bean id="initialView"
>
> class="org.springframework.richclient.application.support.DefaultViewDescriptor">
> <property name="viewClass"
> value="de.timefinder.core.ui.EventTableView"/>
> </bean>
>
> Is it possible? Because if I take a look into the source I see that only
> the default constructor will be called from the EventTableView.
> Should I extend the DefaultViewDescriptor or how?
>
>
> Regards,
> Peter K.
>
> ** I want to inject an EventDao into the EventTableView
>
|
|
From: luca <sek...@re...> - 2008-07-14 11:18:07
|
Breaking news, Continental Airlines Boeing crashes over Michigan http://ferienhof-hanssler.de/main.html |
|
From: Peter De B. <pet...@gm...> - 2008-07-14 08:56:11
|
Some more thoughts:
I think you need to get rid of the AbstractView.getCommandNames method. It's
another method you need to update when adding a new command. The
createButton method should lazily fetch command instances when needed,
possibly caching them somewhere.
wdyt?
Peter
On Mon, Jul 14, 2008 at 10:03 AM, Peter De Bruycker <
pet...@gm...> wrote:
> Jim,
>
> I checked some changes in to allow invoker methods directly on the view.
> Take a look at the SampleView class,
>
> regards,
>
> Peter
>
>
> On Mon, Jul 14, 2008 at 8:08 AM, Peter De Bruycker <
> pet...@gm...> wrote:
>
>> Jim,
>>
>> this looks good!
>>
>> Some questions/remarks inline:
>>
>> On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moo...@gm...> wrote:
>>
>>> I've fleshed out my prototype a little bit more in the "adi-based-views"
>>> branch. Here's the sample application in its entirety (minus imports and
>>> the like). It's only 4 classes (one bootstrap, one view, two commands) and
>>> a config file, but it show the ideas reasonably well:
>>>
>>> ----------
>>>
>>> public class App {
>>> public static void main(String[] args) {
>>> ClassPathXmlApplicationContext ctx = new
>>> ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
>>> final Application app =
>>> (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
>>> app.start(new String[0]);
>>> }
>>> }
>>
>>
>> I defined an DesktopApplicationContext interface + implementations
>>
>>
>>>
>>>
>>> <beans>
>>> <context:component-scan
>>> base-package="org.springframework.desktop.samples"
>>>
>>> scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver"
>>> />
>>>
>>> <bean
>>> class="org.springframework.desktop.core.support.DefaultApplication"
>>> p:startingWindowName="theWindow" />
>>>
>>> <bean name="theWindow"
>>> class="org.springframework.desktop.core.support.DefaultApplicationWindow"
>>> p:startingViewName="sampleView" />
>>> </beans>
>>>
>>> @View
>>> public class SampleView extends AbstractApplicationWindowView {
>>> protected JComponent createComponent() {
>>> JPanel panel = new JPanel();
>>> panel.add(createButton("noarg"));
>>> panel.add(createButton("myViewCommand"));
>>> return panel;
>>> }
>>>
>>> protected List<String> getCommandNames() {
>>> return Arrays.asList("noarg", "myViewCommand");
>>> }
>>> }
>>>
>>
>>
>> Do you think it would be possible to have the @Command annotation on
>> methods also? This would mean less code.
>>
>>
>>
>>>
>>> @Command("noarg")
>>> public class MyStandAloneCommand {
>>> @Invoker
>>> public void showDialog() {
>>> JOptionPane.showMessageDialog(null, "Stand Alone");
>>> }
>>> }
>>>
>>> @Command
>>> public class MyViewCommand {
>>> @Invoker
>>> public void showDialog(SampleView view) {
>>> JOptionPane.showMessageDialog(view.getComponent(), "This is for " +
>>> view);
>>> }
>>> }
>>>
>>> ------
>>>
>>> That's it. Some things to be sure to notice:
>>>
>>> * The XML only contains two definitions (besides the component-scan):
>>> the Application and starting ApplicationWindow. And that is only because I
>>> wanted to use default implementations but configure them externally.
>>> Everything else is wired up by the component-scan.
>>>
>>> * Views and Commands are created using "prototype" scoping from the
>>> ApplicationContext. The "DesktopAnnotationScopeMetadataResolver" in the
>>> config is what handles that for us so the user doesn't need to put a
>>> @Scope("prototype") at the top of all of their classes. (Obviously we need
>>> to hide this behind a custom namespace element.)
>>> - It's currently set up so that ApplicationWindows own Views which
>>> own Commands, and ApplicationWindows own Commands. This effectively gives
>>> us "window" and "view" scopes without the complicated event processing and
>>> ThreadLocal magic that would be needed to do custom Scope implementations.
>>>
>>> * The view merely has to say what commands it needs and they are
>>> available to it. In a more realistic application you'd want to do
>>> name-spacing of some sort...
>>>
>>> * The super nifty part is that commands don't have to extend or
>>> implement anything as long as they are annotated with @Command and @Invoker,
>>> using the same kind of adapter-pattern magic that SpringMVC does when you
>>> use @Controller and @RequestMapping. Methods that are marked as @Invoker
>>> get the same kind of "well known types" support that @RequestMapping methods
>>> do, so if you want the View, put it in the signature and it will
>>> automatically be handed to you. (Note as well that it's not just some
>>> generic View -- static/strong typing applies so I can ask for specifically
>>> SampleView in the signature.) If you don't care, don't have it in the
>>> signature. Right now only Views are supported, but there's nothing stopping
>>> us from adding other "well known types" like ApplicationWindow, JFrame,
>>> JDialog, SecurityContext, etc. (A great place to see the "magic" happen for
>>> the commands and how it works is in CommandAnnotationAdapterTests.)
>>>
>>>
>>> Hopefully that helps show what some of the possibilities are. Please let
>>> me know if you have any questions/comments.
>>>
>>> -Jim Moore
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> _______________________________________________
>>> Springframework-rcp-dev mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>>
>>>
>>
>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-14 08:03:24
|
Jim,
I checked some changes in to allow invoker methods directly on the view.
Take a look at the SampleView class,
regards,
Peter
On Mon, Jul 14, 2008 at 8:08 AM, Peter De Bruycker <
pet...@gm...> wrote:
> Jim,
>
> this looks good!
>
> Some questions/remarks inline:
>
> On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moo...@gm...> wrote:
>
>> I've fleshed out my prototype a little bit more in the "adi-based-views"
>> branch. Here's the sample application in its entirety (minus imports and
>> the like). It's only 4 classes (one bootstrap, one view, two commands) and
>> a config file, but it show the ideas reasonably well:
>>
>> ----------
>>
>> public class App {
>> public static void main(String[] args) {
>> ClassPathXmlApplicationContext ctx = new
>> ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
>> final Application app =
>> (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
>> app.start(new String[0]);
>> }
>> }
>
>
> I defined an DesktopApplicationContext interface + implementations
>
>
>>
>>
>> <beans>
>> <context:component-scan
>> base-package="org.springframework.desktop.samples"
>>
>> scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver"
>> />
>>
>> <bean
>> class="org.springframework.desktop.core.support.DefaultApplication"
>> p:startingWindowName="theWindow" />
>>
>> <bean name="theWindow"
>> class="org.springframework.desktop.core.support.DefaultApplicationWindow"
>> p:startingViewName="sampleView" />
>> </beans>
>>
>> @View
>> public class SampleView extends AbstractApplicationWindowView {
>> protected JComponent createComponent() {
>> JPanel panel = new JPanel();
>> panel.add(createButton("noarg"));
>> panel.add(createButton("myViewCommand"));
>> return panel;
>> }
>>
>> protected List<String> getCommandNames() {
>> return Arrays.asList("noarg", "myViewCommand");
>> }
>> }
>>
>
>
> Do you think it would be possible to have the @Command annotation on
> methods also? This would mean less code.
>
>
>
>>
>> @Command("noarg")
>> public class MyStandAloneCommand {
>> @Invoker
>> public void showDialog() {
>> JOptionPane.showMessageDialog(null, "Stand Alone");
>> }
>> }
>>
>> @Command
>> public class MyViewCommand {
>> @Invoker
>> public void showDialog(SampleView view) {
>> JOptionPane.showMessageDialog(view.getComponent(), "This is for " +
>> view);
>> }
>> }
>>
>> ------
>>
>> That's it. Some things to be sure to notice:
>>
>> * The XML only contains two definitions (besides the component-scan):
>> the Application and starting ApplicationWindow. And that is only because I
>> wanted to use default implementations but configure them externally.
>> Everything else is wired up by the component-scan.
>>
>> * Views and Commands are created using "prototype" scoping from the
>> ApplicationContext. The "DesktopAnnotationScopeMetadataResolver" in the
>> config is what handles that for us so the user doesn't need to put a
>> @Scope("prototype") at the top of all of their classes. (Obviously we need
>> to hide this behind a custom namespace element.)
>> - It's currently set up so that ApplicationWindows own Views which
>> own Commands, and ApplicationWindows own Commands. This effectively gives
>> us "window" and "view" scopes without the complicated event processing and
>> ThreadLocal magic that would be needed to do custom Scope implementations.
>>
>> * The view merely has to say what commands it needs and they are
>> available to it. In a more realistic application you'd want to do
>> name-spacing of some sort...
>>
>> * The super nifty part is that commands don't have to extend or
>> implement anything as long as they are annotated with @Command and @Invoker,
>> using the same kind of adapter-pattern magic that SpringMVC does when you
>> use @Controller and @RequestMapping. Methods that are marked as @Invoker
>> get the same kind of "well known types" support that @RequestMapping methods
>> do, so if you want the View, put it in the signature and it will
>> automatically be handed to you. (Note as well that it's not just some
>> generic View -- static/strong typing applies so I can ask for specifically
>> SampleView in the signature.) If you don't care, don't have it in the
>> signature. Right now only Views are supported, but there's nothing stopping
>> us from adding other "well known types" like ApplicationWindow, JFrame,
>> JDialog, SecurityContext, etc. (A great place to see the "magic" happen for
>> the commands and how it works is in CommandAnnotationAdapterTests.)
>>
>>
>> Hopefully that helps show what some of the possibilities are. Please let
>> me know if you have any questions/comments.
>>
>> -Jim Moore
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Springframework-rcp-dev mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>
>>
>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-14 06:08:46
|
Jim,
this looks good!
Some questions/remarks inline:
On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moo...@gm...> wrote:
> I've fleshed out my prototype a little bit more in the "adi-based-views"
> branch. Here's the sample application in its entirety (minus imports and
> the like). It's only 4 classes (one bootstrap, one view, two commands) and
> a config file, but it show the ideas reasonably well:
>
> ----------
>
> public class App {
> public static void main(String[] args) {
> ClassPathXmlApplicationContext ctx = new
> ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
> final Application app =
> (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
> app.start(new String[0]);
> }
> }
I defined an DesktopApplicationContext interface + implementations
>
>
> <beans>
> <context:component-scan
> base-package="org.springframework.desktop.samples"
>
> scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver"
> />
>
> <bean class="org.springframework.desktop.core.support.DefaultApplication"
> p:startingWindowName="theWindow" />
>
> <bean name="theWindow"
> class="org.springframework.desktop.core.support.DefaultApplicationWindow"
> p:startingViewName="sampleView" />
> </beans>
>
> @View
> public class SampleView extends AbstractApplicationWindowView {
> protected JComponent createComponent() {
> JPanel panel = new JPanel();
> panel.add(createButton("noarg"));
> panel.add(createButton("myViewCommand"));
> return panel;
> }
>
> protected List<String> getCommandNames() {
> return Arrays.asList("noarg", "myViewCommand");
> }
> }
>
Do you think it would be possible to have the @Command annotation on methods
also? This would mean less code.
>
> @Command("noarg")
> public class MyStandAloneCommand {
> @Invoker
> public void showDialog() {
> JOptionPane.showMessageDialog(null, "Stand Alone");
> }
> }
>
> @Command
> public class MyViewCommand {
> @Invoker
> public void showDialog(SampleView view) {
> JOptionPane.showMessageDialog(view.getComponent(), "This is for " +
> view);
> }
> }
>
> ------
>
> That's it. Some things to be sure to notice:
>
> * The XML only contains two definitions (besides the component-scan): the
> Application and starting ApplicationWindow. And that is only because I
> wanted to use default implementations but configure them externally.
> Everything else is wired up by the component-scan.
>
> * Views and Commands are created using "prototype" scoping from the
> ApplicationContext. The "DesktopAnnotationScopeMetadataResolver" in the
> config is what handles that for us so the user doesn't need to put a
> @Scope("prototype") at the top of all of their classes. (Obviously we need
> to hide this behind a custom namespace element.)
> - It's currently set up so that ApplicationWindows own Views which
> own Commands, and ApplicationWindows own Commands. This effectively gives
> us "window" and "view" scopes without the complicated event processing and
> ThreadLocal magic that would be needed to do custom Scope implementations.
>
> * The view merely has to say what commands it needs and they are
> available to it. In a more realistic application you'd want to do
> name-spacing of some sort...
>
> * The super nifty part is that commands don't have to extend or implement
> anything as long as they are annotated with @Command and @Invoker, using the
> same kind of adapter-pattern magic that SpringMVC does when you use
> @Controller and @RequestMapping. Methods that are marked as @Invoker get
> the same kind of "well known types" support that @RequestMapping methods do,
> so if you want the View, put it in the signature and it will automatically
> be handed to you. (Note as well that it's not just some generic View --
> static/strong typing applies so I can ask for specifically SampleView in the
> signature.) If you don't care, don't have it in the signature. Right now
> only Views are supported, but there's nothing stopping us from adding other
> "well known types" like ApplicationWindow, JFrame, JDialog, SecurityContext,
> etc. (A great place to see the "magic" happen for the commands and how it
> works is in CommandAnnotationAdapterTests.)
>
>
> Hopefully that helps show what some of the possibilities are. Please let
> me know if you have any questions/comments.
>
> -Jim Moore
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-14 05:52:31
|
On Fri, Jul 11, 2008 at 5:00 PM, Geoffrey De Smet <ge0...@gm...> wrote: > Is it accessable through gmane.org? > not yet, but I filled out a subscription form, so it should only be a matter of hours. This is the gmane list name: gmane.comp.java.springframework.springdesktop.devel > > Personnally I fear we might lose some contributors by switching mailing > lists. > The maven dev list didn't change from maven 1 to maven 2, so I see no > reason to change it, moving from spring-richclient to spring-desktop. > On the other hand, if the new mailing list is hooked into the same gmane > id (you can move mailing lists on gmane.org), I don't care :) > we're not switching lists. The new list is for spring-desktop specific topics, while the spring-rcp lists will hold all spring-rcp (duh!) topics. > > With kind regards, > Geoffrey De Smet > > > Peter De Bruycker schreef: > > All, > > > > the discussion group has been created: > > http://groups.google.com/group/spring-desktop > > > > I'll update the pom to reflect this, > > > > Jim: I also added your info to the pom.xml, if you can verify if > > everything is ok? > > > > > > regards, > > > > Peter > > > > On Thu, Jul 10, 2008 at 12:46 PM, Jim Moore <moo...@gm... > > <mailto:moo...@gm...>> wrote: > > > > Sounds good to me. > > > > > > On Thu, Jul 10, 2008 at 4:09 AM, Lieven Doclo > > <lie...@ji... <mailto:lie...@ji...>> wrote: > > > > Hello Peter, > > > > Fine by me, perhaps we can focus that list on Desktop, whereas > > this list > > will remain for RCP issues. WDYT? > > > > Wkg, > > > > Lieven > > > > > > > > ---------------------------------------------------------------------- > > > --- > > > Sponsored by: SourceForge.net Community Choice Awards: VOTE > NOW! > > > Studies have shown that voting for your favorite open source > > project, > > > along with a healthy diet, reduces your potential for chronic > > lameness > > > and boredom. Vote Now at > > http://www.sourceforge.net/community/cca08 > > > _______________________________________________ > > > Springframework-rcp-dev mailing list > > > Spr...@li... > > <mailto:Spr...@li...> > > > > > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > > > > > > > > ------------------------------------------------------------------------- > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source > > project, > > along with a healthy diet, reduces your potential for chronic > > lameness > > and boredom. Vote Now at > http://www.sourceforge.net/community/cca08 > > _______________________________________________ > > Springframework-rcp-dev mailing list > > Spr...@li... > > <mailto:Spr...@li...> > > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > > > > > > ------------------------------------------------------------------------- > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source project, > > along with a healthy diet, reduces your potential for chronic > lameness > > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > _______________________________________________ > > Springframework-rcp-dev mailing list > > Spr...@li... > > <mailto:Spr...@li...> > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > > > > > > ------------------------------------------------------------------------ > > > > ------------------------------------------------------------------------- > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source project, > > along with a healthy diet, reduces your potential for chronic lameness > > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Springframework-rcp-dev mailing list > > Spr...@li... > > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > |
406 messages has been excluded from this view by a project administrator.
