@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 <[email protected]>

> @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 Angelo
>
>
> 2012/8/29 Eric Moffatt <[email protected]>
>
>>
>> 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
>>
>>
>>
>>  From: Angelo zerr <[email protected]> To: E4 Project developer
>> mailing list <[email protected]> Date: 08/29/2012 08:43 AM Subject: Re:
>> [e4-dev] How to use E4 DI with Wizard,Dialog and FormEditor? Sent by:
>> [email protected]
>> ------------------------------
>>
>>
>>
>> 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 <*[email protected]* <[email protected]>>
>> 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
>> *<http://www.vogella.com/articles/EclipseRCP/article.html#ownobjects_diinto>
>>
>> Best regards, Lars
>>
>> 2012/8/28 Angelo zerr <*[email protected]* <[email protected]>>:
>> > 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 
>> > <*[email protected]*<[email protected]>
>> >
>> >>
>> >> 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
>> *<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
>> >> > *[email protected]* <[email protected]>
>> >> > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<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* <%2B%2B43%20512%20935833>
>> >> *http://www.BestSolution.at* <http://www.bestsolution.at/>
>>            phone    *++43 512 935834* <%2B%2B43%20512%20935834>
>> >> _______________________________________________
>> >> e4-dev mailing list
>> >> *[email protected]* <[email protected]>
>> >> *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev>
>> >
>> >
>> >
>> > _______________________________________________
>> > e4-dev mailing list
>> > *[email protected]* <[email protected]>
>> > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev>
>> >
>> _______________________________________________
>> e4-dev mailing list*
>> **[email protected]* <[email protected]>*
>> **https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev>
>> _______________________________________________
>> e4-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>>
>
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev

Reply via email to