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

[Jim M. <moo...@gm...>]

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