GWT 2.1 and the editor mechanism, how to? - gwt

I'm very confused about the new editor mecanism with GWT 2.1.
I can't understand how to provide errors with a simple TextBox.
For example I want a TextBox where text size is greater than 6 (for a password).
How can I simply provide a delegate to this textbox to handle this verification and use this textbox in the editor mecanism ?
Moreover, I don't understand differences between editor adapters and editor subtypes. How should I use these two features to create my own editor widget ?
official documentation is here:
http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideUiEditors.html
But it's not very clear.

There's a sample widget in DynaTableRf that implements a ZIP+4 input box as a subclass of ValueBox. A custom Parser is used to provide the input validation. The ValueBoxEditor adapter is used to transform the ValueBoxBase.getValueOrThrow() into an EditorError.
An "adapter" contains a reusable behavior that isn't tied to editing a specific kind of data. For example, the OptionalFieldEditor and the ListEditor don't really care about the T parameterization. An Editor subtype is primarily concerned with displaying an instance of the T type and may or may not embed a complex behavior.

Related

How to achieve Two Way data binding in native GWT?

We have been using GWT for around 4 years now. One of the most often discussed features missing in native GWT is data binding. Reading across AngularJs another Google offering, i came across http://devgirl.org/2013/03/21/fun-with-angularjs/ . I do not wish to use GXT or any other third party tools. I also wish to avoid generator related solution.
Is there any way this will ever be implementable in pure native GWT?
Is there any specific reason why GWT cannot provide this out of the BOX?
Have you tried GWT Pectin?
I have used it successfully in a larger project some time ago.
I suggest you try HexaBinding, which is non invasive and only focused on data binding. Here is the link : https://github.com/ltearno/hexa.tools/blob/master/hexa.binding/README.md
It works with pure Java, GWT and will soon work also with Android and JavaFX. It may even work with J2Objc but not sure yet...
I read the post you mention on devgirl about AngularJS. In that post the "2 way data binding" refers to the property of the code to reflect automatically on the view the changes that occurs to the data that the view is currently displaying.
This is achieved in GWT since version 2.1 with the Cell Widgets
In the first paragraph of the Cell Widgets documentation I linked above it is clearly stated that:
A cell widget can accept data from any type of data source. The data
model handles asynchronous updates as well as push updates. When you
change the data, the view is automatically updated.
If you want to do in GWT something as basic as the example in the devGirl post you need to write a onKeyup handler (in AngularJS you should write a Scope to this purpose) that would copy what you entered to the linked label. Something like this:
...
final TextBox nameField = new TextBox();
final Label enteredName = new Label("");
...
public void onKeyUp(KeyUpEvent event) {
enteredName.setText(nameField.getText());
}
...

why use zend form decorators instead of individually rendering?

I am almost at the end of my rope trying to style my Zend form using decorators. Previously to avoid these issues I would create a form script extending zend_form, add whatever validators, labels, etc I needed then retrieved the element from my view script using $form->getElement('my_form_element');
that way I could wrap whatever css tags I wanted around the element. I thought I should learn how to use the built in decorators, but I'm starting to feel like it's a waste of my time. My old way seems easier, is there some reason I am not seeing that makes using custom decorators better?
In general decorators are used to dynamically add functionality without having to touch the code's core functionality and for a better re-usage of code. In Zend_Form however, I think that the decorator system (as well as Zend_Form in general) is unintuitive and heavily over-engineered and so it does exactly the opposite of what it should do: Help the developer to create better and more intuitive code faster.
In my opinion the usage of Zend_Form_Decorator makes only sense in the case where you have some extended logic that you plan to reuse throughout your project on multiple and different types of elements.
Let me give you two examples:
You want to add a tooltip icon next to an arbitrary form element with a nice icon and a fancy JavaScript hover box.
An element should be validated directly upon entering data by posting an AJAX request and adding either a green check mark on success or a red cross icon on failure next to the element.
With the decorator you can now separate the logic of the added functionality from that of the underlying element and so you can use the same code to add the tooltip and/or the live validation feature to a textbox element as well as any other element simply by adding all the decorators you want to the element.
There is also a great article from Matthew Weier O'Phinney, the lead developer of Zend Framwork, that gives some background insight on the motivations for using decorators along with a lot of examples: Decorators with Zend_Form
Decorators can come in handy if you have a specific repeatable markup for your forms, for example if you want to use Bootstrap. Other than that, especially if you have a good html/css person, I would avoid them.

GWT "big" Forms

I completed the StockWatcher basic gwt tutorial, and read several pages of documentation but I can't find the solution for a very simple thing.
What if my stock was a "real" object, such as an invoice, with dozens of fields to be entered by hand?b
I suppose I have to write a panel with many text boxes, and on the 'OK' button click, retrieve each textbox value in a awful way:
codeTb.getText();
year.getText();
customerTb.getText();
...
Then build a POJO-DTO and send through the RPC wire.
Really, isn't there a more simple way?
I think about a concept of "Form" in Gwt. Sorry, maybe I didn't find it in the doc, yet.
GWT has what are called Editors. With Editors you can bind Widgets to a DTO and it's fields, so you don't have to do the getText or setText yourself. It's not totaly trivial to use, but you can find more details in the GWT documentation: http://code.google.com/webtoolkit/doc/latest/DevGuideUiEditors.html
What you need is a FormPanel. Take a look here http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/com/google/gwt/user/client/ui/FormPanel.html

add Validator to existing FormItem Validators in smartgwt

in a smartgwt DynamicForm, how can I add a validator to an existing set of validators within a FormItem ?
The only method I found in the official api is "setValidator(Validator)", but this seems to overwrite all the existing ones.
I would prefer a java approach to this (i.e. using smartgwt api), but in the end, if no solutions are available, at least a "js" native method would do the job.
thanks
Most likely, you don't want to by trying to dynamically add a validator at all.
First, read the Data Binding section of the QuickStart Guide, which shows how you can add screen-specific validators to a form while still inheriting validators declared in the DataSource.
Second, if you're trying to dynamically change the list of validators because some data that validation depends on is changing, take a look at the CustomValidator instead.
If you have some reason to add a validator dynamically that isn't handled by these approaches, try explaining it in detail.
Finally, you can continue with your current approach (not recommended) if you just refactor such that you can provide all the appropriate validators to the FormItems in a single setValidators() call.

Developing a GUI Builder Application

I am looking for a nice framework for developing a GUI builder Application. We have an application where 100Os of custom data entry forms and their print formats are required and each client will need some modifications on these. We have a developed a product using java based open source templatnig frameworks so that the layout and field definition are stored in database and rendered dynamically to the user. We also have an appication to design these forms but cannot do visual design.
Now I am trying to make a Visual Form Designer application for generating these forms. Can any one suggest some open source frameworks than can be used? Can I use Eclipse Visual Editor? Or is it better to develop some kind of parser for HTML using AntLR and then parse the HTML output from already existing GUI builders like Dreamweaver to get the desired output?
Thanks and Regards,
-- Kannan
Oooh, great question!
I wouldn't know any readily availble framework that you can use. Depending on your needs however, I think rolling your own shouldn't be too hard.
First of all, you probably wouldn't want to give the users too much freedom. Freedom only gives them the opportunity to mess things up and make the resultant forms hard to use. I think from your description that the fields are pre-defined, so that the user only needs to customize which fields appear on a given form, and in what order. Order can be a simple thing like top-to-bottom. Some semi-intelligent automatic layouting could be used to conserve screen space. Adding a feature to group fields together would probably also be useful, and grouping would lead to some kind of standard "group" widget.
Accepting simplified functionality like this, you don't really need the flexibility of a full gui editor. A couple of listviews, maybe a property sheet and a preview window will be enough to give your users the functionality they need.
Of course, this only holds for screen forms. Print forms may be trickier to layout, as people may want to cram as many fields as possible into very little space so the entire form can fit on a single page or something. I really don't have any suggestions for you there, but maybe a similar "simplified" approach with some intelligent auto-layouting could work.
Overall, my advice would be: Keep It Simple! (S... ;)