Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version
|
From: Kevin D. <ke...@tr...> - 2008-07-08 20:48:02
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>How about we start with a concrete example of how the service locator is currently used, and consider how it could be refactored?</DIV>
<DIV> </DIV>
<DIV>Here's a simple example:</DIV>
<DIV> </DIV>
<DIV>Currently RulesValidator has the ability to set a RulesSource object in the constructor, or if none is specified, it uses <FONT size=2>ApplicationServicesLocator to look up a RulesSource.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Advantages of this approach:</DIV>
<DIV> </DIV>
<DIV>1. The RulesValidator needs no knowledge of the ServiceRegistry - that dependency is completely gone.</DIV>
<DIV>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)</DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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...).</DIV>
<DIV> </DIV>
<DIV>Disadvantages of this approach:</DIV>
<DIV> </DIV>
<DIV>1. The service registry becomes more complicated (it has to support registration, and possibly deregistration, event notifications)</DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Larry Streepy <A href="mailto:lst...@au..."><FONT color=#0000ff><lst...@au...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Tue, 08 Jul 2008 14:59:53 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV>
<DIV> </DIV></DIV>Peter De Bruycker wrote:
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite">2nd attempt:<BR><BR>Can we reach a consensus here?<BR>I think we need to go as fast as possible, to keep the momentum going...<BR><BR>1. code organization:<BR>
<UL>
<LI>core
<LI>application: window, dialogs, page, view, action, ...
<LI>binding: validation, binding, forms
<LI>resources </LI></UL>2. singleton/service locator:<BR><BR>Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...<BR></BLOCKQUOTE><BR>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?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR>3. osgi support<BR><BR>First make sure we have something working, then see what we can do to improve?<BR></BLOCKQUOTE><BR>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?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR><BR>Again: I think we need to go fast, so we have something working as soon as possible.<BR><BR><BR>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!<BR><BR><BR>regards,<BR>Peter<BR></BLOCKQUOTE><BR>Good to see things getting ramped up!<BR><BR>Thanks,<BR>Larry.<BR><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML>
|
