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 - obviously there somewhere but I haven't seen it yet.

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

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