[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Injecting 3.x Views/Editors
|
I agree that the use of executable extensions are less desirable, and it should be integrated into the ConfigurationElement (or more appropriate) because having API methods called automatically is a little scary. But it is not possible for me to use DIViewPart/EditorPart because I extend from "FileDiagramEditorWithFlyoutPalette" in the gmf runtime, which does not extend from DIEditorPart.
My thoughts were to *forcibly* inject the workbench parts, a like it or not approach. By modifying the class template at runtime to include annotations like @Creatable / @Focus / @Inject (const & createpart) we can use the API to our advantage. Most importantly, annotations will not break binary compatibility. Thus, it doesn't matter if they want to be injected or not; if there are any parameters for the constructor we can just place them in a temporary static context and then inject away.
By forcibly injecting the workbench parts, all workbench events (like focus and persist) can be dispatched through the E4 plumbing. The advantage is any direct/manual calls to API methods from client code would continue to function as normal since binary compatibility has been maintained. The only catch is that all client generated events and hooks would have to be picked up and sent into the E4 plumbing and not the old API (avoid double dispatching), but this should be relatively straight forward to accomplish.
The same approach of forcibly injecting workbench parts should work for all 3.x legacy parts (like action sets / handlers / etc..) that have been replaced by modeled elements and injectable api. It would even be possible to "decorate" the 3.x legacy parts and provide a hybrid element that extends from the 3.x legacy part and implements the e4 model interface. The implementation of the e4 model element would come from a model element created from the relevant factory and a bridge to the interface methods.
I don't know if this is counter to the current direction of the compatibility layer, but by forcibly injecting the 3.x components and using the old API to our advantage there would be no distinction between the 3.x and 4.x components (truly seamless). The end user of the workbench would have to change 0 lines of code (in theory) in order to start using the new workbench features and could even intermix 3.x & 4.x components in the same bundle if they so pleased. IMO, forcibly injecting is the best answer because it gives the greatest amount of flexibility for the smallest amount of existing code change.
Those are my thoughts at least
JD
On Fri, Aug 24, 2012 at 10:13 AM, Eric Moffatt
<emoffatt@xxxxxxxxxx> wrote:
We should avoid using 'ExecutableExtension'
where we can...it's 'old school' and unnecessary when there's a DI engine
available. The main difference is that 'createExecutableExtension' will
only call the class's constructor (then it usually calls some API-defined
'init' method).
We want to go the other way IMO; allow
the existing EP's 'class' specifications to be defined in a way that allows
them to be created through injection directly (even though the class spec
is defined in the extension). For the most part this would mean either
checking for the particular API spec for the extension (i.e. views must
implement IViewPart) or by checking the specified class for annotations.
If both exist (i.e. some part implementation that will run in both e4 and
3.x) then my preference would be that DI wins because it's the preferred
mechanism and the author of the class had to know about both approaches
in order to get into this state.
Eric
I explicitly decided against using ExecutableExtension
when I designed
the e4-bridge but what you duplicated here is exactly what the e4 bridge
does already since some time with DIViewPart and DIEditorPart.
Tom
Am 24.08.12 03:40, schrieb Joseph D Carroll Jr:
> After a brief conversation with Paul on IRC, I hacked together a
> solution for grabbing the WorkbenchContext in a 3.x application. (See
> attached)
>
> It is clearly a hack, would be better to use a lifecycle hook. But
this
> allowed me to create an injector for all of my 3.x editors and views.
> Obviously there are things that cannot be injected even though
it would
> be possible (like the composite), but I am able to inject things like
> properties. While I haven't tested it, I have a feeling that
it *could*
> be possible to inject methods like @Focus.
> (It also gives me all the goodies like Logger and NLS injected!)
>
> I am building an application that uses a diagram editor from GMF,
thus I
> have to use 3.x editors. But with a little more finessing, I
think this
> would be a good option for 3.x & 4.x interoperability in the compat
> layer. I am just getting started on this application so maybe
something
> like this already exists and I just missed it. But I thought
I would
> share...
>
> (The source files are attached)
> - I created an abstract class "InjectableExecutableExtensionFactory"
> that defines the base functionality
> - From this I extend to a "BlockDiagramPartFactory" that
is capable of
> supplying the specific contexts for injection and anything else
> - Then whether old or new classes, just annotate them with @Creatable
> and any @Inject's
> - Lastly, when I create my view/editor extension point, invoke the
> extension factory. The factory is capable of providing context
for
> specific classes or passing them through with no added context.
>
> <plugin>
> <extension
> point="org.eclipse.ui.editors">
> <editor
>
> class="braintrader.blockdiagram.ui.parts.BlockDiagramPartFactory:braintrader.blockdiagram.ui.blockdiagrameditor"
> default="false"
> id="braintrader.blockdiagram.ui.blockdiagrameditor"
> name="Block Diagram
Editor">
> </editor>
> </extension>
> <extension
> point="org.eclipse.ui.views">
> <view
>
> class="braintrader.blockdiagram.ui.parts.BlockDiagramPartFactory:braintrader.blockdiagram.ui.view.blocklibrary"
> id="braintrader.blockdiagram.ui.view.blocklibrary"
> name="Block Library"
> restorable="true">
> </view>
> </extension>
> </plugin>
>
> Whether or not this is actually useful / beneficial, I don't know.
But
> this is going to be my approach for now, presuming I don't run into
any
> major road blocks.
>
>
> Take care,
>
> JD
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
--
B e s t S o l u t i o n . a t
EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax
++43 512 935833
http://www.BestSolution.at
phone
++43 512 935834
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
