Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] What about E4 Editor?

Like Tom I've never heard of the @dirrty annotation...MParts inherit MDirty which is what we currently use to keep track of the dirty state of a part.

The main problem with trying to re-use the existing legacy code (i.e. TextEditor) is that it's tightly would up in all the other 3.x API. This is partly because of the 3.x 'framework' architecture where just getting to some common service *requires* that TexrEditor reference PlatformUI...and then you're doomed because if you follow the API referenced through it recursively you end up with almost all the core platform.

We've always had the 'plan' to start migrating legacy parts over to pure e4 implementations but even something as simple as 'porting' the ErrorLog view (the view with the fewest dependencies we could identify) turned out to be far more problematic than we anticipated since it's tied into preference stores... It's because of this that we've decided to initially spend the effort removing obstacles from using legacy parts in primarilty e4 RCP apps rather that to try to break the web of dependencies that exist in the current 3.x code. This is Wim's 'mixed-mode' where most of the app is just a simple e4 RCP app but you can 'embed' a 3.x view / editor into the UI.

I certainly agree that we need a viable story for supporting inheritance in e4 so that something as valuable as TextEditor can be re-used. Even here I'm starting to wonder whether 'inheritance' is the best way to code it up when we're already in DI-land. The same way DI allows POJOs for just about everything why wouldn't a DI-style 'inheritance' just be a reference to some other annotated POJO ?

Onwards,
Eric


Inactive hide details for Tom Schindl ---09/08/2013 04:16:37 PM---Von meinem iPhone gesendet Am 08.09.2013 um 21:44 schrieb WimTom Schindl ---09/08/2013 04:16:37 PM---Von meinem iPhone gesendet Am 08.09.2013 um 21:44 schrieb Wim Jongman <wim.jongman@xxxxxxxxx>:


    From:

Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>

    To:

E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>,

    Date:

09/08/2013 04:16 PM

    Subject:

Re: [e4-dev] What about E4 Editor?

    Sent by:

e4-dev-bounces@xxxxxxxxxxx





Von meinem iPhone gesendet

Am 08.09.2013 um 21:44 schrieb Wim Jongman <wim.jongman@xxxxxxxxx>:

      I must play with E4 editor development. Doc is important but I think tooling is important too. It should be cool if we can have PDE templates like :

      * Plug-in with an E4 editor.
      * Plug-in with an E4 view.
      ...

    We have that. If you install the e4 tooling you can create an e4 application with a view. An editor just implements the @dirtyable annotation.

??? Never heard of this annotation all an editor has to do is to mark a method with @Persit
     

      I tell me if JDT, WTP etc have the intention to migrate to pure E4 API?

      With 3.x, we have base class EditorPart and IDE provides TextEditor which extends EditorPart. After that a lot of Plug'In can extends TextEditor like JDT with JavaEditor, WTP with StructuredTextEditor, etc..
      With 4.x, if I understand, the idea is to use annotation and not base class. If we have not base class, it means that each Plug-in will implement TextEditor-like? Or perhaps the idea is just to provide a TextEditor (a simple Pojo)?

    Obviously, we want to write TextEditor only once. Naturally you want to reuse this implementation.

    However, in pure Eclipse 4, we do not use the org.eclipse.ui bundle. EditorPart sits in the heart of org.eclipse.ui so there is a little problem.

    You have to pull in the compatibility layer until the complete editing framework has been rewritten to use pure Eclipse 4. I don't think that this will happen in the near future. AFAIK no one is working on this at the moment and frankly you can just forget that everyone will convert to pure E4. Having a solid CompatLayer and a solid "mixed-mode" solution is therefore the only way to reuse all the existing stuff.

    So if you want to include your TextEditor based editor in your RCP on top of pure E4 code then you will be committed to use the "mixed-mode" scenario. Parts of your code uses the old framework and parts use the new DI based framework. There is nothing wrong in that. The Eclipse IDE does this as well. In Luna M1 the platform team have just reached a major milestone to allow the definition of an E4 view inside a CompatLayer Eclipse [1]

    If your editor just depends on EditorPart then there is a different story because EditorPart can be quite easily rewritten to pure Eclipse 4. However, since pure Eclipse 4 does not work with the *Advisor classes any more, saving and restoring state is up to you until the time the e4 project provides something generic.

It does that already just annotate a method with @PersitState

Tom

GIF image

GIF image

Back to the top