Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] Modularity
|
From: Kevin D. <ke...@tr...> - 2008-07-07 18:46:14
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>Amen. I also appreciate your comments describing the reason that some of the service locator features were used in the RCP project - that makes a lot of sense, and I think taking some time to go through the specific use cases of dialog creation, etc... would be time well spent.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>So, it sounds like we have the beginning of a design philosophy for the Desktop project: "we do good, disciplined design (e.g., highly cohesive packages with absolutely no cycles between them, no static singletons, etc)"</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>I think that a good starting point is to lay out the services that are actually provided by the framework, and the mechanism by which users can work with those services. With these services in mind, perhaps a module definition will begin to materialize. We should also keep in mind that there are cases where modules are used to provide functionality (not necessarily services). I think that binding is a good example of this.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>That said, here is the beginning of services/capabilities that I would love to see in a RC framework (obviously, some are more important than others):</DIV>
<DIV> </DIV>
<DIV><STRONG><U>For lower level stuff:</U></STRONG></DIV>
<DIV>Service registration (let's leave the details on that one alone for the time being)</DIV>
<DIV> </DIV>
<DIV>Binding (I know that there is already binding capability in RCP, but JSR 295 is pretty slick if anyone hasn't looked at it - and possibly more general purpose. For list binding, GlazedLists is amazing - if you haven't used it and your apps have anything that is list or table based, I highly recommend it). In any case, the use of the PresentationModel pattern (something akin to the Form</DIV>
<DIV> </DIV>
<DIV>
<DIV>Validation</DIV></DIV>
<DIV> </DIV>
<DIV>Action management (JSR 296 actually has some pretty nice ideas on this)</DIV>
<DIV> </DIV>
<DIV>Curent Selection State management (in some of our apps, we use data binding to bind the current selection state to our various Action implementations - something like a dynamic dependency injection)</DIV>
<DIV> </DIV>
<DIV>GUI state persistence (allowing for addition of new functionality and toolbars as new modules are added or removed to/from the system)</DIV>
<DIV> </DIV>
<DIV>Preferences persistence (?? not sure on this one)</DIV>
<DIV> </DIV>
<DIV>Dynamic menu/command bar configuration from Action definitions (including special menu types such as MRU lists, and the ability to dynamically add and remove bundles of menu items based on 'module' presence). Ability to define insertion points for adding specific functionality (i.e. if I want to add a menu option to the Edit menu). Bear in mind that menus and command bars may need to be completely swapped out (similar to what happens with Perspective changes in Eclipse).</DIV>
<DIV> </DIV>
<DIV>Resource injection (for internationalization, etc...)</DIV>
<DIV> </DIV>
<DIV>Undo/Redo support</DIV>
<DIV> </DIV>
<DIV><STRONG><U>At a higher level:</U></STRONG></DIV>
<DIV>Dialog creation (some mechanism to quickly create bound controls, validation feedback, etc... - from what I've seen so far, Spring RCP excels at this)</DIV>
<DIV> </DIV>
<DIV>Wizard creation (dialog creation bundled with some standardized mechanism for controling wizard workflow)</DIV>
<DIV> </DIV>
<DIV>Preferences GUI (a standardized preferences GUI would be a nice option for many apps)</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>That's all for now - I'm sure the list can and will be expanded.</DIV>
<DIV> </DIV>
<DIV>- K</DIV>
<DIV> </DIV>
<DIV><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> "Jim Moore" <A href="mailto:moo...@gm..."><FONT color=#0000ff><moo...@gm...></FONT></A></DIV>
<DIV><B>To:</B> "Spring Rich Dev" <A href="mailto:spr...@li..."><FONT color=#0000ff><spr...@li...></FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Mon, 7 Jul 2008 08:37:32 -0400</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] Modularity</U></B></DIV>
<DIV> </DIV></DIV>Short summary of the modularity discussion...<BR>First premise: Modularity is good.<BR>Second premise: OSGi help with modularity.<BR>Therefore Spring Desktop needs modularity from a "good design" standpoint, but it's debatable the extent of the benefits OSGi would give relative to the additional complexity (technical and conceptual).<BR><BR>There's no reason to over-burden either development of the framework, or what people have to learn to use it. The beautiful thing about Spring DM for the end-user is that it lets you develop your application as a "normal Spring app" (ie, using DI) and not worry about if it's running in an SE or OSGi environment. If they know and want to use OSGi, then they create and consume bundles as normal Spring app-contexts with additional meta-data, otherwise they simply do things the "old" way.<BR><BR>On the framework side, as long as we do good, disciplined design (e.g., highly cohesive packages with absolut
ely no cycles between them, no static singletons, etc) then there's nothing that would prevent us from going for the traditional library modularity approach we all know and love, then upgrade to OSGi when we're feeling more comfortable with the technology. At first, no OSGi. Later someone can start maintaining the OSGi meta-data so end-users that want to use Spring Desktop in an OSGi environment can do so easily. Then, after we've seen/experienced exactly how the technology is being used, we can start adding the cool features of OSGi for those that want to take advantage of them. (This is the path that all the core Spring libraries are taking.)<BR><BR>We should go for the simplest solution first, which in this case is a highly modular library (at the package level, not necessarily the src code level) with no OSGi use. When we get to things people are begging for that can't be done except with OSGi, we'll start doing so. But let's get the b
asics in there first. :-)<BR><BR>-Jim Moore<BR><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV></FONT><FONT face=Tahoma size=2><BR> </DIV></FONT></BODY></HTML>
|
