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: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] 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 Good one! It would make sense for the annotation processor the go down the class structure. Why not? On Fri, Sep 6, 2013 at 5:16 PM, Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx> 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 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. I send you the editor chapter is a private mail. It also an example for a multiple editor implementation (which is not yet online). 2013/9/6 Angelo zerr <angelo.zerr@xxxxxxxxx> 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. >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 { public void createControls(Composite parent) { Button button = new Button(parent, SWT.PUSH); button.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { ------------------------------------------------------------------ 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 { protected MDirtyable dirty; 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() { public void widgetSelected(SelectionEvent e) { ------------------------------------------------------------------ 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). 2013/9/6 Wim Jongman <wim.jongman@xxxxxxxxx> 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. On Fri, Sep 6, 2013 at 4:07 PM, Lars Vogel <lars.vogel@xxxxxxxxx> wrote: Hi Angelo, I'm not sure if I understand your question correctly. Dirty and focus is handled via the application model. 2013/9/6 Angelo zerr <angelo.zerr@xxxxxxxxx> 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 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. _______________________________________________ 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
|