Menu
▾
▴
Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] @Command style
|
From: Kevin D. <ke...@tr...> - 2008-07-18 19:23:44
|
<!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> <DIV dir=ltr>Comments below with my initials. My lack of deep experience with Spring is probably making me bring up points that I shouldn't be - my apologies! Hopefully there's some wheat in the chaffe.</DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="MARGIN-RIGHT: 0px"> <DIV><BR>We can do this using PropertyEditors (the conversion mechanism used by Spring). That way you can auto inject icons/images/text/..., in fact anything that can be translated by a registered PropertyEditor.</DIV></BLOCKQUOTE> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>KD - very nice. Sounds like it's just the thing.<BR> </DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><FONT face=Arial size=2> <DIV></DIV> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <DIV> </DIV> <DIV>As I see it, the trick to auto-injection of resource properties is always in determining the object ID. For JComponents, we can use the name property. For actions that are created from annotations, we can create a name or id property on the generated action. For the general case, if the resource injection is the same for all instances of a given class, then an id can be specified in an annotation on the class. For object instances that need to have different resource injection, some form of id/name property will be required - OR the object will need to be registered in such a way that id/name meta data can be associated with the object.</DIV></BLOCKQUOTE></FONT></BLOCKQUOTE> <BLOCKQUOTE class=gmail_quote dir=ltr style="MARGIN-RIGHT: 0px"> <DIV><BR>When your object is a spring managed bean, it has a name, so that can be used.<BR></DIV></BLOCKQUOTE> <DIV class=gmail_quote dir=ltr>KD - I was thinking along these lines as well. The meta data is associated with the object by spring. </DIV> <DIV class=gmail_quote dir=ltr> </DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><FONT face=Arial size=2> <DIV></DIV> <DIV> </DIV> <DIV> </DIV> <DIV>The bigger design question on all of this is how to get those resources injected automagically. Right now JSR 296 requires explicit injection calls - and the temptation to put those calls directly into the object itself via the Application singleton is high. I've already seen that the Jigloo GUI builder does this. This may be one of those scenarios where whiteboard comes into play:</DIV> <DIV> </DIV></FONT></BLOCKQUOTE> <DIV class=gmail_quote dir=ltr><BR> If we create a custom BeanPostProcessor, then the injection can be triggered from there. This would handle all spring managed beans (views, actions, ...)<BR><BR> for all other cases, the resource injection will have to be called manually.</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr> <DIV class=gmail_quote dir=ltr>KD : I'm thinking about situations where a newly created object could be registered with the framework ( as opposed to having the framework create the object in the first place). It's something of a middle ground between the pure spring IOC approach (i.e. do not expose the framework at *all* into the application) and the current rcp approach (which has lots of artificial dependencies exposed via the Application singleton).</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>Instead of requiring manual resource injection (and manual selectionProvider injection, and manual XXX injection, etc...), the whiteboard pattern (more on that below) suggests reversing the problem by having the object get generically registered once. Then have registration listeners take care of processing the object as they need to.</DIV><BR> </DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV><FONT face=Arial size=2> <DIV></DIV> <DIV>Create object</DIV> <DIV>Register the object with the service manager (possibly with an optional name/id property specified???)</DIV> <DIV>Service manager notifies listeners that an object of class Foo has been registered</DIV> <DIV>A resource injector service (which set itself up to listen for registration of classes that it should be doing injections for) gets notified, and does it's work</DIV> <DIV> </DIV></FONT></DIV></BLOCKQUOTE> <DIV class=gmail_quote dir=ltr><BR> What do you mean by "Service manager"?</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>KD: This is a part of the whiteboard pattern - using a centralized object registration system that provides a listener interface so that other objects can learn about objects as they are registered and deregistered. This is something like the BeanPostProcessor - but allows for dynamic processing of objects. My understanding is that BeanPostProcessor is targeted at *configuration* of a given object soon after it is constructed by the Spring framework. The whiteboard approach would treat configuration of the object as just one of many services that might be interested in a newly registered object.</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>One service may do resource injection (which is just part of initial configuration, and could be done with bean post processing - but why not just have the post processor register the bean with the service manager and be done with it?).</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>Another service could do action injection into views (this opens the possibility of dynamically creating a view in code instead of having to use a named object specified in an external configuration file). This could be done using BeanPostProcessor. Although how do we handle situations where we want several views of the same class, but each having different actionmaps and/or beans associated with them? Maybe a bean editor view where the user is able to open up dialogs for each of 5 or 10 or 15 beans that they've selected...</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>Another service may track current global selection by listening for registration of objects that expose a 'selectionProvider' interface. This is outside the scope of initial configuration, altogether.</DIV> <DIV class=gmail_quote dir=ltr> </DIV> <DIV class=gmail_quote dir=ltr>This starts to create a situation where Spring IOC is used primarily for configuring the registration listeners, then registering objects that are initially created by the framework. But it does not preclude the possibility of new objects being created and registered (and unregistered), and manual creation (and removal) of registration listeners as the application runs.</DIV> <DIV class=gmail_quote dir=ltr><BR> </DIV> <BLOCKQUOTE class=gmail_quote dir=ltr style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> <DIV><FONT face=Arial size=2> <DIV></DIV> <DIV> </DIV> <DIV>There's still the trick of locating the service manager - perhaps a discussion for another post...</DIV> <DIV> </DIV> <DIV>- K<BR></DIV> <DIV> </DIV></FONT> <DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma"> <DIV class=Ih2E3d> <DIV><FONT face=Tahoma size=2><BR><BR> </DIV></DIV></DIV></DIV></BLOCKQUOTE></FONT></BODY></HTML> |
