Thursday, September 22, 2011

GWT Tricks #1

I've decided to post any "tricks" or common GWT mistakes that I've run into, researched and fixed. Hopefully these will be helpful to the next person who sees the same errors, researches the same information and wonders which fix to "try".

The SafeHTML warning

Ever see these warnings when running your GWT application?
[WARN] Template with variable in CSS context: The template code
generator cannot guarantee
HTML-safety of the template -- please inspect manually
What does this mean? How do I fix it?

Basically, it is telling you that you have inserted an "include" in your code to something in a .css file. Look for something like this:
sb.appendHtmlConstant("<div class=<\"myapp-CellSelect\">");

Where the myapp-CellSelect happens to be defined in your myapp.css file. Since you are bringing something in from "outside", the code generator can't insure it's going to work. That "outside" thing may be broken, missing, or malformed and is a bug waiting to happen.

So, what to do?
Remove this external reference and put it inline with your div. So, let say your: myapp-CellSelect is:

.myapp-CellSelect {
text-decoration:underline;
cursor: pointer;
}

then your code should look like:
sb.appendHtmlConstant("<div style=\"text-decoration:underline;cursor:point\">");
You no longer are pointing to something in your .css file and the warnings will now be gone.


Auto Selecting an Input Field

When implementing data input screens, like popup dialog boxes for example, you sometimes want to set the focus in the dialog box to something meaningful. Maybe this data entry screen has a Name field followed my other input fields. It might be nice to automatically select the Name field for the user so that they can just start typing when this popup opens. In typical application programming, you can just set the Name field as the initial focus field and it works, however, with web/GWT programming, this will not work as you expect.

Take this example:

TextBox nameBox = new TextBox();
nameBox.setFocus(true);

build the rest of your fields, populate them with data and then show() the dialog. The nameBox is not highlighted, not focused on, not ready for user input until they click on it. Why? Because the setFocus must be called after the dialog box has been rendered. Ok, so what to do?

In the code that will do the: dialog.show(); call, set the focus to the field you want when the system is not busy, meaning right after it has rendered your dialog. How? Like this:

Scheduler.get().scheduleDeferred(new ScheduledCommand()
{
@Override
public void execute()
{
nameBox.setFocus(true);
}
});

dialog.show();

Remember, with GWT there are a lot of async operations that might happen. In my case, I make calls to my database to fill in my dialog and then once they have completed, I show my dialog. Had I tried to setFocus at the beginning, it would have failed. Setting focus at the end works.

Tuesday, September 13, 2011

Patent Issued

Today I received notice that my name was included on a patent. The process was long, the company actually came and went during the whole process, but still, it happened, it's permanent and it's kinda cool. At least to me...

I'm including a link to the patent details here and I truly don't remember all the ins and outs of the algorithm, but I'll try to describe it here.

The Patent

As a UI developer, I'm always worried about keeping the data I'm showing up to date. Almost all systems require multi-user support and once someone sees stale data or worse, tries to edit it, all heck breaks loose. Your application takes a hit, your users start to feel worried about the data integrity and you'll scramble to try and "fix" it.

From the UI point of view, your widgets, tables, trees, views should be backed by "backing" data in the form of some kind of data model. Processes need to be in place to keep that "backing" data up to date and then your widgets need to react to that data changing and do the right thing. This is usually achieved with some kind of polling or pushing. When done right, your users will be amazed and feel very good about the application.

At Quarry Technologies, a secure router was being developed with a configuration CLI (command line). The UI application would need to latch on to a router and push configuration commands at it. Now what happens if someone were to telnet into the router, get onto the command line and start making configuration changes? The UI would be instantly out of date. The configuration screens and data would be stale. The rules engine for validating configuration changes wouldn't be useful, etc. And what if there were multiple UI's and multiple command line jockeys all going at it. Chaos would ensue! and it did....

How to solve this? What if there was a way for the router to tell everyone interested about configuration changes? After all, the router held that final configuration at all times and insured consistency. So we developed a way for the router to essentially "echo" out to all listeners configuration changes as they were accepted and processed. Now the UI application could setup a listener and process configuration changes coming from the router. This sounds simple enough, but there was more to it than that....you can read the goodies in the patent....but in a nutshell, the ability for our router to intelligently push out a consistent state of its configuration to all listeners was the big deal.

So I guess someday my kids, grandkids, etc. can look me up on Google or whatever the worldwide search engine will be and see my name on a patent. Here's to more to come....