I'm new to RCP and I'm trying to create a new View or Editor. At the current state I'm extending ViewPart.
The Layout I want to achieve is a SashForm where both sides have a CTabFolder. One of the sides of the SashForm is basically a MultiPageEditorPart. One of it's tabs should be an editor for a specific language with syntax highlighting and similar features. From what I understand I could extend AbstractTextEditor for that (and maybe use it as one tab of a MultiPageEditorPart).
If I try to achieve this layout with a ViewPart as top level container which contains a SashForm, I can't add an EditorPart to one of the sides of the SashForm. Of course I could implement this editor from scratch as Composite but I want to avoid that.
I am also willing to use an EditorPart or MultiPageEditorPart as top level container but then I'd have to find a way to get the SashForm layout working. The whole editor should be splited first and then each side should have tabs.
Does anyone have an idea how to solve this?
If anything is unclear please ask. I've got the feeling I've put this into words a little complicatedly.
I think you should just make a ViewPart that has a text editing component of some kind on the left, instead of trying to find a way to use an EditorPart. All that EditorPart is really buying you is dirty flag management and Save support; syntax highlight and so forth you can add to the text editing component yourself (I was surprised at how few drop-in text components I found while poking around the internet just now; I expected to find "a few" and instead I found "basically none").
You can see one way to do very rudimentary syntax highlighting with a StyledText component here: JavaSourceCodeViewer
To see a more robust implementation of things like syntax highlight and autocomplete, take a look at the class that Eclipse uses for the editing of Java source code: CompilationUnitEditor
I think what you are trying to achieve is quite complicated and might require a lot of extra work. See an editor is not just different controls laid out in some order, but it has a lot of additional features that any editor class expects to work. These include things like selection service and action bars etc, that you will need to hook in to ensure smooth running.
That said, it should be possible to achieve what you are hoping for. You can have a look at the source code of the MultiPageEditorPart itself to see how it converts a single editor into a multi page editor, which is capable of hosting a completely independent editor on each of its pages. You would need to achieve something similar if you want your editor to host two MultiPageEditorParts separated by a sash. If you want to carry on, you should start implementing some stuff and if you run into any problems, post them here. You would be able to get a lot better help then.
You need something like MultiPageEditorSite. Use it for inspiration when implementing an EditorSiteDelegate. MultiPageEditorSite has support for separate keybindings between the pages, for example.
class ChildEditorSite implements IEditorSite {
IEditorSite parent;
public Object method() {
return parent.method();
}
}
Using this class, you can easily do the following in your main EditorPart:
class MyCoolPart extends EditorPart {
public void createControl(Composite parent) {
EditorPart child1 = new MyChild();
child1.init(new ChildEditorSite(getEditorSite()), myInput);
EditorPart child2 = new MyChild();
child2.init(new ChildEditorSite(getEditorSite()), myInput);
child1.createPartControl(parent);
child2.createPartControl(parent);
}
}
Be sure to also dispose of your children correctly when you dispose of your MyCoolPart. Please note that this only works in the most basic of cases. An EditorPart that is a DocumentEditor or that relies on IPersistablePart or implements listeners/adapters for confirming a save is probably going to require a lot more Lifecycle management...
Related
I want to get Exactly eclipse editor kind highly customized tooltip like below-
I used eclipse provided snippets of customized Tooltips but none of them were so highly improvised performance and easy to use.
How to reuse these Tooltips , any example would help.
you just need to extend org.eclipse.jface.window.ToolTip
and override
protected abstract Composite createToolTipContentArea(Event event,
Composite parent);
you can add org.eclipse.swt.browser.Browser and set formatted content and add required controls.
In my application I've got about a dozen places where I need to show a country suggest box. All the code of the suggest box(including the creation of a custom SuggestOracle, it's initialization and various handlers) take up some ~100 lines of and copying it all over the project seems quite hardcore for me.
So I decided to write a custom CountrySuggestBox which extended SuggestBox wrapped in itself the construction of my custom SuggestOracle and did all the click/key handling stuff in itself. After this I was planning to just write something in the lines of #UiFiled(provided=true) CountrySuggestBox = new CountrySuggestBox(countryList); and be done with it. But for that I also need CountrySuggestBox to implement LeafValueEditor<Country> which i can't do cause SuggestBox implements HasText and these interfaces do not "like" each other.
So how can I make CountrySuggestBox an editor of country types property without writing custom editor methods in the classes using it.
Prefer composition over inheritance.
Have CountrySuggestBox extend Composite (or simply implement IsWidget) and wrap the SuggestBox.
Then you can make it a LeafValueEditor<Country> or IsEditor<LeafValueEditor<Country>> (along with TakesValue<Country> or HasValue<Country>)
GWT's Editor framework is really handy and it can not only be used for editing POJOs but also for read-only display.
However I am not entirely sure what the best practice is for doing inline edits.
Let's assume I have a PersonProxy and I have one Presenter-View pair for displaying and editing the PersonProxy. This Presenter-View should by default display the PersonProxy in read-only mode and if the user presses on a edit button it should allow the user to edit the PersonProxy object.
The solution I came up with was to create two Editors (PersonEditEditor and PersonDisplayEditor) that both added via UiBinder to the View. The PersonEditEditor contains
ValueBoxEditorDecorators and the PersonDisplayEditor contains normal Labels.
Initially I display the PersonDisplayEditor and hide PersonEditEditor.
In the View I create two RequestFactoryEditorDriver for each Editor and make it accessable from the Presenter via the View interface. I also define a setState() method in the View interface.
When the Presenter is displayed for the first time I call PersonDisplayDriver.display() and setState(DISPLAYING).
When the user clicks on the Edit button I call PersonEditDriver.edit() and setState(EDITING) from my Presenter.
setState(EDITING) will hide the PersonDisplayEditor and make the PersonEditEditor visible.
I am not sure if this is the best approach. If not what's the recommended approach for doing inline edits? What's the best way to do unit-testing on the Editors?
If you can afford developing 2 distinct views, then go with it, it gives you the most flexibility.
What we did in our app, where we couldn't afford the cost of developing and maintaining two views, was to bake the two states down into our editors, e.g. a custom component that can be either a label or a text box (in most cases, we simply set the text box to read-only and applied some styling to hide the box borders).
To detect which mode we're in, because we use RequestFactoryEditorDriver (like you do), we have our editors implement HasRequestContext: receiving a null value here means the driver's display() method was used, so we're in read-only mode. An alternative would be to use an EditorVisitor along with some HasReadOnly interface (which BTW is exactly what RequestFactoryEditorDriver does to pass the RequestContext down to HasRequestContext editors).
Yes,Presenter-View pair should be. But Here two ways to achieve this feature if you like to go with:
1) Integrate Edit/View code design in one ui.xml i.e.Edit code in EDitHorizonatlPanel and View code in ViewHorizontalPanel.The panel has different id. By using id, show/hide panel with display method. if getView().setState() ==Displaying then show ViewHorizontalPanel and if getView().setState()==Editing then show EditHorizontalPanel.
2) Instead of using labels, Use textboxes only. set Enable property is false when you need it in view mode otherwise true
You have created two Presenter/view but I think if Edit/View function has similar code so no need to rewrite similar code again and again for view purpose.
If a big project has so many Edit/View function and you will create such type of multiple View/Presenter than your project size become so huge unnecessary.
I think that whatever I have suggest that might be not good approach but a way should be find out which help to avoid code replication.
I have extended org.eclipse.ui.editors.text.TextEditor to implement a custom editor.
For this editor, I have defined a marker type (org.eclipse.core.resources.markers extension point) and an annotation type (org.eclipse.ui.editors.annotationTypes extension point) to mark specific parts of code in my editor. I use a reconciler to update my annotation model.
Now I want to add a quick fix / quick assist feature. I simply want eclipse, to show a box with proposals, when I hover over an annotated part of the code and replace that part with a given string, when I click on a proposal. Just like the quick fix feature for the java editor.
So, what is the best way to implement this behavior?
I read about marker resolution generators and quick assist processors, but I'm still confused how it all works together...
I would be glad, if someone could point me to the right direction.
EDIT: From what I've understood so far, a MarkerResolutionGenerator is responsible for showing quick fixes in the problems view. To get quick fixes in the source viewer, I would have to set a QuickAssistAssistant for my SourceViewer and implement a QuickAssistProcessor which returns CompletionProposals.
Is this the right way to do it?
EDIT2: I'm wondering if I need Markers at all, or only Annotations, I'm confused...
I finally found out how to get Quick Fix to work for my editor.
I use the annotationTypes extension point to register my own annotation type and the markerAnnotationSpecification extension point to specify the look and feel. In my custom SourceViewerConfiguration class I override getAnnotationHover(...) to return a DefaultAnnotationHover object and getTextHover(...) to return a DefaultTextHover object, so the annotations are shown in my source viewer.
Then I override getReconciler(...) to return a MonoReconciler with my own implementation of IReconcilingStrategy to create the annotations in its reconcile(...) method. And finally I override getQuickAssistAssistant(...) to return a QuickAssistAssistant with my own implementation of IQuickAssistProcessor. The computeQuickAssistProposals(...) method in the processor class computes the quick fix proposals which show up, when I press CTRL+1.
I don't create any Marker objects and don't use a MarkerResolutionGenerator, since the marker concept is much more heavyweight than using only annotations and the functionality which annotations provide fits my needs.
You have to register an extension to the extension point org.eclipse.ui.ide.markerResolution. This extension refers to a markerType (using the markerId), and also a resolution generator.
The latter component is responsible for calculating the possible fixes: it reads the marker, it can check the related files, etc., and creates marker resolution instances. These resolution instances basically process the erroneous files, and hopefully fix the original problem.
During marker resolution, you should not worry about removing the markers, as after the fix is executed, sometimes the validation would run again (e.g. during the build, or if no automatic validation is available, then manually - but it is not the task of the marker resolution to update the list of markers).
in a définition of a widget, what is a better practice, and why, use the widget himself or the type "higher", example, it's a better practice to do
1) Button myButton;
or
2) Hastext myButton; (and set a button later)
thanks for your answer.
It is usually a good idea to use "higher" types or interfaces. By doing this properly you can hide implementation details. The code that uses an object looks at it as the one of a higher type and it is not important what is actually hiding behind it. This is good because you can easily change an implementation of the object without breaking anything.
For example when defining a panel in an application you should use Panel class instead of its implementation e.g. HorizontalPanel or VerticalPanel.:
Panel myPanel;
Then you can create a proper implementation of it, e.g HorizontalPanel:
myPanel = new HorizontalPanel();
If you then later decide to change myPanel to be VerticalPanel you will not have to change anything in the code that uses myPanel. Everything will work just fine.
However you must remember that you will be only able to use methods available in Panel class. Additional methods defined in e.g. HorizontalPanel will not be accessible. And this is actually what you should remember when choosing the type of your widgets. Your widgets should be of types which provide methods which you want to use.
In your example using HasText instead of Button isn't probably a good idea because HasText has only methods for setting and getting a text and you probably also want to have access to addClickHandler method available in Button and a few more.
So to summarize it is good to use "higher types" but they should not be "too high" to be useful.
The answer to that lies in the Model-View-Presenter pattern, that was introduced in last years Google IO presentation by Ray Ryan. There's also an official tutorial/docs - part 1 and part 2. There are also a number of questions here on SO that cover that topic :)
And a quick answer to your question (that will make more sense once you get familiar with MVP): use interfaces in the Presenter and their implementations in the View :) That way your Presenter stays oblivious to the underlying implementation/Widget you actually used (was it a Button? Or a Label? It doesn't matter, they both implement HasText).