GWT Designer and Kitchen Sink -- Composite Inheritance

[Cove583]

I tried using GWT designer using a class inherited from a class inherited from the Composite class (much like all of the GWT Kitchen Sink classes that are derived from 'Sink'.

I tried several sample cases and each time I got a designer error. I also could not get any Kitchen 'Sink' derived classes to work.

Broad Questions:

What are the design goals of GWT designer? Is the design such that I should be able to look at the designer view of a GWT element regardless of how I have constructed my classes?

That is, is this just a matter of working out the kinks of a new product, or are there deeper design issues here?

Anybody else getting the same behavior?

Thanks much,
- Ed

[Eric Clayberg]

I tried using GWT designer using a class inherited from a class inherited from the Composite class (much like all of the GWT Kitchen Sink classes that are derived from 'Sink'.

We are currently working on support for visual inheritance of Composite classes.

It would always be helpful, if you could post a test case of what you are trying to do.

I tried several sample cases and each time I got a designer error.

It would also always be helpful to see any exceptions (from your log) that you run into.

What are the design goals of GWT designer?

To allow you to create any reasonable GWT application using the product and then to be able to continue to edit those classes within either the design view or source view.

To the extent that we can teach it to parse arbitrary hand-written GWT code, we will do so, but that is a secondary goal.

When we first started with SWT and Swing, for example, we could parse roughly 60% of hand-written code. Today we are in the 80-90% range and improving incrementally with every failing example that we get.

Is the design such that I should be able to look at the designer view of a GWT element regardless of how I have constructed my classes?

That would be our ultimate theoretical goal. How close we get will depend on the kinds of test cases we find on our own or are sent by users.

That is, is this just a matter of working out the kinks of a new product, or are there deeper design issues here?

Parsing arbitrary Java GUI code is very difficult (much harder than parsing HTML, for example), and Designer is one of the only tools out there that even tries.

The NetBeans Matisse GUI builder, for example, can't even parse its own generated Java code much less any code created elsewhere.

Visual inheritance is also very difficult to handle in Java and, again, Designer is one of the only tools that even tries to handle it.

We have that working fairly well for SWT and Swing and are now working on implementing it for GWT.

[Cove583]

Eric,

I certainly understand that parsing Java code is not an easy task and my hat off to you all for trying.

IMO, it would be helpful if the designer placed all of it's generated code in it's own method, (such as a designerInit() method), in order to seperate it from the rest of the code- and then in turn, attempted to parse only this method.

This would help drive home the understanding that making substantial manual modification to the designer generated code might cause the parser to fail. Also, then additional manually created GWT code could be written outside the scope of the designer(if desired) without concern about the parser.

GWT Designer has the potential to be greatly beneficial from a productivity point of view, but I would not want the use of it to preclude a good inheritance design of the UI.

Would love to hear your thoughts.

Thanks,
Ed

[Eric Clayberg]

I certainly understand that parsing Java code is not an easy task and my hat off to you all for trying.

We've been doing it successfully for many years now

it would be helpful if the designer placed all of it's generated code in it's own method, (such as a designerInit() method)

That would be very limiting and would make it difficult for the user to refactor their code. That would also seem to preclude reverse engineering code generated by other tools (which do as you suggest, but into differently named methods).

Currently, Designer can read and write code generated by every Java GUI builder on the market, and it can be configured to emulate the code generation style of almost any other tool.

BTW, if you want Designer to generate code for your Composites in a designerInit() method, you can specify that right now.

in order to seperate it from the rest of the code- and then in turn, attempted to parse only this method.

Forcing all of the code into a single method (whatever the name) is also very limiting. Rather than having all widgets generated in a single monolithic method, it is often useful to break the UI definition into multiple methods.

This would help drive home the understanding that making substantial manual modification to the designer generated code might cause the parser to fail.

While that is a possibility, our goal is to allow "substantial manual modification to the designer generated code".

We already do a very good job of this, and the more test cases that we get, the better the product gets in this respect.

then additional manually created GWT code could be written outside the scope of the designer(if desired) without concern about the parser.

You can do that now using code hiding tags.

GWT Designer has the potential to be greatly beneficial from a productivity point of view, but I would not want the use of it to preclude a good inheritance design of the UI.

Using Designer should not preclude you from doing anything that you like...you just might not be able to use Designer for everything (you can always use the standard Java editor in those cases).