Re: [Springframework-rcp-dev] [spring-desktop] Re: [Desktop] @Command style

[Peter De B. <pet...@gm...>]

Okay! It's time to crank out some code. I'll see what I can do this weekend
(we have the national holiday on monday in Belgium, so it's a long weekend
for me), and I'll get back to you tuesday.

I'll commit my code to the resource-injection branch.

regards,

Peter

On Fri, Jul 18, 2008 at 9:23 PM, Kevin Day <ke...@tr...> wrote:

>  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.
>
>>
>> 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.
>>
>
> KD - very nice.  Sounds like it's just the thing.
>
>
>>
>> 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.
>>
>>
>> When your object is a spring managed bean, it has a name, so that can be
>> used.
>>
> KD - I was thinking along these lines as well.  The meta data is associated
> with the object by spring.
>
>
>>
>>
>> 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:
>>
>>
>
>   If we create a custom BeanPostProcessor, then the injection can be
> triggered from there. This would handle all spring managed beans (views,
> actions, ...)
>
>   for all other cases, the resource injection will have to be called
> manually.
>
>
>  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).
>
> 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.
>
>
>
>>  Create object
>> Register the object with the service manager (possibly with an
>> optional name/id property specified???)
>> Service manager notifies listeners that an object of class Foo has been
>> registered
>> 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
>>
>>
>
>  What do  you mean by "Service manager"?
>
> 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.
>
> 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?).
>
> 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...
>
> 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.
>
> 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.
>
>
>
>>
>> There's still the trick of locating the service manager - perhaps a
>> discussion for another post...
>>
>> - K
>>
>>
>>
>>
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>