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

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

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 <
pet...@gm...> wrote:

> Jim,
>
> this looks good!
>
> Some questions/remarks inline:
>
> On Sun, Jul 13, 2008 at 12:40 AM, Jim Moore <moo...@gm...> 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
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>
>>
>