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
From: Tom Schindl <[email protected]>
To: E4 Project developer mailing list <[email protected]>,
Date: 09/08/2013 04:16 PM
Subject: Re: [e4-dev] What about E4 Editor?
Sent by: [email protected]
Von meinem iPhone gesendet
Am 08.09.2013 um 21:44 schrieb Wim Jongman <[email protected]>:
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
Best regards,
Wim
[1]
http://industrial-tsi-wim.blogspot.nl/2013/08/a-giant-leap-for-eclipse-rcp.html
** removed the rest of the thread to save the whales **
_______________________________________________
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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
