Deferred code generation

[jominor]

My company has purchased GWT Designer and it is awesome. It has truly saved us considerable time and crafting a front-end that has seemed to impress our customers.

However, for a fairly complex page, it gets slower and slower as each change using the gui tool has to sync with the code. Is there any way to "defer" the code sync until a series of changes have made and then batch the code changes.

For a complex screen with many panels and widgets, a simply label changes can take 6-10 secs on a dual core machine with 4 gigs of ram.

[Eric Clayberg]

However, for a fairly complex page, it gets slower and slower as each change using the gui tool has to sync with the code. Is there any way to "defer" the code sync until a series of changes have made and then batch the code changes.

No. Note that Designer does not regenerate the full source with each edit. It only changes the source that is actually affected. Disabling that code update would cause the source to be immediately out of sync with its associated AST. It would also effectively disable undo/redo support.

For a complex screen with many panels and widgets, a simply label changes can take 6-10 secs on a dual core machine with 4 gigs of ram.

Can you send us a test case? We have some very complex examples, and this does not happen on our end.

Have you considered refactoring the screen so that each panel is represented by a Composite? Not only would that make the indivisual pieces more reusable, it should reduce the size of your source file considerably.

[jominor]

However, for a fairly complex page, it gets slower and slower as each change using the gui tool has to sync with the code. Is there any way to "defer" the code sync until a series of changes have made and then batch the code changes.

No. Note that Designer does not regenerate the full source with each edit. It only changes the source that is actually affected. Disabling that code update would cause the source to be immediately out of sync with its associated AST. It would also effectively disable undo/redo support.

For a complex screen with many panels and widgets, a simply label changes can take 6-10 secs on a dual core machine with 4 gigs of ram.

Can you send us a test case? We have some very complex examples, and this does not happen on our end.

Have you considered refactoring the screen so that each panel is represented by a Composite? Not only would that make the indivisual pieces more reusable, it should reduce the size of your source file considerably.

I'll send a test case. I figured (read assumed) that only the gui changed affected a section of code, which was why it was only taking as long as it did.

I use Idea primarily, and haven't come up with a scheme that allows both Eclipse and Idea to share resources in manner that works well, so currently, I've used Eclipse just for the front-end.

Basically, I have a single project, the image viewer actually. I create a screen, then copy the code into my idea project. I'll assemble one of the screens and send it in.

I take it that I should send it to the support number?

[Eric Clayberg]

I take it that I should send it to the support number?

Yes. Small examples can be posted here. Large examples should be sent to support via e-mail.