Bi-directional Code Generation

Editing hand-written windows

Most GUI builders in the world will only read and write the code that they themselves create. Designer is an exception to that rule. It can read and write not only the code it creates, but also a great deal of code written by hand(>90%). If you come across a case that does not work, send it to us for analysis. The more broken examples that we can "fix", the better Designer will get in the long run (and the better chance you will have of salvaging your old code as-is).

Note that dynamic GUI code can not be rendered or edited. The problem with dynamic code is that it generally relies on runtime calculations that have no meaning at runtime. Widgets created in a loop (where the loop parameters are passed in externally) are a good example. Widgets created in conditionals where the value of the conditional is not known until runtime are another example. Dynamic GUI code constructed from the results of complex database queries is yet another example.

Modifying generated code

The Designer parser has a good understanding of basic Java code and various Swing, SWT and GWT patterns. As a result, it is very refactoring friendly and very resilient in the face of hand made changes. You can make changes or add code anywhere you like and Designer will reverse engineer it when possible. You can also refactor the code in almost any conceivable way and Designer will still be able to parse it and render it in the Design View. For example, use the tool to create a new Swing JFrame, add some widgets, and then use the Eclipse refactoring tools to extract some of the widgets into their own methods.

No special tags required

Using special tags or marking code read-only would go against several of Designer's major design goals. Designer does not make any distinction between generated code and user-written code. Designer is designed to generated the same code that you would write by hand and to make minimal changes to the source when you make a change to the design view. Designer never regenerates the entire source for a file. If you change a single property, it will change only a single line of code. That line of code could theoretically be anywhere in the source file (including within lines originally created by Designer or within lines that you wrote by hand).

Specific constructs that can't be parsed

Here are some examples of constructs that Designer does not yet handle:

• Re-use of GridBagConstraint objects across multiple widgets (we support reusing the same variable but not the same objects)
• UI construction through the use of local parameterized helper methods
• Multiple aliases (fields or local variables) referring to the same component
• Multiple references to the same widget definition through multiple invocations of the same helper method
• Dynamic GUI code based on runtime calculations