There are many different cases… base classes vs interfaces, methods vs fields vs types. Java default getAnnotation() semantics differs across these.
The bottom line, if you aren’t happy with default getAnnotation() semantics for a particular scenario, you don’t have to accept it. - Konstantin From: [email protected] [mailto:[email protected]] On Behalf Of Tom Schindl Sent: Friday, September 06, 2013 8:34 AM To: E4 Project developer mailing list Cc: E4 Project developer mailing list Subject: Re: [e4-dev] What about E4 Editor? Who says annotations are not called on base classes which would be simply wrong because this works as expected. Tom Von meinem iPhone gesendet Am 06.09.2013 um 17:27 schrieb Wim Jongman <[email protected]>: Good one! It would make sense for the annotation processor the go down the class structure. Why not? Regards, Wim On Fri, Sep 6, 2013 at 5:16 PM, Konstantin Komissarchik <[email protected]> wrote: No stake in the particular topic in question, but I do want to clarify the statement regarding annotations… > the problem is that annotations are not inherited Java semantics on annotation inheritance are only relevant when it comes to describing semantics of the built-in lookup methods, such as Class.getAnnotation(). There is nothing stopping a framework that processes the annotation from implementing its own semantics and in fact many frameworks do just that. All you need to do is traverse the type hierarchy, collect the relevant annotations and apply your own rules on shadowing and merging, depending on what’s appropriate for the annotation in question. Thanks, - Konstantin From: [email protected] [mailto:[email protected]] On Behalf Of Lars Vogel Sent: Friday, September 06, 2013 7:59 AM To: E4 Project developer mailing list Subject: Re: [e4-dev] What about E4 Editor? Hi Angelo, the problem is that annotations are not inherited, hence such a base class would not be very useful. Inheritance of annotations works only for class annotations AFAIK. See http://docs.oracle.com/javase/7/docs/api/java/lang/annotation/Inherited.html http://stackoverflow.com/questions/4745798/why-java-classes-do-not-inherit-annotations-from-implemented-interfaces I send you the editor chapter is a private mail. It also an example for a multiple editor implementation (which is not yet online). Best regards, Lars 2013/9/6 Angelo zerr <[email protected]> Hi Lars, Eric, Wim, Many thank's for your answer! > I think Angelo wants some base class which already implements dirty, focus, > memento, save as, issaveasallowed, editor input, etcetera. An editor that is > uniform to workbench requirements and that plays along well with the 3.x > editor lifecycle. Exactly! >I'm not sure why you think it's necessary to have a base class though; we >already handle focus and dirty etc through the model. When you are newbie to develop some editor with E4 (as me), it's difficult to know how to start (except if you read tutorial of Lars:)). I think if E4 provides some framework by providing some base class, it should be easier. Takes a basic sample of Lars tutorial : ------------------------------------------------------------------ public class MySavePart { @Inject MDirtyable dirty; @PostConstruct public void createControls(Composite parent) { Button button = new Button(parent, SWT.PUSH); button.addSelectionListener(new SelectionAdapter() { @Override public void widgetSelected(SelectionEvent e) { dirty.setDirty(true); } }); } } ------------------------------------------------------------------ In this sample you need to declare MDirtyable with @Inject and createControls with @PostConstruct. If you are newbie, you can forget to set the well annotation. If E4 provides a base class like this : ------------------------------------------------------------------ public abstract class BasePart { @Inject protected MDirtyable dirty; @PostConstruct public abstract void createControls(Composite parent); } ------------------------------------------------------------------ After you could implement like this : ------------------------------------------------------------------ public class MySavePart extends BasePart { public void createControls(Composite parent) { Button button = new Button(parent, SWT.PUSH); button.addSelectionListener(new SelectionAdapter() { @Override public void widgetSelected(SelectionEvent e) { dirty.setDirty(true); } }); } } ------------------------------------------------------------------ It's a basic example, but if E4 doesn't provide this BasePart class, I think each people will create that to avoid duplicate the code. But perhaps I'm wrong. @Lars : it should be fantastic if you can send me the part about the editor of your chapter. I will follow you to buy it as soon as it will available (I have already the first edition). Regards Angelo 2013/9/6 Wim Jongman <[email protected]> I think Angelo wants some base class which already implements dirty, focus, memento, save as, issaveasallowed, editor input, etcetera. An editor that is uniform to workbench requirements and that plays along well with the 3.x editor lifecycle. Cheers, Wim On Fri, Sep 6, 2013 at 4:07 PM, Lars Vogel <[email protected]> wrote: Hi Angelo, I'm not sure if I understand your question correctly. Dirty and focus is handled via the application model. Best regards, Lars 2013/9/6 Angelo zerr <[email protected]> Hi E4 Team, I know this topic comes from every time, but I would like to know what is the sate of E4 Editor. My project CodeMirror-Eclipse <https://github.com/angelozerr/CodeMirror-Eclipse> provides Eclipse 3.x EditorPart, but I would like to provide too Eclipse 4.x Editor. I would like to avoid developping my own Pojo class like ModelEditor. E4 provides the capability to manage your editor with Pojo, it's a great feature, but IMHO I think E4 should provide an abstract class for editor like EditorPart which manages dirty, focus, after that E4 could provide TextEditor class and a lot of project (JDT Java editor, WTP XML editor, etc) could migrate to a pure E4 code (but I don't know if it's the goal of E4 to remove 3.x EditorPart, View in the future?). Many thank's for your help. Regards Angelo _______________________________________________ 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 _______________________________________________ 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
