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

Here are my thoughts on jsr 296:

 

1.  The @action annotation is extremely convenient

2.  Resource injection from properties files (both for control properties, and Action properties) is convenient

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.

 

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).

 

 

- K

 

----------------------- Original Message -----------------------

  

From: "Peter De Bruycker" peter.de.bruycker@...

To: spring-desktop@...

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 <lstreepy@...> 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" peter.de.bruyc...@...
wrote:
  

On Wed, Jul 16, 2008 at 12:33 AM, Jim Moore moore....@... 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...@... 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 spring-desktop@...
To unsubscribe from this group, send email to spring-desktop-unsubscribe@...
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev