|
Re: [Spring Desktop] ideas for the Desktop version
> > 3. Besides the OSGi debate Spring-Desktop should definitely provide a
> > Spring bean-scope "window" to be able to configure commands in the
> > normal application-context (if needed with scope "window") and get rid
> > of the separate commans-context.
Yes, the separate commands context has been the bane of my spring rcp
programming.
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
This all looks great!
On Tuesday 01 July 2008, Jim Moore escreveu:
> Heya, everyone. Sorry for jumping into this discussion late.
>
> I prefer Claudio's distinctions for breaking out the modules. In any case,
> we need to make sure (like Spring) that there's never a circular dependency
> between packages so that things can easily be broken apart later if needed.
>
> Spring 3.0 will also be dropping JDK1.4 support. Going to Java 5 just
> makes sense -- especially for a desktop app. (In fact it's arguable that
> we should go to Java 6 given all the desktop improvements they made.)
>
> There's a reason no Spring example shows injecting a Logger. The nature of
> logging and the logging libraries means there's no real benefit to doing
> so. Also, in general commons-logging is a bad thing (especially in
> multiple classloader environments), which is why slf4j exists, but you can
> write to the commons-logging API and use slf4j as the implementation.
> That's what the Spring does on the SpringSource Application Platform
> (S2AP), for example.
>
> I love the idea of new XML configuration. A couple of comments on the
> examples:
>
> <bean id="someBean" class="foobar">
> <property name="prefs">
> <desktop:prefs scope="user|system"
> path="path/to/preferences/node"/> </property>
> </bean>
>
> It's not clear from the example, but Spring already has support for the
> scoping capability (via aop:scoped-proxy) as described in section 3.4 of
> the reference manual. I assume "user" scope would be defined based on a
> Spring Security SecurityContext and "system" would be a standard singleton?
> Having the custom XML element would nicely hide those details from the
> user.
>
> <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> mdi:closable="true" mdi:resizable="false">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="yetAnotherView"
> viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> docking:draggable="true">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> In Spring 2.5 ADI style that might be done as
>
> <context:component-scan package="com.myco"/>
>
> @View
> public class SomeView {
> @Autowired SomeView(SomeService someService) {..}
> }
>
> @View
> @MdiConfiguration(closable=true, resizable=false)
> public class OtherView {
> @Autowired OtherView(SomeService someService) {..}
> }
>
> @View
> @DockingConfiguration(closable=false, draggable=false)
> public class YetAnotherView {
> @Autowired YetAnotherView(SomeService someService) {..}
> }
>
>
> Modular plugin support is partly for plugins (a-la Eclipse or Netbeans),
> but mostly for making it easier to do good modularity. Hot-swapping,
> discovery, etc are all just nice side-effects of having better modularity.
> Fortunately, because of Spring Dynamic Modules this can always be added
> later, especially if we follow the SpringDM conventions. (eg,
> /META-INF/spring/application-context.xml) S2AP can provide the underlying
> support for that if we want. Otherwise we can keep OSGi use (but not OSGi
> compliance) out for now. Having JSR-277 support (like WebStart and
> Netbeans) would be awesome so people don't have to download 50 copies of
> log4j and updates can happen faster/easier.
>
> -Jim Moore
> Senior Consultant, SpringSource
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
C On Mon, Jul 7, 2008 at 8:26 PM, Thomas R. Corbin < thomas.corbin@...> wrote:
This all looks great!
On Tuesday 01 July 2008, Jim Moore escreveu:
> Heya, everyone. Sorry for jumping into this discussion late.
>
> I prefer Claudio's distinctions for breaking out the modules. In any case,
> we need to make sure (like Spring) that there's never a circular dependency
> between packages so that things can easily be broken apart later if needed.
>
> Spring 3.0 will also be dropping JDK1.4 support. Going to Java 5 just
> makes sense -- especially for a desktop app. (In fact it's arguable that
> we should go to Java 6 given all the desktop improvements they made.)
>
> There's a reason no Spring example shows injecting a Logger. The nature of
> logging and the logging libraries means there's no real benefit to doing
> so. Also, in general commons-logging is a bad thing (especially in
> multiple classloader environments), which is why slf4j exists, but you can
> write to the commons-logging API and use slf4j as the implementation.
> That's what the Spring does on the SpringSource Application Platform
> (S2AP), for example.
>
> I love the idea of new XML configuration. A couple of comments on the
> examples:
>
> <bean id="someBean" class="foobar">
> <property name="prefs">
> <desktop:prefs scope="user|system"
> path="path/to/preferences/node"/> </property>
> </bean>
>
> It's not clear from the example, but Spring already has support for the
> scoping capability (via aop:scoped-proxy) as described in section 3.4 of
> the reference manual. I assume "user" scope would be defined based on a
> Spring Security SecurityContext and "system" would be a standard singleton?
> Having the custom XML element would nicely hide those details from the
> user.
>
> <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> mdi:closable="true" mdi:resizable="false">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="yetAnotherView"
> viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> docking:draggable="true">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> In Spring 2.5 ADI style that might be done as
>
> <context:component-scan package="com.myco"/>
>
> @View
> public class SomeView {
> @Autowired SomeView(SomeService someService) {..}
> }
>
> @View
> @MdiConfiguration(closable=true, resizable=false)
> public class OtherView {
> @Autowired OtherView(SomeService someService) {..}
> }
>
> @View
> @DockingConfiguration(closable=false, draggable=false)
> public class YetAnotherView {
> @Autowired YetAnotherView(SomeService someService) {..}
> }
>
>
> Modular plugin support is partly for plugins (a-la Eclipse or Netbeans),
> but mostly for making it easier to do good modularity. Hot-swapping,
> discovery, etc are all just nice side-effects of having better modularity.
> Fortunately, because of Spring Dynamic Modules this can always be added
> later, especially if we follow the SpringDM conventions. (eg,
> /META-INF/spring/application-context.xml) S2AP can provide the underlying
> support for that if we want. Otherwise we can keep OSGi use (but not OSGi
> compliance) out for now. Having JSR-277 support (like WebStart and
> Netbeans) would be awesome so people don't have to download 50 copies of
> log4j and updates can happen faster/easier.
>
> -Jim Moore
> Senior Consultant, SpringSource
-------------------------------------------------------------------------
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
_______________________________________________
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
2nd attempt: Can we reach a consensus here? I think we need to go as fast as possible, to keep the momentum going...
1. code organization: - core
- application: window, dialogs, page, view, action, ...
- binding: validation, binding, forms
- resources
2. singleton/service locator: Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...
3. osgi support First make sure we have something working, then see what we can do to improve? Again: I think we need to go fast, so we have something working as soon as possible. I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge!
regards, 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
|
|
Re: [Spring Desktop] ideas for the Desktop version
Peter De Bruycker wrote:
> 2nd attempt:
>
> Can we reach a consensus here?
> I think we need to go as fast as possible, to keep the momentum going...
>
> 1. code organization:
>
> * core
> * application: window, dialogs, page, view, action, ...
> * binding: validation, binding, forms
> * resources
>
This looks like a reasonable split to me.
> I already started on work on the application infrastructure code
> (window, page, pagecomponent, view, editor) that will allow for much
> simpler (and less) xml, multiple view instances at the same time
> (formerly known as editors)
Is there some way of instructing the different views on which object to
present? e.g. in Eclipse, you can have multiple instances of a Java code
editor, each editing a different .java source file. How do you specify
which file to edit?
Regards,
Rogan
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
On Tue, Jul 8, 2008 at 3:04 PM, Rogan Dawes < rogan@...> wrote:
Peter De Bruycker wrote:
> 2nd attempt:
>
> Can we reach a consensus here?
> I think we need to go as fast as possible, to keep the momentum going...
>
> 1. code organization:
>
> * core
> * application: window, dialogs, page, view, action, ...
> * binding: validation, binding, forms
> * resources
>
This looks like a reasonable split to me.
> I already started on work on the application infrastructure code
> (window, page, pagecomponent, view, editor) that will allow for much
> simpler (and less) xml, multiple view instances at the same time
> (formerly known as editors)
Is there some way of instructing the different views on which object to
present? e.g. in Eclipse, you can have multiple instances of a Java code
editor, each editing a different .java source file. How do you specify
which file to edit?
to open a view, you do ApplicationPage.showView(String id).
I created a new method ApplicationPage.showView(String id, Object input)
the ApplicationPage checks if a view with the given id and input is already open. if not, it opens a new one, otherwise it shows the existing one
the input is passed on to the View, so it can render itself using this object (the object can be anything, a file, a customer object, ...)
Regards,
Rogan
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
Peter De Bruycker wrote:
>
> Is there some way of instructing the different views on which object to
> present? e.g. in Eclipse, you can have multiple instances of a Java code
> editor, each editing a different .java source file. How do you specify
> which file to edit?
>
> to open a view, you do ApplicationPage.showView(String id).
>
> I created a new method ApplicationPage.showView(String id, Object input)
> the ApplicationPage checks if a view with the given id and input is
> already open. if not, it opens a new one, otherwise it shows the
> existing one
>
> the input is passed on to the View, so it can render itself using this
> object (the object can be anything, a file, a customer object, ...)
>
Perfect. Thanks!
Rogan
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
Peter De Bruycker <peter.de.bruycker <at> gmail.com> writes:
>
>
> 2nd attempt:Can we reach a consensus here?I think we need to go as fast as
possible, to keep the momentum going...1. code organization:
>
> core
> application: window, dialogs, page, view, action, ...
> binding: validation, binding, forms
> resources
+1
> 2. singleton/service locator:Get rid of it by clever use of custom xml,
>component scanning + autowiring, convention over configuration, simpler object
>structures,
+1 (just use spring 2.5 features)
> 3. osgi supportFirst make sure we have something working, then see what we can
do to improve?
+1 Just focus on cohesive packages .... after hat we can have a deeper look into
osgi if it makes sense.
> Again: I think we need to go fast, so we have something working as soon as
possible.I already started on work on the application infrastructure code
(window, page, pagecomponent, view, editor) that will allow for much simpler
(and less) xml, multiple view instances at the same time (formerly known as
editors) and easier integration possibilities with 3rd party component providers
(i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this
week. If you have questions/remarks/suggestions on these parts of the framework,
don't hesitate to give me a nudge!regards,Peter
>
What about the JSR 295 and 296? Do we want to take a look at them, at least to
the binding JSR to see if it would make sense to integrate it?
-
Claudio
>
> -------------------------------------------------------------------------
> 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 <at> lists.sourceforge.net
> 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
|
|
Re: [Spring Desktop] ideas for the Desktop version
Hi Peter,
great that you started committing.
I would prefer having having two more modules:
1. Separate an action module. Business modules may implement actions not
needing to know about the application displaying it.
2. Move out the forms from the binding/validation module. The binding
and validation stuff may be used without forms.
Regards,
Arne
Peter De Bruycker schrieb:
> 2nd attempt:
>
> Can we reach a consensus here?
> I think we need to go as fast as possible, to keep the momentum going...
>
> 1. code organization:
>
> * core
> * application: window, dialogs, page, view, action, ...
> * binding: validation, binding, forms
> * resources
>
> 2. singleton/service locator:
>
> Get rid of it by clever use of custom xml, component scanning +
> autowiring, convention over configuration, simpler object structures, ...
>
> 3. osgi support
>
> First make sure we have something working, then see what we can do to
> improve?
>
>
> Again: I think we need to go fast, so we have something working as
> soon as possible.
>
>
> I already started on work on the application infrastructure code
> (window, page, pagecomponent, view, editor) that will allow for much
> simpler (and less) xml, multiple view instances at the same time
> (formerly known as editors) and easier integration possibilities with
> 3rd party component providers (i.e. Jide, SwingDocking, ...), and I
> expect to be able to check them in this week. If you have
> questions/remarks/suggestions on these parts of the framework, don't
> hesitate to give me a nudge!
>
>
> regards,
>
> 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
|
|
Re: [Spring Desktop] ideas for the Desktop version
Peter De Bruycker wrote:
2nd attempt:
Can we reach a consensus here?
I think we need to go as fast as possible, to keep the momentum going...
1. code organization:
- core
- application: window, dialogs, page, view, action, ...
- binding: validation, binding, forms
- resources
2. singleton/service locator:
Get rid of it by clever use of custom xml, component scanning +
autowiring, convention over configuration, simpler object structures,
...
I'm still unclear on how we do this without an explosion of XML or
intermediate factories, lots of boilerplate (including additional
members on objects), or some other nasty artifact that makes the
platform difficult to use. Maybe I missed how this was to be done in
the earlier email exchange, or I'm just being dense. Could you please
elucidate how we get rid of the service locator and keep the solution
simple to implement even with dynamic objects?
3. osgi support
First make sure we have something working, then see what we can do to
improve?
Do you mean to get the basic modularity cleaned up first and then look
at OSGi, or do you mean get OSGi working right away?
Again: I think we need to go fast, so we have something working as soon
as possible.
I already started on work on the application infrastructure code
(window, page, pagecomponent, view, editor) that will allow for much
simpler (and less) xml, multiple view instances at the same time
(formerly known as editors) and easier integration possibilities with
3rd party component providers (i.e. Jide, SwingDocking, ...), and I
expect to be able to check them in this week. If you have
questions/remarks/suggestions on these parts of the framework, don't
hesitate to give me a nudge!
regards,
Peter
Good to see things getting ramped up!
Thanks,
Larry.
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
Some parts of this message have been removed.
Learn more about Nabble's security policy.
How about we start with a concrete example of how the service locator is currently used, and consider how it could be refactored?
Here's a simple example:
Currently RulesValidator has the ability to set a RulesSource object in the constructor, or if none is specified, it uses ApplicationServicesLocator to look up a RulesSource.
Another approach is to consider that we know that any given RulesValidator is *always* going to need a RulesSource. So we provide a setter for rulesSource (and probably ditch the variable pass in the constructor). When a RulesValidator is created, it is registered with a ServiceRegistry. The ServiceRegistry sends notifications that a new RulesValidator has been registered.
We also have a Configurator object that has been created that listends to the ServiceRegistry. When new objects are registered, it injects resources into them. So as the RulesValidator is registered, the Configurator becomes aware of it, and injects the appropriate RulesSource. For the generic case, a default RulesSource will get injected. If a given RulesValidator needs a specific instance, the Configurator can determine which one to provide using a number of different strategies (xml, annotations, convention or any of a ton of other ways of declaritively specifying this kind of thing).
Advantages of this approach:
1. The RulesValidator needs no knowledge of the ServiceRegistry - that dependency is completely gone.
2. The RulesSource needs no knowledge of the ServiceRegistry (Spring DI should be able to take care of the registration as it creates the RulesSource)
3. The behavior of configuration of objects becomes factored out into a separate entity (Configurator, or whatever). There is no longer any self configuration, which keeps the RulesValidator and RulesSource clean.
If the Configurator is in a separate 'module' (or we follow appropriate design guidelines to ensure there isn't dependency creep), it may be possible to have different implementations of the basic configuration policy (i.e. one using xml files, one using annotations, one 'by-convention', etc...).
Disadvantages of this approach:
1. The service registry becomes more complicated (it has to support registration, and possibly deregistration, event notifications)
2. The service registry still needs to be made available (although I suspect that in most cases this can be factored out into Spring DI). If it does need to be made available, I believe that it should be done by injection (at least at the module level) and not via static lookup. If a module wants to store a copy of the service registry in a static variable with global module scope, then so be it - but I think the overall framework should not require this.
Comments? I think it may be worthwhile to take a look at a bunch of cases like this and make sure that it really makes sense.
- K
----------------------- Original Message -----------------------
Cc:
Date: Tue, 08 Jul 2008 14:59:53 -0500
Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version
Peter De Bruycker wrote:
2nd attempt:
Can we reach a consensus here?
I think we need to go as fast as possible, to keep the momentum going...
1. code organization:
- core
- application: window, dialogs, page, view, action, ...
- binding: validation, binding, forms
- resources
2. singleton/service locator:
Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...
I'm still unclear on how we do this without an explosion of XML or intermediate factories, lots of boilerplate (including additional members on objects), or some other nasty artifact that makes the platform difficult to use. Maybe I missed how this was to be done in the earlier email exchange, or I'm just being dense. Could you please elucidate how we get rid of the service locator and keep the solution simple to implement even with dynamic objects?
3. osgi support
First make sure we have something working, then see what we can do to improve?
Do you mean to get the basic modularity cleaned up first and then look at OSGi, or do you mean get OSGi working right away?
Again: I think we need to go fast, so we have something working as soon as possible.
I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge!
regards,
Peter
Good to see things getting ramped up! Thanks, Larry.
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
Some parts of this message have been removed.
Learn more about Nabble's security policy.
In this approach haven't we just replaced the ServiceLocator with a
ServiceRegistry - with all the same problems? Meaning that every
object needs to "find" the ServiceRegistry, either by having it be a
static singleton, or having declarative XML to DI it. This leads us
right back to the earlier problems we had with the ServiceLocator. Or,
have I misunderstood something in your proposal Kevin?
Thanks,
Larry.
Kevin Day wrote:
How about we start with a concrete example of how the service
locator is currently used, and consider how it could be refactored?
Here's a simple example:
Currently RulesValidator has the ability to set a RulesSource
object in the constructor, or if none is specified, it uses ApplicationServicesLocator to look up a RulesSource.
Another approach is to consider that we know that any given
RulesValidator is *always* going to need a RulesSource. So we provide
a setter for rulesSource (and probably ditch the variable pass in the
constructor). When a RulesValidator is created, it is registered with
a ServiceRegistry. The ServiceRegistry sends notifications that a new
RulesValidator has been registered.
We also have a Configurator object that has been created that
listends to the ServiceRegistry. When new objects are registered, it
injects resources into them. So as the RulesValidator is registered,
the Configurator becomes aware of it, and injects the appropriate
RulesSource. For the generic case, a default RulesSource will get
injected. If a given RulesValidator needs a specific instance, the
Configurator can determine which one to provide using a number of
different strategies (xml, annotations, convention or any of a ton of
other ways of declaritively specifying this kind of thing).
Advantages of this approach:
1. The RulesValidator needs no knowledge of the ServiceRegistry
- that dependency is completely gone.
2. The RulesSource needs no knowledge of the ServiceRegistry
(Spring DI should be able to take care of the registration as it
creates the RulesSource)
3. The behavior of configuration of objects becomes factored
out into a separate entity (Configurator, or whatever). There is no
longer any self configuration, which keeps the RulesValidator and
RulesSource clean.
If the Configurator is in a separate 'module' (or we follow
appropriate design guidelines to ensure there isn't dependency creep),
it may be possible to have different implementations of the basic
configuration policy (i.e. one using xml files, one using annotations,
one 'by-convention', etc...).
Disadvantages of this approach:
1. The service registry becomes more complicated (it has to
support registration, and possibly deregistration, event notifications)
2. The service registry still needs to be made available
(although I suspect that in most cases this can be factored out into
Spring DI). If it does need to be made available, I believe that it
should be done by injection (at least at the module level) and not via
static lookup. If a module wants to store a copy of the service
registry in a static variable with global module scope, then so be it -
but I think the overall framework should not require this.
Comments? I think it may be worthwhile to take a look at a bunch
of cases like this and make sure that it really makes sense.
- K
----------------------- Original Message
-----------------------
Cc:
Date: Tue, 08 Jul 2008 14:59:53 -0500
Subject: Re: [Springframework-rcp-dev] [Spring Desktop]
ideas for the Desktop version
Peter De Bruycker wrote:
2nd attempt:
Can we reach a consensus here?
I think we need to go as fast as possible, to keep the momentum going...
1. code organization:
- core
- application: window, dialogs, page, view, action, ...
- binding: validation, binding, forms
- resources
2. singleton/service locator:
Get rid of it by clever use of custom xml, component scanning +
autowiring, convention over configuration, simpler object structures,
...
I'm still unclear on how we do this without an explosion of XML or
intermediate factories, lots of boilerplate (including additional
members on objects), or some other nasty artifact that makes the
platform difficult to use. Maybe I missed how this was to be done in
the earlier email exchange, or I'm just being dense. Could you please
elucidate how we get rid of the service locator and keep the solution
simple to implement even with dynamic objects?
3. osgi support
First make sure we have something working, then see what we can do to
improve?
Do you mean to get the basic modularity cleaned up first and then look
at OSGi, or do you mean get OSGi working right away?
Again: I think we need to go fast, so we have something working as soon
as possible.
I already started on work on the application infrastructure code
(window, page, pagecomponent, view, editor) that will allow for much
simpler (and less) xml, multiple view instances at the same time
(formerly known as editors) and easier integration possibilities with
3rd party component providers (i.e. Jide, SwingDocking, ...), and I
expect to be able to check them in this week. If you have
questions/remarks/suggestions on these parts of the framework, don't
hesitate to give me a nudge!
regards,
Peter
Good to see things getting ramped up!
Thanks,
Larry.
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I think that this approach exactly inverts the ServiceLocator approach.
In the current RulesValidator, there is an explicit call to (RulesSource) ApplicationServicesLocator.services().getService(RulesSource.class);
this call is the root of the dependency issue under discussion.
By inverting the problem, we can remove references to the static ApplicationServicesLocator.services() method entirely. Instead, the configuration of the object is factored out, and is triggered on registration of the object with the service registry. This last point (configuration occurs on registration) is actually pretty important because it drives the direction that dependencies are created. Instead of registring object foo with service A, we allow A to be notified when objects of type Foo become available. Service A (or preferably a handler such as Spring DM) then registers the object with the service. This enforces decoupling between objects and the services that operate on them. (Ironically, the 'ServiceRegistry' isn't really a registry of services at all - it's a registry of objects that services may want to operate on. In most cases, the service itself will never be registered with the registry). Perhaps some
renaming is called for...
Anyway, the result of this in the current refactored example is that we are not injecting the ApplicationServicesLocator object into the RulesValidator. We are injecting the dependency that RulesValidator actually needs (RulesSource). At a functional level, RulesValidator should not need to know about ApplicationServicesLocator to properly function.
Objects themselves are very rarely, if ever, actually aware of the service registry. The framework itself does most (if not all) of that interaction on the object's behalf. The difference is subtle, but it completely unravels the dependency issue and makes modular development possible (as well as dynamic loading/unloading and all of the interesting stuff that comes with this kind of decoupling).
- K
----------------------- Original Message -----------------------
Cc:
Date: Tue, 08 Jul 2008 16:23:52 -0500
Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version
In this approach haven't we just replaced the ServiceLocator with a ServiceRegistry - with all the same problems? Meaning that every object needs to "find" the ServiceRegistry, either by having it be a static singleton, or having declarative XML to DI it. This leads us right back to the earlier problems we had with the ServiceLocator. Or, have I misunderstood something in your proposal Kevin?
Thanks,
Larry.
Kevin Day wrote:
How about we start with a concrete example of how the service locator is currently used, and consider how it could be refactored?
Here's a simple example:
Currently RulesValidator has the ability to set a RulesSource object in the constructor, or if none is specified, it uses ApplicationServicesLocator to look up a RulesSource.
Another approach is to consider that we know that any given RulesValidator is *always* going to need a RulesSource. So we provide a setter for rulesSource (and probably ditch the variable pass in the constructor). When a RulesValidator is created, it is registered with a ServiceRegistry. The ServiceRegistry sends notifications that a new RulesValidator has been registered.
We also have a Configurator object that has been created that listends to the ServiceRegistry. When new objects are registered, it injects resources into them. So as the RulesValidator is registered, the Configurator becomes aware of it, and injects the appropriate RulesSource. For the generic case, a default RulesSource will get injected. If a given RulesValidator needs a specific instance, the Configurator can determine which one to provide using a number of different strategies (xml, annotations, convention or any of a ton of other ways of declaritively specifying this kind of thing).
Advantages of this approach:
1. The RulesValidator needs no knowledge of the ServiceRegistry - that dependency is completely gone.
2. The RulesSource needs no knowledge of the ServiceRegistry (Spring DI should be able to take care of the registration as it creates the RulesSource)
3. The behavior of configuration of objects becomes factored out into a separate entity (Configurator, or whatever). There is no longer any self configuration, which keeps the RulesValidator and RulesSource clean.
If the Configurator is in a separate 'module' (or we follow appropriate design guidelines to ensure there isn't dependency creep), it may be possible to have different implementations of the basic configuration policy (i.e. one using xml files, one using annotations, one 'by-convention', etc...).
Disadvantages of this approach:
1. The service registry becomes more complicated (it has to support registration, and possibly deregistration, event notifications)
2. The service registry still needs to be made available (although I suspect that in most cases this can be factored out into Spring DI). If it does need to be made available, I believe that it should be done by injection (at least at the module level) and not via static lookup. If a module wants to store a copy of the service registry in a static variable with global module scope, then so be it - but I think the overall framework should not require this.
Comments? I think it may be worthwhile to take a look at a bunch of cases like this and make sure that it really makes sense.
- K
----------------------- Original Message -----------------------
Cc:
Date: Tue, 08 Jul 2008 14:59:53 -0500
Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version
Peter De Bruycker wrote:
2nd attempt:
Can we reach a consensus here?
I think we need to go as fast as possible, to keep the momentum going...
1. code organization:
- core
- application: window, dialogs, page, view, action, ...
- binding: validation, binding, forms
- resources
2. singleton/service locator:
Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...
I'm still unclear on how we do this without an explosion of XML or intermediate factories, lots of boilerplate (including additional members on objects), or some other nasty artifact that makes the platform difficult to use. Maybe I missed how this was to be done in the earlier email exchange, or I'm just being dense. Could you please elucidate how we get rid of the service locator and keep the solution simple to implement even with dynamic objects?
3. osgi support
First make sure we have something working, then see what we can do to improve?
Do you mean to get the basic modularity cleaned up first and then look at OSGi, or do you mean get OSGi working right away?
Again: I think we need to go fast, so we have something working as soon as possible.
I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge!
regards,
Peter
Good to see things getting ramped up!
Thanks,
Larry.
-------------------------------------------------------------------------
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
|
