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

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