code generation and NLS preferences

[jdam]

We have an application with about 150 screens that we would like maintain using swing-designer and are currently evaluating. Because we generate some screens but also have a corporate manual code style, the following would be very useful to us:
- specific start/end tags identifying the control around the statement(s) that add a control to the layout
- more flexibility in choosing a localization messages class (non static get method enabling dynamic construction and separate classes or instances for different sets of fields on a screen)
- optional disabling of some functionality of the designer to avoid corruption of generated code (no source view, no removal of certain controls)

I am not sure if any of this is already possible, but I could not find a way yet.

Regards,

jdam

[Eric Clayberg]

- specific start/end tags identifying the control around the statement(s) that add a control to the layout

Is there a particular reason for this? What do you define as "add" in this context? Just the line that instantiates the control or all of the lines that set properties for the control?

How would you handle the case where that code is not contiguous (e.g., control created in initializer and properties set elsewhere, control created in an accessor but added to parent in another method, etc.)?

- more flexibility in choosing a localization messages class (non static get method enabling dynamic construction and separate classes or instances for different sets of fields on a screen)

Designer is already very flexible in handling different NLS patterns. If you are looking for additional choices, then we need to see examples of them.

- optional disabling of some functionality of the designer to avoid corruption of generated code (no source view, no removal of certain controls)

That would certainly possible in a customized, OEM version of the tool. What sort of "corruption" are you trying to prevent?

Disallowing access to the source would also prevent you from coding event handlers or andding any logic to the class beyond that generated by the tool itself.[/quote]

[Guest]

Is there a particular reason for this? What do you define as "add" in this context? Just the line that instantiates the control or all of the lines that set properties for the control?
How would you handle the case where that code is not contiguous (e.g., control created in initializer and properties set elsewhere, control created in an accessor but added to parent in another method, etc.)?

With add I meant the lines that sets the properties and actually add it to the container (parent). My assumption was that these would be contiguous. The creation would be generated and out of reach for manipulation, so that could be in another method. The reason is that we generate a large number of screens where we would only allow designers to adapt properties and layout, but not remove the control. If the control is removed by the generator we need to find the lines that set properties and add it to the parent and remove these too.

Designer is already very flexible in handling different NLS patterns. If you are looking for additional choices, then we need to see examples of them.

We use instances of home-grow property managers that look like this:
either

Code: Select all

LocalizationPropertyManager carPropmngr = new LocalizationPropertyManager(Car.class);
carPropMngr.getLabel("make");

or

Code: Select all

LocalizationPropertyManager.getLabel(Car.class, "make");

This partitions the properties and makes reuse of texts based on domain classes possible. We also use the more traditional bundle approach for screen specific texts, but Designer already supports this elegantly.

That would certainly possible in a customized, OEM version of the tool. What sort of "corruption" are you trying to prevent? Disallowing access to the source would also prevent you from coding event handlers or andding any logic to the class beyond that generated by the tool itself.

Because the controls themselves are determined by the generator, they should not be removed. The designers are not programmers and will not need to add logic or write event handlers.