[Springframework-rcp-dev] [Desktop] - Thoughts on directions for Desktop project

[Kevin D. <ke...@tr...>]

The list seems to be working fine.  I'll put my thoughts and comments here instead of continuing in the forums.

I hope that I have something to add to the conversation!

First comment:  I have done some initial work with MyDoggy, and I have come away quite impressed.  I would very much like to see this be a well supported part of Desktop (perhaps a second alternative to a single window type application).



I agree with the comments in the forum posting about service locator and factory patterns.  There is certainly a place for factory patterns, but I think that they should be approached with a great deal of caution, and all other options exhausted before their use.  My personal experience is that Factory is appropriate in small, relatively well contained contexts.  When it starts being used as a central location for components to access other components, the Factory pattern tends to create artificial dependencies and the problems associated with that (issues with testing, code re-use, etc...).  The use of SL and Factories in NetBeans is one of the prime reasons that we have chosen not to work with that platform - the NB platform works, but it tends to result in messy, messy code - and refactoring of the core architecture is almost impossible.

Before I write the next paragraph (outlining an effective alternate to the Factory pattern), I want to be sure that I state my position on OSGi/modules/etc... so I don't get branded as just another OSGi proponent:

1.  I think that the concept of bundles/code modules is a very good one - it's a discipline that leads to better quality code, and more thoughtful design of large systems.  Even if an app isn't running inside an OSGi type container, the underlying principles of the module idea can still be used and applied (though not necessarily *enforced* by the container).
2.  I do not think that Spring Desktop should be dependent on the use of OSGi
3.  I can easily see projects of mine that would benefit from an OSGi (or equivalent) container, but I also see plenty where that would just be overhead that I'd prefer to avoid.  Equinox can be deployed in less than 1 MB, but if you don't need it, then you don't need it.  I think that the Spring container may be able to provide the required capability to get the same benefit via dependency injection (hopefully while leaving the door open to using OSGi for projects that want it).

OK, with the above caveats in place, here is an alternative to the Factory pattern (or the singleton pattern such as used by Application.instance()):

An alternative approach to factories and lookups is suggested by whiteboarding (and I think that OSGi provides a very nice mechanism for this - esp. when coupled with Spring OSGi).  A couple of articles explaining this approach in OSGi are here (the knopflerfish article is quite good, providing hard code contrasts between the service lookup and whiteboarding approaches):

http://www.knopflerfish.org/osgi_service_tutorial.html
http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf


The difference in the two patterns is subtle (one is pretty much the exact reverse of the other) - but I think that whiteboarding is much more in keeping with the principle of IOC.  The thing that I find most interesting about whiteboarding is that any and all complexity associated with the relationship between two sub-systems is placed on the shoulders of the service *consumer* instead of the service *provider*.  In the case of the Desktop framework, this means that the complexity will be captured in the framework itself, and users of the framework will have minimal (if any) special requirements.  This, I believe, is the purpose of any well designed framework:  to minimize the amount of boilerplate code required by the users of the framework.  To be as unobtrusive as possible, and to create an environment where it is difficult for the user of the framework to shoot themselves in the foot.



One very simple example of where this design decision becomes important is in the development of an Action framework.  Many actions need to work on the current selection of one (or maybe multiple) elements in the GUI.  A simple approach is to have the action, when invoked, grab a some singleton that ultimately holds the current selection and request the current selection from it.  However, this precludes the ability of dynamically disabling the action, etc...  The solution to this is typically to register a listener on the current selection, and update the action state dynamically.  This works (although writing all of the listeners is a total hassle) - But this design is not a good design in the general case - specifically, it creates a nightmare for testing b/c you can't call the action without having the entire 'current selection' infrastructure mocked up and in place.  Also, this approach removes the possibility of having actions that are sensitive to selection in multiple areas of the application.

A different approach is to have a property on the action that accepts a list of objects that it should work on.  The application framework is configured declaritively to define the types of selections/etc... that the action can respond to, and the framework itself takes care of setting that property on the action as the application state changes.  Note that the aspect of the framework that even tracks 'current' selection could be completely different (in a very simple app, it could just be the selection model in a listview.  In other cases, it might be a SelectionList from GlazedLists - or maybe a rule based collection of the above plus others).  The point is that this approach completely separates the concern of performing actions from selection of which objects to act against.

One could envision collections of actions (perhaps via a mechanism similar to JSR 296's approach - if not exactly that approach) that allows for an intelligent ActionMap that is able to respond to changes in current selection to drive when different context menu actions should appear, which command bars should show, etc...




I think that's enough for now - I have a ton of other thoughts on bindings and where it fits into the overall picture (I think there is a tendency to use bindings just in the context of a single form ala the Presentation Model pattern, but I think that the utility of the bindings pattern may be much greater than that), Presentation Model pattern for dialogs, etc...


I look forward to any and all comments and thoughts!

- K


----------------------- Original Message -----------------------
 
From: Jan Hoskens <jh...@sc...>
To: <spr...@li...>
Cc: 
Date: Sat, 21 Jun 2008 12:43:31 +0200 (CEST)
Subject: Re: [Springframework-rcp-dev] Spring RCP/Desktop
 
For some reason, Lieven couldn't get the mail on the dev list. So I'll
post the link to the user forum where he finally put the message:

http://forum.springframework.org/showthread.php?t=56225

Are there any other users experiencing problems with the list?

Kind Regards,
Jan