[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] How to use E4 DI with Wizard,Dialog and FormEditor?
|
@Angelo: IMHO editor support handling in Eclipse 4 need some improvements, that the reason why I did not cover it deeply. For example AFAIK you need to manually manage the already open editors. I have a small writeup and editors but didn't want to put it into the book as I believe there are plans to improve editor handling in Eclipse 4.3:
http://www.vogella.com/articles/Eclipse4Editor/article.html
2012/8/29 Angelo zerr
<angelo.zerr@xxxxxxxxx>
@Lars : I will try to post a comment on amazon. I think your book is very good, the explanation about parts is very good, but it is explained with basic sample (just an UI with some SWT widgets). Editor is very important I think in an Eclipse application and I have not found information about pure e4 editor (that's why my post).
@Eric : many thank's for your post. If I understand it should be better not to use 3.x EditorPart, FormEditor, etc if I wish develop a pure e4 RCP Application. So I think it should bif e4 provides some abstract class editor. My idea is to provides
E4EditorPart which looks like to EditorPart but without 3.x dependencies, E4MultiPageEditorPart which looks like to MultiPageEditorPart without 3.x dependencies, E4FormEditor which looks like to FormEditor without 3.x dependencies etc...
What do you think about this idea?
Regards Angelo2012/8/29 Eric Moffatt
<emoffatt@xxxxxxxxxx>
Angelo, re-using an existing editor
(or view) implementation is not just a matter of using DI but more one
of removing dependencies in the underlying implementation to legacy classes
like IWorkbench[Window | Page]. Only once the part has been refactored
to remove these dependencies does it make sense to host it in an e4 RCP
app (otherwise you'll get the whole compat layer). Then we still face the
issue of having *that* implementation run under 3.x...defining some sort
of pattern for how to do this (perhaps with changes on the 3.x side to
help support it) would be a great way to pave the path.
JD has already made a cut at trying
to allow some of the common views to be hosted in e4 apps and will post
his findings soon. My point is really that moving parts out from under
the legacy API is apt to require significant changes to the existing code
and that making the resulting implementation also work in 4.x
The idea of injecting existing parts
has been discussed but if the part is meant to work in both 3.x and 4.x
then there's really little advantage since it would have to work in the
non-DI case (3.x). Extending 4.x to directly host e4 parts is *much* easier
but doesn't seem to be what you are aiming for...
I too wish this were easier but I'm
not sure that there's a simple solution to extracting code out from under
the existing API but at least the mechanisms for doing it should be easy
to re-use for other parts.
Eric
Hi Lars,
Many thank's for your answer. I have seen that (because I'm reading your
famous book, very great:))
My question is how to manage editor with E4 like FormEditor which is used
too for PDE editor, WTP Server editor etc :
1) Use directly FormEditor (and extend it to have DIFormEdtor). The advatnage
with that is that I can use FormEditor code but it extends of deprecated
EditorPart. I suppose that 3.x EditorPart will be removed in the future?
2) Create from scratch an abstract class E4FormEdtor (a pojo) wich use
e4 annotations (@Focus, etc) and creates CTAbFolder, creates a FormToolkit,
etc like FormEditor.
Many thank's for your help.
Regards Angelo
2012/8/28 Lars Vogel <lars.vogel@xxxxxxxxx>
Hi Angelo,
if you create your Dialogs and Wizard instances yourself you could use
// Create instance of class
ContextInjectionFactory.make(MyDialogClass.class, context);
See here for a short description:
http://www.vogella.com/articles/EclipseRCP/article.html#ownobjects_diinto
Best regards, Lars
2012/8/28 Angelo zerr <angelo.zerr@xxxxxxxxx>:
> Hi Tom,
>
> Many thank's to have taking time to answer me. I would like migrate
our
> XDocReport Eclipse Application and our MongoDB IDE with e4 which uses
a lot
> of dialogs, wizards and FormToolkit FormEditor
> and so I tell me what is the best pratice to do that. I would like
having
> pure e4 code and not use 3.x bridge (I suppose this bridge will be
> deprecated in the future of e4, EditorPart, ViewPart will be deprecated
too,
> is that?).
>
> I have seen your ModelEditor code and I find there are a lot of code
that we
> could set in an abstract class editor (perhaps it's the "add
native support
> for editors " that you told me.
> So I tell me if e4 could provide some abstract class for Editor (Editor
with
> multi-page, Editor with FormToolkit etc..).
> I understand the e4 idea with Part is to use Pojo with annotations
(@Focus,
> etc) but I think it should be cool if e4 provides those abstract class
for
> Editor (you use it or not).
>
> 2012/8/27 Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
>>
>> When you talk about wizards, which wizards do you talk about?
Those
>> configured using extension points or custom ones? If it is the
latter
>> you can use DI using ContextInjectionFactory in your custom code.
>
>
> I talk about the 2 wizards kind. In our application we use DI with
> wizard+dialog with Spring DM to consume some OSGi services.
> For instance if you see
> http://code.google.com/p/xdocreport/source/browse/dynaresume/org.dynaresume.eclipse.ui/plugin.xml?repo=eclipse
>
> I declare a dialog (and wizard) like editor :
>
> <extension
> point="fr.opensagres.xdocreport.eclipse.ui.dialogFactories">
> <factory
> id="org.dynaresume.eclipse.ui.dialogs.SearchResumeDialog"
>
> class="org.eclipse.springframework.util.SpringExtensionFactory:searchResumeDialog"
> title="%SearchResumeDialog.title"
>
> </factory>
> </extension>
>
> (I have created an extension point for that). So I tell me how to
manage
> that with e4?
> It seems ContextInjectionFactory that you suggested me, is the solution.
>>
>>
>> Same goes for dialogs although those are always custom code and
you use
>> ContextInjectionFactory.
>>
>> Same goes for editors but they are not yet available in e4 and
you need
>> to use the compat layer there at the moment. Take a look at the
>> model-editor which uses DI for implementating an editor and dialogs.
>>
>> Final note: We plan to provide Wizards, Dialogs are part of the
>> Application Model in 4.3 and add native support for editors in
e4
>> applications.
>
>
> Cool! What do you mean with native support for editors? You wish provides
> some abstract class editor?
>
> Regards Angelo
>>
>>
>> Tom
>>
>>
>> Am 27.08.12 01:13, schrieb Angelo zerr:
>> > Hi E4 Team,
>> >
>> > E4 provides DI which is really great, but it seems working
just with
>> > Part (perhaps I'm wrong, I'm a newbie). I tell me how to
we can benefit
>> > from DI with
>> >
>> > * wizard
>> > * dialog
>> > * editor.
>> >
>> > How to manage that with E4 (create Addon, etc) ?
>> >
>> > When I say "editor", I would like to use FormToolkit
to have a Part like
>> > FormEditor (like PDE editor).
>> > Is EditorPart (FormEditor extends EditorPart) are depreceated
in E4? If
>> > yes, how to manage the same think than FormEditor with e4?
>> >
>> > Perhaps, e4 should to provide some classes like EditorPart,
>> > MultiPageEditor, FormEditor?
>> >
>> > Many thank's for your answer.
>> >
>> > Regards Angelo
>> >
>> >
>> > _______________________________________________
>> > 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
>
_______________________________________________
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
_______________________________________________
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