Eclipse Community Forums: Eclipse 4 » Using Factories in Class URI for Parts

Help

Home

Home » Eclipse Projects » Eclipse 4 » Using Factories in Class URI for Parts(Rendering Parts from Model )

Show: Today's Messages :: Show Polls :: Message Navigator

Using Factories in Class URI for Parts [message #870886]

Thu, 10 May 2012 07:31

Felix Heppner

Messages: 3
Registered: May 2012

Junior Member

Hi E4 world,

I am currently getting my first experiences with E4 and the application model and trying to figure out what still may work the 3.x and possibly the "spring" way and what may not and possibly what should not work anymore.

Im my 3.x RCP applications I normally use something like org.eclipse.springframework.util.SpringExtensionFactory:myBeanName in class attributes in plugin.xml for views and handlers to create these using Spring DI. Eclipse detects that the class is an ExtensionFactory and uses the factory to create the actual view or handler. Is there a similar way and/or factory interface for parts in the E4 model? I can think of some useful cases where I still want my part to be created using spring application context although E4 DI will likely the reduce the need. But Spring still provides some possibilites for intercepting call using proxies for injected objects, easy remoting, jmx export and the like what is pretty useful in many cases.

Regards

Felix

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870895 is a reply to message #870886]

Thu, 10 May 2012 07:57

Lars Vogel

Messages: 1098
Registered: July 2009

Senior Member

Hi Felix,

can you try the following solution and let me know if it works:

http://pastebin.com/zZ2Lish0

Cheers, Lars

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870896 is a reply to message #870886]

Thu, 10 May 2012 07:55

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Am 10.05.12 09:31, schrieb Felix Heppner:
> Hi E4 world,
> I am currently getting my first experiences with E4 and the application
> model and trying to figure out what still may work the 3.x and possibly
> the "spring" way and what may not and possibly what should not work
> anymore.
>
> Im my 3.x RCP applications I normally use something like
> org.eclipse.springframework.util.SpringExtensionFactory:myBeanName in
> class attributes in plugin.xml for views and handlers to create these
> using Spring DI. Eclipse detects that the class is an ExtensionFactory
> and uses the factory to create the actual view or handler. Is there a
> similar way and/or factory interface for parts in the E4 model? I can
> think of some useful cases where I still want my part to be created
> using spring application context although E4 DI will likely the reduce
> the need. But Spring still provides some possibilites for intercepting
> call using proxies for injected objects, easy remoting, jmx export and
> the like what is pretty useful in many cases.

No e4 does not support such a delegation pattern but I think a possible
solution is that you invent your own annotation - let us call it
@SpringBean and then you would write injection code like this:

public class MyPart {
@Inject
@SpringBean("mybean")
private MyBean bean;
}

There is some code and slides around from myself showing how one creates
custom annotations.

Code:
http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/tree/bundles/org.eclipse.e4.tools.services
Slides:
http://tomsondev.bestsolution.at/2012/03/28/slides-from-eclipsecon-talks/ (Around
Slide 47)

Another interesting idea would be to allow the injection of a
IEclipseContext which knows the Spring-Context so that the context
hierarchy would look like this:

OSGI-Context
Spring-Context
Application-Context
Window-Context
....

where as today it is

OSGI-Context
Application-Context
Window-Context
....

Not sure such a brigde context is doable though and I have to admit that
I have no idea about spring and we'd have to provide a special hook to
allow the creation of such an intermediate root context.

Tom

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870898 is a reply to message #870896]

Thu, 10 May 2012 08:16

Lars Vogel

Messages: 1098
Registered: July 2009

Senior Member

@Tom is ExtensionFactory (without Spring) supported via the ApplicationModel? For example I don't specify the Part directly but use an ExtensionFactory to create the Part.

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870900 is a reply to message #870895]

Thu, 10 May 2012 08:21

Felix Heppner

Messages: 3
Registered: May 2012

Junior Member

Hi Lars,

thanks for the link. This does not work. The factory is created as the class for the part but the "magic" factory interfaces are not "detected" by the renderer. And so create and setInitializationData are not called.

Regards

Felix

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870915 is a reply to message #870900]

Thu, 10 May 2012 09:01

Lars Vogel

Messages: 1098
Registered: July 2009

Senior Member

@Felix: Lets see if Tom knows a trick to use ExtensionFactory directly. Otherwise you could define your own Renderer which would evaluate the class name and create the class accordingly.

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870919 is a reply to message #870898]

Thu, 10 May 2012 09:05

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

No how do you think this should work and even if it would you would base
your Part instance on the root OSGi-Context which is makeing even less
sense because fairly any stuff you'd expect to be there (e.g. a parent
Composite is not in this context!)

The other problem is that I don't see how this would solve Felix'
problem because he relies on the fact that Spring produces the instance
which would make it impossible e.g. to get the correct selection, the
event bus, ... and implement the lifecycle.

It has to be our DI engine that creates and manages the lifecycle of the
beans (well we could in theory allow Spring to create the instance and
then call our inject-method to attach it to our lifecycle - you can't
use constructor injection naturally then e.g. to get the composite but
use @PostCreate).

My suggestion simply helps bringing in DI information from Spring using
a specialized Object-Supplier. I guess one can look up DI informations
in the spring DI context somehow. Is it possible to e.g. find a value
that would be inject by it FQN? - as said I have no idea at all how
Spring works and what one can do with it.

Tom

Am 10.05.12 10:16, schrieb Lars Vogel:
> @Tom is ExtensionFactory (without Spring) supported via the
> ApplicationModel? For example I don't specify the Part directly but use
> an ExtensionFactory to create the Part.

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870921 is a reply to message #870919]

Thu, 10 May 2012 09:15

Lars Vogel

Messages: 1098
Registered: July 2009

Senior Member

@Tom: my question was unrelated to Spring. Can I use ExtensionFactory somehow directly in the ApplicationModel (without using Spring)?

I would like to have the option to create my parts with another class.

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870924 is a reply to message #870915]

Thu, 10 May 2012 09:21

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

As outlined in my reply this isn't so easy. If the instance is created
using another DI-Framework (Guice/Spring/...) you need to attach it to
our DI-Engine.

All information only available in our DI-Engine (e.g. the parent
Composite, ...) then can't be used in constructor injection.

In theory (that's really only theory!) our injection stuff is abstracted
in "IContributionFactory" so if you push another such factory in the
context you can control the creation instances.

An idea I've had is to bind the type of IContributionFactory to the
classprotocol you use.

bundleclass://.... => ReflectionContributionFactory
bundlejs://.... => ...
bundlespring://... => ...

IContributionFactory would get an OSGi-Service instead of directly
getting pushed in the root-context.

Tom

Am 10.05.12 11:01, schrieb Lars Vogel:
> @Felix: Lets see if Tom knows a trick to use ExtensionFactory directly.
> Otherwise you could define your own Renderer which would evaluate the
> class name and create the class accordingly.

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870929 is a reply to message #870921]

Thu, 10 May 2012 09:33

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Yes - by providing a specialized IContributionFactory.

As outlined in my other reply you could contribute (well infact you'd
push it root-context e.g. through a lifecycle handler) a custom
IContributionFactory which detects the IExecutableExtensionFactory
pattern, creates the instance through it and afterwards - and this is
the really important point - calls our DI-Engine to bind it to the
lifecycle.

As outlined it would be much nicer if IContributionFactory would be an
OSGi-Service which would allow you to replace it a lot easier.

Tom

Am 10.05.12 11:15, schrieb Lars Vogel:
> @Tom: my question was unrelated to Spring. Can I use ExtensionFactory
> somehow directly in the ApplicationModel (without using Spring)?
>
> I would like to have the option to create my parts with another class.
>
>
>
>

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870934 is a reply to message #870929]

Thu, 10 May 2012 09:47

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Damn - I like this idea. Let me poke around with it a bit and see what I
can come up with ;-)

We are already in RC1 so even the servicefying of IContributionFactory
won't make it in 4.2 but it's worth a try.

Tom

Am 10.05.12 11:33, schrieb Tom Schindl:
> Yes - by providing a specialized IContributionFactory.
>
> As outlined in my other reply you could contribute (well infact you'd
> push it root-context e.g. through a lifecycle handler) a custom
> IContributionFactory which detects the IExecutableExtensionFactory
> pattern, creates the instance through it and afterwards - and this is
> the really important point - calls our DI-Engine to bind it to the
> lifecycle.
>
> As outlined it would be much nicer if IContributionFactory would be an
> OSGi-Service which would allow you to replace it a lot easier.
>
> Tom
>
> Am 10.05.12 11:15, schrieb Lars Vogel:
>> @Tom: my question was unrelated to Spring. Can I use ExtensionFactory
>> somehow directly in the ApplicationModel (without using Spring)?
>>
>> I would like to have the option to create my parts with another class.
>>
>>
>>
>>
>

Report message to a moderator

Re: Using Factories in Class URI for Parts [message #870938 is a reply to message #870934]

Thu, 10 May 2012 09:55

Felix Heppner

Messages: 3
Registered: May 2012

Junior Member

Hi,

I like the idea with the extended context hierarchy because there is only one "injection step" with the combined context. The "3.x" style indirection could be plugged in ReflectionContributionFactory in a "dirty" way by checking whether the created contribution (round about line 102) in M7 is instanceof IPartFactory or whatever and then call setInitializationData (or the like) and then get the "real" contribution using a factory, and possibly attaching the instance to the context and lifecycle - although I did not get that part. I am looking forward for everything thats coming there and I will try to understand the concept of ContributionFactories and Contexts in more depth.

Thanks for the answers.

Felix

Report message to a moderator