Thoughts on Google WebToolkit

The Google WebToolkit is very exciting.

I am going to listing some of the functions we currently have in JGuiGen in order to start a list of what can and can't be done easily.

Given the way I have structured the code generator (which is not finished except in my mind) - one of the hardest steps is to get a working version of a final application. I can then "mark-it-up" and use it to generate code that deals with different SQL tables and columns. Bassic application should have CRUD menu, scrolling table of data, FIND button functionality would be nice.

Connecting to SQL Backend - They are doing this through RPC. This would be a fundamental difference in the code. I suspect that since we use the AbstractTable model paradym this could be done without a tremendous amount of work. All of the calls for data are localized in the Table Model.

Main Menu

1. Exit - no problem
2. Delete - no problem
3. Add - no problem
4. Print - ignore - browser takes care of it.
5. Extra - no problem
6. Find - lots of code - Query building is probably not a problem, the report is something else again.
7. Save - no problem
8. Help - since we can use straight html - no problem

Popup Menu

1. Freq Count - probably not a problem
2. Duplicate - no problem
3. next - no problem
4. previous - no problem
5. A11y - ignore for now (write the code with A11y, just ignore the magnifying glass and probably the debug screen)
6. Switch look and feel - ignore - browser handles that
7. Switch locale - probably need to do this - not sure how
8. Switch font - ignore - let the browser handle

Bottom line - menu options don't seem to be a big problem

Now on to other basics

1. Layout Manager - they have some. I'm not sure how difficult out issues will be
2. Scrolling Table - they have scolling sub-areas, again not sure how difficult a table will be
3. Sort on column headers - don't know
4. Basic Widgets - they have a lot.
5. BoundedTextFeild - didn't see that - probably have to revert back to substringing data to the maximum length the SQL column can handle (char(30) type columns)
6. Formatted text - not sure here - SSN, Telephone, etc.

Really tough issues

Their web site says that almost off of the operation is done through RPC's. In other words the application is downloaded and stays in the browser. Calls for data and updates are done using RPCs. This is not like the round-trip html submits that JSP and JSF use.

1. handling conversion errors (user enter ONE where they should enter the number 1.)
2. handling data error messages at the browser level
3. handling data error messages from the server
4. doing the "Data Changed" checking

Just like with JSF. I see this as doable if we cna get a basic "sample" application running