Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Larry S. <lst...@au...>]

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* -----------------------
>   
> *From:* Larry Streepy <lst...@au...> 
> <mailto:lst...@au...>
> *To:* spr...@li... 
> <mailto:spr...@li...>
> *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.
>