Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] @Command style

[Peter De B. <pet...@gm...>]

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