|
From: Jim M. <moo...@gm...> - 2008-07-12 22:40:45
|
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
|
|
From: Peter K. <pe...@ya...> - 2008-07-13 14:21:14
|
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
|
|
From: Jim M. <moo...@gm...> - 2008-07-14 14:37:12
|
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 <pe...@ya...> 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
>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-14 06:08:46
|
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
>
>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-14 08:03:24
|
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
>>
>>
>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-14 08:56:11
|
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 <
pet...@gm...> 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 <
> 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
>>>
>>>
>>
>
|
|
From: Jim M. <moo...@gm...> - 2008-07-14 14:40:35
|
Looks great!
On Mon, Jul 14, 2008 at 4:03 AM, Peter De Bruycker <
pet...@gm...> 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 <
> 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
>>>
>>>
>>
>
> -------------------------------------------------------------------------
> 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
>
>
|
|
From: Jim M. <moo...@gm...> - 2008-07-14 14:39:46
|
On Mon, Jul 14, 2008 at 2: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
>
>
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.
|
|
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
|
|
From: Jim M. <moo...@gm...> - 2008-07-15 01:53:25
|
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
>
>
>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-16 08:15:31
|
On Mon, Jul 14, 2008 at 4:58 PM, 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...
>
The command decorator you're talking about is the next thing on my list: a
bunch of custom BeanPostProcessors that handle injection of these resources
(label, title, tooltip, icon, ...).
These infrastructure classes are also needed for
applications/views/dialogs/...
>
> -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
>
>
>
> -------------------------------------------------------------------------
> 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
>
>
|
|
From: Arne L. <Arn...@ar...> - 2008-07-14 18:15:19
|
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
> <pet...@gm... <mailto: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
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: Jim M. <moo...@gm...> - 2008-07-15 01:35:17
|
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 <Arn...@ar...> 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
> > <pet...@gm... <mailto: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
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > 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
> >
>
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: Claudio R. <cla...@li...> - 2008-07-15 09:26:22
|
Jim Moore <moore.jim <at> gmail.com> writes: > > For whatever reason, if you give <at> Command a <at> Target of > ElementType.METHOD in addition to ElementType.TYPE then the > auto-scan breaks. > So I guess it's staying with <at> 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 <at> googlegroups.com for good > measure >to get this kind of discussion moved into the correct list. > -Jim Moore > Hi Jim, your implementation looks quite good! What about something like this: @Invoke(enableProperty="enabled") ? This annotation parameter would bind the enabled state of the @Invoke to the current value of a property? (Like JSR 296 btw) If the this would make sense for you then it would be another annotation parameter: "selectedProperty" . This additional parameter would toggle the selected state of the action. just my ... Claudio ps: What is the correct list for this disscussion, google group or the spring-rich mailinglist? |