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