GWT ValueListBox: can it support more than a single selection? - gwt

Can GWT's ValueListBox support multiple selections? Also, is there a way to get it to display more than a single value at a time (like ListBox.setVisibleItemCount()) ?
It seems like you'd need to get at the underlying ListBox (or somehow provide a custom one) in order to make this happen. Of course getListBox() is private, so that's out.

No. ValueListBox is intended to operate on single value. That's why it can be easily used as editor (from Editor framework) for wrapped type.
For multiple selection you can use ListBox, but AFAIK there's no straightforward way to use it as editor (you have to write your own custom editor based on ListBox).

Related

What would be the best approach to implement a multi-select combo in SWT/JFace?

I need to implement a multi-select combobox using SWT/JFace, What would be the best approach?should i go for changing the source code or i should try to extend the combo?
It is not possible to extend a Combo It is possible to extend Combo by overriding checkSubclass(), however it is highly disapproved of. The alternative is to create a wrapper for it. But that would be too much work.
Extending a CCombo is an option, but not a very good idea. Again, too much work for the functionality you need.
BUT
As sambi reddy mentioned, you could use a TableComboViewer from Nebula (scroll down to "TableCombo").
Another convenient solution (my favorite) is to have a CheckboxTreeViewer since you need to implement multi selection and such.
screenshot
https://github.com/lawhcd/SWTMultiCheckSelectionCombo
For anyone who is looking for a widget that allows user to select multiple options from a list of check box style options.
It is based on user1438038's idea and extended to provide nearly all of the api required of a widget similar to Combo.

GWT SuggestBox custom non-text editor

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 Editors for readonly and edit mode

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.

GWT MVP - maintaining multiple displays that are separate of one another

I have a GWT App and I am using GWT MVP with Places / Activities.
My application layout is something like
MENU | CONTENT
The Menu and the Content displays will change dynamically and one changes separately from the other. What I mean by this is that when the Content display changes I do not want to have to update the Menu display and vice versa. Both displays need to be able to respond to PlaceChangeEvents and update themselves when these occur. The problem is that each display should only update in response to certain PlaceChangeEvents, ignoring PlaceChangeEvents that are directed at the other display. However this does not work using the 'standard' GWT MVP pattern because even when each display has it's own ActivityManager they will automatically pick up ALL PlaceChangeEvents because there is a single PlaceController listening on a single EventBus. The only way I can see to do this is by having two EventBus's and two PlaceControllers - one for the Menu and one for the Content. So my question is whether this is a good solution or is there a simpler/better way that I am missing? One problem with this solution is that the PlaceHistoryHandler can only be registered with one of the EventBus's.
Place changes are actually controlled by ActivityMappers. They get a Place and return the corresponding Activity. This is where you control how Places are mapped to Activities:
You need to create two ActivityMappers (MenuActivityMapper, ContentActivityMapper) and then instantiate two ActivityManagers each with it's own ActivityMappers. Then for each ActivityManager you call setDisplay(AcceptsOneWidget display) where for each you pass in an area (display) where it will show it's content.
For menu you will probably only use one Activity, since it's available in all Places. So MenuActivityMapper.getActivity() will always return the same instance of the MenuActivity. To enable MenuActivity to still adapt it's look based on place changes, MenuActivity should listen to PlaceChangeEvents.

GWT: creating a text widget for highly customized data entry

I'm trying to implement a kind of "guided typing" widget for data entry, in which the user's text entry is highly controlled and filtered. When the user types a particular character I need to intercept and filter it before displaying it in the widget. Imagine if
you will, a Unix shell embedded as a webapp; that's the kind of thing I'm trying to implement. I've tried two approaches.
In the first, I extend a TextArea, and add a KeyPressHandler to filter the characters. This works, but the browser-provided spelling correction is totally inappropriate, and I don't see how to turn it off. I've tried:
DOM.setElementProperty(textArea.getElement(),
"spellcheck", "false");
But that seems to have no effect- I still get the red underlines over
"typos".
In the second approach I use a FocusWidget to get KeyPress events, and a separate Label or HTML widget to present the filtered characters back to the user. This avoids the spelling correction issue, but since the FocusWidget is not a TextArea, the browser tends to intercept certain typed characters for internal use; e.g. FireFox will use the "/" character to begin a "Quick Find" on the page, and hitting Backspace will load the previous web page.
Is there a better way to accomplish what I'm trying to do?
You might just be able to use event.preventDefault() on your keypress events to avoid these browser behaviors. Otherwise, maybe a hybrid of the two approaches? Have a hidden TextArea with focus, accepting key events, and then post the typed characters to a separate Label.
There is no specific GWT method on TextBox for this, but this simple line of
GWT code fixes the problem for Chrome (for other browsers, YMMV - it may depend upon how completely they implement HTML5) by setting an attribute on the underlying input element:
myTextBox.getElement().setAttribute("spellCheck", "false");
Perhaps this attribute is a relatively new feature.