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>)
Related
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...
I tried to create a properties view for a graph model in an Eclipse RCP Application. The graph elements are from a non-eclipse library and so don't implement IAdaptable or even IPropertySource.
The Tabbed Properties View, explained here:
http://www.eclipse.org/articles/Article-Tabbed-Properties/tabbed_properties_view.html
seems to be a simple possibility - but only for inputs that implement IAdaptable.
I've thought about implementing my own IPropertySheetPage but the only implementations I found are the built-in PropertySheetPage and TabbedPropertySheetPage which are very complex.
Is there another way to create a properties view for input elements that don't implement IAdaptable? Can I use Tabbed Properties View in a way I don't see yet? Are there any other less complex implementations of IPropertySheetPage, I can look at?
Thank you!
Kristina
Actually, you can write an IAdapterFactory for objects which don't implement IAdaptable and register it in plugin.xml or in your plugin activator. See http://www.eclipsezone.com/eclipse/forums/t61666.html.
Are there any other less complex implementations of IPropertySheetPage, I can look at?
Short answer: No.
But why don't you wrap the non-adaptable object into your own object that implements IAdaptable or IPropertySource or whatever, so that the property-page can work with your wrapper which holds the object you want to make editable through the property-page. And instead of providing this "library" object to global adapter-mechanism, create the wrapper, set the object and provide it to your global selection-service or whatever.
I just want to know if this is the proper way to go about splitting up widgets in GWT that get too large, or if I am missing the concept of widgets/proper GWT usage all together.
I started out with a single class (widget), PCBuilder. As PCBuilder became too large, I decided to branch off and make two classes SuggestionPanel, and BuildControlPanel, both of which just split off PCBuilder's code into separate classes that still have access to the methods in PCBuilder:
This way, in my PCBuilder class, I can do something like this to add the SuggestionPanel and the BuildControlPanel to the tabs (TabLayoutPanel) that are specified in the UiBinder of PCBuilder while allowing for SuggestionPanel and BuildControlPanel to have their own separate UiBinder specifications:
My question is: Is this proper? Part of me thinks "no" just because it's not a nice way of doing it. On the other hand it works just fine, and my web application is somewhat broken up into manageable "sections" which is what I wanted.
Thanks for any insight.
It's fine apart from the fact that you have circular dependencies between classes.
Why do SuggestionPanel and BuildControlPanel need to call PCBuilder? Is there any business logic in it? RPC maybe? Separate that into another class.
First, you might want to take a look at GIN - this handles dependency injection. This is good for testability.
Second, if your app goes beyond one "page", then take a look at GWT MVP.
You should not consider your PCBuilder as a widget. Quoting gwt -
You construct user interfaces in GWT applications using widgets that are contained within panels. Widgets allow you to interact with the user. Panels control the placement of user interface elements on the page.
Coming back to your question, my take is to create widgets only if I can reuse the same element more than once. The rest of my layout logic goes into the view. Layout shouldn't be a part of the definition of the widget as much as possible.To conclude, push styling in css, push layout in the views; widgetize only if re-usable (and core) or if adding additional functionality to existing widgets.
We are using the GWT-Presenter framework and attempting to use CellTable to put together an updateable grid. It seems as though several of the GWT constructs for CellTable don't lend themselves to easily breaking up the logic into clean view and presenter code.
Examples: 1) Within the View's constructor, the CellTable is defined and each column is created by anonymous inner classes that extend the Column class to provide the onValue() method. 2) The FieldUpdater interface must be implemented to provide logic to execute when a user alters data in a cell. This seems like it would best fit in the Presenter's onBind() method, but FieldUpdaters often need access to the Cell or Column which belong in the view. CellTable does not have accessor methods to get hold of the Columns or Cells, so it seems the only way for the Presenter to get them is for me to create a multitude of member variables on the View and accessors on my Display interface.
Can anyone provide good examples for dealing with CellTable in GWT-Presenter or a comparable MVP
I think the main point of GWT MVP is that Presenters (Activities in 2.1) do not depend on View implementation, so that you can easily swap in mock Views for easy testing.
Further, it's OK to have Views that depend on Presenters (= call presenter methods), but not vice versa (well yes, but via interface).
Usually I just keep Presenter reference inside View, so that FieldUpdater anon inner classes can call methods in Presenter. You could put this methods in an interface, but it would make no sense since there is only one version of given type of Presenter.
Or, if you want to have things more decoupled, then just have View send a GWT Event which Presenter listens to.
Are you trying to avoid binding of Model class with View? i tried doing that for cellTable but it was becoming confusing to maintain code so i decided to let Model class couple with View. you can avoid this coupling by some generic arguments while creating view..
-Saket
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).