[Desktop] @Command style

[Jim Moore]

I've fleshed out my prototype a little bit more in the "adi-based-views" branch.  Here's the sample application in its entirety (minus imports and the like).  It's only 4 classes (one bootstrap, one view, two commands) and a config file, but it show the ideas reasonably well:

----------

public class App {
  public static void main(String[] args) {
    ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
    final Application app = (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
    app.start(new String[0]);
  }
}

<beans>
  <context:component-scan base-package="org.springframework.desktop.samples"
    scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver" />

  <bean class="org.springframework.desktop.core.support.DefaultApplication" p:startingWindowName="theWindow" />

  <bean name="theWindow" class="org.springframework.desktop.core.support.DefaultApplicationWindow"
    p:startingViewName="sampleView" />
</beans>

@View
public class SampleView extends AbstractApplicationWindowView {
  protected JComponent createComponent() {
    JPanel panel = new JPanel();
    panel.add(createButton("noarg"));
    panel.add(createButton("myViewCommand"));
    return panel;
  }

  protected List<String> getCommandNames() {
    return Arrays.asList("noarg", "myViewCommand");
  }
}

@Command("noarg")
public class MyStandAloneCommand {
  @Invoker
  public void showDialog() {
    JOptionPane.showMessageDialog(null, "Stand Alone");
  }
}

@Command
public class MyViewCommand {
  @Invoker
  public void showDialog(SampleView view) {
    JOptionPane.showMessageDialog(view.getComponent(), "This is for " + view);
  }
}

------

That's it.  Some things to be sure to notice:

  * The XML only contains two definitions (besides the component-scan): the Application and starting ApplicationWindow.  And that is only because I wanted to use default implementations but configure them externally.  Everything else is wired up by the component-scan.

  * Views and Commands are created using "prototype" scoping from the ApplicationContext.  The "DesktopAnnotationScopeMetadataResolver" in the config is what handles that for us so the user doesn't need to put a @Scope("prototype") at the top of all of their classes.  (Obviously we need to hide this behind a custom namespace element.)
      - It's currently set up so that ApplicationWindows own Views which own Commands, and ApplicationWindows own Commands.  This effectively gives us "window" and "view" scopes without the complicated event processing and ThreadLocal magic that would be needed to do custom Scope implementations.

  * The view merely has to say what commands it needs and they are available to it.  In a more realistic application you'd want to do name-spacing of some sort...

  * The super nifty part is that commands don't have to extend or implement anything as long as they are annotated with @Command and @Invoker, using the same kind of adapter-pattern magic that SpringMVC does when you use @Controller and @RequestMapping.  Methods that are marked as @Invoker get the same kind of "well known types" support that @RequestMapping methods do, so if you want the View, put it in the signature and it will automatically be handed to you.  (Note as well that it's not just some generic View -- static/strong typing applies so I can ask for specifically SampleView in the signature.) If you don't care, don't have it in the signature.  Right now only Views are supported, but there's nothing stopping us from adding other "well known types" like ApplicationWindow, JFrame, JDialog, SecurityContext, etc.  (A great place to see the "magic" happen for the commands and how it works is in CommandAnnotationAdapterTests.)


Hopefully that helps show what some of the possibilities are.  Please let me know if you have any questions/comments.

-Jim Moore


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[petar]

Hi Jim,

I took a look at your source. Maybe my question is a little bit
off-topic, but the stuff you have written is interesting and, yes, a
little bit too complicate for me :-)

So, could you please list the steps which are necessary to implement my
own autowiring stuff?

I want to have an instance of the translator in a class. How could I do
this? E.g. to reach the following:

@I18N
Translator tr;

public void showDialog() {
    JOptionPane.showMessageDialog(null, tr.getMessage("Stand Alone"));
}


Another question for SpringRC (!) is: how can I inject something into
the view created through the DefaultViewDescriptor:

<bean id="initialView"
class="org.springframework.richclient.application.support.DefaultViewDescriptor">
     <property name="viewClass"
value="de.timefinder.core.ui.EventTableView"/>
</bean>

Is it possible? Because if I take a look into the source I see that only
the default constructor will be called from the EventTableView.
Should I extend the DefaultViewDescriptor or how?


Regards,
Peter K.

** I want to inject an EventDao into the EventTableView


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Peter De Bruycker-2]

Jim,

this looks good!

Some questions/remarks inline:

On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moore.jim@...> wrote:

I've fleshed out my prototype a little bit more in the "adi-based-views" branch.  Here's the sample application in its entirety (minus imports and the like).  It's only 4 classes (one bootstrap, one view, two commands) and a config file, but it show the ideas reasonably well:

----------

public class App {
  public static void main(String[] args) {
    ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
    final Application app = (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
    app.start(new String[0]);
  }
}

I defined an DesktopApplicationContext interface + implementations
 

<beans>
  <context:component-scan base-package="org.springframework.desktop.samples"
    scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver" />

  <bean class="org.springframework.desktop.core.support.DefaultApplication" p:startingWindowName="theWindow" />

  <bean name="theWindow" class="org.springframework.desktop.core.support.DefaultApplicationWindow"
    p:startingViewName="sampleView" />
</beans>

@View
public class SampleView extends AbstractApplicationWindowView {
  protected JComponent createComponent() {
    JPanel panel = new JPanel();
    panel.add(createButton("noarg"));
    panel.add(createButton("myViewCommand"));
    return panel;
  }

  protected List<String> getCommandNames() {
    return Arrays.asList("noarg", "myViewCommand");
  }
}

Do you think it would be possible to have the @Command annotation on methods also? This would mean less code.

 

@Command("noarg")
public class MyStandAloneCommand {
  @Invoker
  public void showDialog() {
    JOptionPane.showMessageDialog(null, "Stand Alone");
  }
}

@Command
public class MyViewCommand {
  @Invoker
  public void showDialog(SampleView view) {
    JOptionPane.showMessageDialog(view.getComponent(), "This is for " + view);
  }
}

------

That's it.  Some things to be sure to notice:

  * The XML only contains two definitions (besides the component-scan): the Application and starting ApplicationWindow.  And that is only because I wanted to use default implementations but configure them externally.  Everything else is wired up by the component-scan.

  * Views and Commands are created using "prototype" scoping from the ApplicationContext.  The "DesktopAnnotationScopeMetadataResolver" in the config is what handles that for us so the user doesn't need to put a @Scope("prototype") at the top of all of their classes.  (Obviously we need to hide this behind a custom namespace element.)
      - It's currently set up so that ApplicationWindows own Views which own Commands, and ApplicationWindows own Commands.  This effectively gives us "window" and "view" scopes without the complicated event processing and ThreadLocal magic that would be needed to do custom Scope implementations.

  * The view merely has to say what commands it needs and they are available to it.  In a more realistic application you'd want to do name-spacing of some sort...

  * The super nifty part is that commands don't have to extend or implement anything as long as they are annotated with @Command and @Invoker, using the same kind of adapter-pattern magic that SpringMVC does when you use @Controller and @RequestMapping.  Methods that are marked as @Invoker get the same kind of "well known types" support that @RequestMapping methods do, so if you want the View, put it in the signature and it will automatically be handed to you.  (Note as well that it's not just some generic View -- static/strong typing applies so I can ask for specifically SampleView in the signature.) If you don't care, don't have it in the signature.  Right now only Views are supported, but there's nothing stopping us from adding other "well known types" like ApplicationWindow, JFrame, JDialog, SecurityContext, etc.  (A great place to see the "magic" happen for the commands and how it works is in CommandAnnotationAdapterTests.)


Hopefully that helps show what some of the possibilities are.  Please let me know if you have any questions/comments.

-Jim Moore


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Peter De Bruycker-2]

Jim,

I checked some changes in to allow invoker methods directly on the view. Take a look at the SampleView class,

regards,

Peter

On Mon, Jul 14, 2008 at 8:08 AM, Peter De Bruycker <peter.de.bruycker@...> wrote:

Jim,

this looks good!

Some questions/remarks inline:

On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moore.jim@...> wrote:

I've fleshed out my prototype a little bit more in the "adi-based-views" branch.  Here's the sample application in its entirety (minus imports and the like).  It's only 4 classes (one bootstrap, one view, two commands) and a config file, but it show the ideas reasonably well:

----------

public class App {
  public static void main(String[] args) {
    ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
    final Application app = (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
    app.start(new String[0]);
  }
}

I defined an DesktopApplicationContext interface + implementations
 

<beans>
  <context:component-scan base-package="org.springframework.desktop.samples"
    scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver" />

  <bean class="org.springframework.desktop.core.support.DefaultApplication" p:startingWindowName="theWindow" />

  <bean name="theWindow" class="org.springframework.desktop.core.support.DefaultApplicationWindow"
    p:startingViewName="sampleView" />
</beans>

@View
public class SampleView extends AbstractApplicationWindowView {
  protected JComponent createComponent() {
    JPanel panel = new JPanel();
    panel.add(createButton("noarg"));
    panel.add(createButton("myViewCommand"));
    return panel;
  }

  protected List<String> getCommandNames() {
    return Arrays.asList("noarg", "myViewCommand");
  }
}

Do you think it would be possible to have the @Command annotation on methods also? This would mean less code.

 

@Command("noarg")
public class MyStandAloneCommand {
  @Invoker
  public void showDialog() {
    JOptionPane.showMessageDialog(null, "Stand Alone");
  }
}

@Command
public class MyViewCommand {
  @Invoker
  public void showDialog(SampleView view) {
    JOptionPane.showMessageDialog(view.getComponent(), "This is for " + view);
  }
}

------

That's it.  Some things to be sure to notice:

  * The XML only contains two definitions (besides the component-scan): the Application and starting ApplicationWindow.  And that is only because I wanted to use default implementations but configure them externally.  Everything else is wired up by the component-scan.

  * Views and Commands are created using "prototype" scoping from the ApplicationContext.  The "DesktopAnnotationScopeMetadataResolver" in the config is what handles that for us so the user doesn't need to put a @Scope("prototype") at the top of all of their classes.  (Obviously we need to hide this behind a custom namespace element.)
      - It's currently set up so that ApplicationWindows own Views which own Commands, and ApplicationWindows own Commands.  This effectively gives us "window" and "view" scopes without the complicated event processing and ThreadLocal magic that would be needed to do custom Scope implementations.

  * The view merely has to say what commands it needs and they are available to it.  In a more realistic application you'd want to do name-spacing of some sort...

  * The super nifty part is that commands don't have to extend or implement anything as long as they are annotated with @Command and @Invoker, using the same kind of adapter-pattern magic that SpringMVC does when you use @Controller and @RequestMapping.  Methods that are marked as @Invoker get the same kind of "well known types" support that @RequestMapping methods do, so if you want the View, put it in the signature and it will automatically be handed to you.  (Note as well that it's not just some generic View -- static/strong typing applies so I can ask for specifically SampleView in the signature.) If you don't care, don't have it in the signature.  Right now only Views are supported, but there's nothing stopping us from adding other "well known types" like ApplicationWindow, JFrame, JDialog, SecurityContext, etc.  (A great place to see the "magic" happen for the commands and how it works is in CommandAnnotationAdapterTests.)


Hopefully that helps show what some of the possibilities are.  Please let me know if you have any questions/comments.

-Jim Moore

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Peter De Bruycker-2]

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

On Mon, Jul 14, 2008 at 10:03 AM, Peter De Bruycker <peter.de.bruycker@...> wrote:

Jim,

I checked some changes in to allow invoker methods directly on the view. Take a look at the SampleView class,

regards,

Peter

On Mon, Jul 14, 2008 at 8:08 AM, Peter De Bruycker <peter.de.bruycker@...> wrote:

Jim,

this looks good!

Some questions/remarks inline:

On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moore.jim@...> wrote:

I've fleshed out my prototype a little bit more in the "adi-based-views" branch.  Here's the sample application in its entirety (minus imports and the like).  It's only 4 classes (one bootstrap, one view, two commands) and a config file, but it show the ideas reasonably well:

----------

public class App {
  public static void main(String[] args) {
    ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
    final Application app = (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
    app.start(new String[0]);
  }
}

I defined an DesktopApplicationContext interface + implementations
 

<beans>
  <context:component-scan base-package="org.springframework.desktop.samples"
    scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver" />

  <bean class="org.springframework.desktop.core.support.DefaultApplication" p:startingWindowName="theWindow" />

  <bean name="theWindow" class="org.springframework.desktop.core.support.DefaultApplicationWindow"
    p:startingViewName="sampleView" />
</beans>

@View
public class SampleView extends AbstractApplicationWindowView {
  protected JComponent createComponent() {
    JPanel panel = new JPanel();
    panel.add(createButton("noarg"));
    panel.add(createButton("myViewCommand"));
    return panel;
  }

  protected List<String> getCommandNames() {
    return Arrays.asList("noarg", "myViewCommand");
  }
}

Do you think it would be possible to have the @Command annotation on methods also? This would mean less code.

 

@Command("noarg")
public class MyStandAloneCommand {
  @Invoker
  public void showDialog() {
    JOptionPane.showMessageDialog(null, "Stand Alone");
  }
}

@Command
public class MyViewCommand {
  @Invoker
  public void showDialog(SampleView view) {
    JOptionPane.showMessageDialog(view.getComponent(), "This is for " + view);
  }
}

------

That's it.  Some things to be sure to notice:

  * The XML only contains two definitions (besides the component-scan): the Application and starting ApplicationWindow.  And that is only because I wanted to use default implementations but configure them externally.  Everything else is wired up by the component-scan.

  * Views and Commands are created using "prototype" scoping from the ApplicationContext.  The "DesktopAnnotationScopeMetadataResolver" in the config is what handles that for us so the user doesn't need to put a @Scope("prototype") at the top of all of their classes.  (Obviously we need to hide this behind a custom namespace element.)
      - It's currently set up so that ApplicationWindows own Views which own Commands, and ApplicationWindows own Commands.  This effectively gives us "window" and "view" scopes without the complicated event processing and ThreadLocal magic that would be needed to do custom Scope implementations.

  * The view merely has to say what commands it needs and they are available to it.  In a more realistic application you'd want to do name-spacing of some sort...

  * The super nifty part is that commands don't have to extend or implement anything as long as they are annotated with @Command and @Invoker, using the same kind of adapter-pattern magic that SpringMVC does when you use @Controller and @RequestMapping.  Methods that are marked as @Invoker get the same kind of "well known types" support that @RequestMapping methods do, so if you want the View, put it in the signature and it will automatically be handed to you.  (Note as well that it's not just some generic View -- static/strong typing applies so I can ask for specifically SampleView in the signature.) If you don't care, don't have it in the signature.  Right now only Views are supported, but there's nothing stopping us from adding other "well known types" like ApplicationWindow, JFrame, JDialog, SecurityContext, etc.  (A great place to see the "magic" happen for the commands and how it works is in CommandAnnotationAdapterTests.)


Hopefully that helps show what some of the possibilities are.  Please let me know if you have any questions/comments.

-Jim Moore

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Jim Moore]

For what you described, there's no need for any custom autowiring support.  Just change @I18N to @Autowired and Spring 2.5 will inject it.  See the reference documentation on @Autowired.

With the DefaultViewDesciptor you can only use the no-arg constructor.  If you want more capabilities simply provide your own ViewDescriptor.

On Sun, Jul 13, 2008 at 10:21 AM, Peter Karich <peathal@...> wrote:

Hi Jim,

I took a look at your source. Maybe my question is a little bit
off-topic, but the stuff you have written is interesting and, yes, a
little bit too complicate for me :-)

So, could you please list the steps which are necessary to implement my
own autowiring stuff?

I want to have an instance of the translator in a class. How could I do
this? E.g. to reach the following:

@I18N
Translator tr;

public void showDialog() {
   JOptionPane.showMessageDialog(null, tr.getMessage("Stand Alone"));
}


Another question for SpringRC (!) is: how can I inject something into
the view created through the DefaultViewDescriptor:

<bean id="initialView"
class="org.springframework.richclient.application.support.DefaultViewDescriptor">
    <property name="viewClass"
value="de.timefinder.core.ui.EventTableView"/>
</bean>

Is it possible? Because if I take a look into the source I see that only
the default constructor will be called from the EventTableView.
Should I extend the DefaultViewDescriptor or how?


Regards,
Peter K.

** I want to inject an EventDao into the EventTableView

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Jim Moore]

On Mon, Jul 14, 2008 at 2:08 AM, Peter De Bruycker <peter.de.bruycker@...> wrote:

Jim,

this looks good!

Some questions/remarks inline:

On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moore.jim@...> wrote:

I've fleshed out my prototype a little bit more in the "adi-based-views" branch.  Here's the sample application in its entirety (minus imports and the like).  It's only 4 classes (one bootstrap, one view, two commands) and a config file, but it show the ideas reasonably well:

----------

public class App {
  public static void main(String[] args) {
    ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
    final Application app = (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
    app.start(new String[0]);
  }
}

I defined an DesktopApplicationContext interface + implementations
 

I tried XmlDesktopApplicationContext, but it has a bug that doesn't allow @Autowired.  Swap it out and you'll see what I mean.  Haven't taken the time to track down why.


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Jim Moore]

Looks great!

On Mon, Jul 14, 2008 at 4:03 AM, Peter De Bruycker <peter.de.bruycker@...> wrote:

Jim,

I checked some changes in to allow invoker methods directly on the view. Take a look at the SampleView class,

regards,

Peter

On Mon, Jul 14, 2008 at 8:08 AM, Peter De Bruycker <peter.de.bruycker@...> wrote:

Jim,

this looks good!

Some questions/remarks inline:

On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moore.jim@...> wrote:

I've fleshed out my prototype a little bit more in the "adi-based-views" branch.  Here's the sample application in its entirety (minus imports and the like).  It's only 4 classes (one bootstrap, one view, two commands) and a config file, but it show the ideas reasonably well:

----------

public class App {
  public static void main(String[] args) {
    ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
    final Application app = (Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
    app.start(new String[0]);
  }
}

I defined an DesktopApplicationContext interface + implementations
 

<beans>
  <context:component-scan base-package="org.springframework.desktop.samples"
    scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver" />

  <bean class="org.springframework.desktop.core.support.DefaultApplication" p:startingWindowName="theWindow" />

  <bean name="theWindow" class="org.springframework.desktop.core.support.DefaultApplicationWindow"
    p:startingViewName="sampleView" />
</beans>

@View
public class SampleView extends AbstractApplicationWindowView {
  protected JComponent createComponent() {
    JPanel panel = new JPanel();
    panel.add(createButton("noarg"));
    panel.add(createButton("myViewCommand"));
    return panel;
  }

  protected List<String> getCommandNames() {
    return Arrays.asList("noarg", "myViewCommand");
  }
}

Do you think it would be possible to have the @Command annotation on methods also? This would mean less code.

 

@Command("noarg")
public class MyStandAloneCommand {
  @Invoker
  public void showDialog() {
    JOptionPane.showMessageDialog(null, "Stand Alone");
  }
}

@Command
public class MyViewCommand {
  @Invoker
  public void showDialog(SampleView view) {
    JOptionPane.showMessageDialog(view.getComponent(), "This is for " + view);
  }
}

------

That's it.  Some things to be sure to notice:

  * The XML only contains two definitions (besides the component-scan): the Application and starting ApplicationWindow.  And that is only because I wanted to use default implementations but configure them externally.  Everything else is wired up by the component-scan.

  * Views and Commands are created using "prototype" scoping from the ApplicationContext.  The "DesktopAnnotationScopeMetadataResolver" in the config is what handles that for us so the user doesn't need to put a @Scope("prototype") at the top of all of their classes.  (Obviously we need to hide this behind a custom namespace element.)
      - It's currently set up so that ApplicationWindows own Views which own Commands, and ApplicationWindows own Commands.  This effectively gives us "window" and "view" scopes without the complicated event processing and ThreadLocal magic that would be needed to do custom Scope implementations.

  * The view merely has to say what commands it needs and they are available to it.  In a more realistic application you'd want to do name-spacing of some sort...

  * The super nifty part is that commands don't have to extend or implement anything as long as they are annotated with @Command and @Invoker, using the same kind of adapter-pattern magic that SpringMVC does when you use @Controller and @RequestMapping.  Methods that are marked as @Invoker get the same kind of "well known types" support that @RequestMapping methods do, so if you want the View, put it in the signature and it will automatically be handed to you.  (Note as well that it's not just some generic View -- static/strong typing applies so I can ask for specifically SampleView in the signature.) If you don't care, don't have it in the signature.  Right now only Views are supported, but there's nothing stopping us from adding other "well known types" like ApplicationWindow, JFrame, JDialog, SecurityContext, etc.  (A great place to see the "magic" happen for the commands and how it works is in CommandAnnotationAdapterTests.)


Hopefully that helps show what some of the possibilities are.  Please let me know if you have any questions/comments.

-Jim Moore

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Jim Moore]

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 <peter.de.bruycker@...> 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

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Arne Limburg-2]

Hi Jim,

what about something like this:
@View(externalCommands = {"ext1", "ext2"})
public class SampleView {
}

Regards,
Arne

Jim Moore schrieb:

> 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
> <peter.de.bruycker@... <mailto:peter.de.bruycker@...>> 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
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ------------------------------------------------------------------------
>
> _______________________________________________
> Springframework-rcp-dev mailing list
> Springframework-rcp-dev@...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>  

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Jim Moore]

Arne, I considered something like that, but the kicker was the need for a getComponent() method for Views.  Since there's no reasonable way (I could come up with) to do that without implementing an interface, Views may as well use interfaces and inheritance.  Besides, @View(externalCommands = {"ext1", "ext2"}) feels too much like trying to "program" with annotation rather than letting them just provide meta-data.  If someone can show me a reasonable way to do getComponent() via annotations that isn't more of a hassle/confusing than an interface, then I'd love to make them "pure POJOs".

On Mon, Jul 14, 2008 at 2:15 PM, Arne Limburg <Arne.Limburg@...> wrote:

Hi Jim,

what about something like this:
@View(externalCommands = {"ext1", "ext2"})
public class SampleView {
}

Regards,
Arne

Jim Moore schrieb:

> 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

> <peter.de.bruycker@... <mailto:peter.de.bruycker@...>> 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
>
>

> ------------------------------------------------------------------------

>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ------------------------------------------------------------------------
>
> _______________________________________________
> Springframework-rcp-dev mailing list
> Springframework-rcp-dev@...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Springframework-rcp-dev mailing list
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

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

[Jim Moore]

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 spring-desktop@... 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 <moore.jim@...> wrote:

It might work, but I was think