Java Code and Jigloo

Parsing Code

Jigloo parses the java class to construct the visual representation of the form. If you edit the code in the source editor then your changes will be reflected in the form editor. However, this might take a few seconds, so if you are making lots of changes to the java code you might want to disable parsing temporarily till you have made your changes. You can toggle parsing on/off by hitting Ctrl+Alt+P in the source editor, or hitting the "Toggle Parsing" button in the Outline View.

Jigloo is able to parse most common Java techniques for building GUIs as adopted by most popular GUI builders. It is also able to accomodate hand-written code to a certain degree. However, it does have limitations and these include:
Jigloo starts by parsing the constructors of your class. If it finds a call to other class methods (eg, if "createComponents" is a method of your class, and it is called from your constructor), then those methods will be parsed by jigloo as it encounters the method calls. Similarly, if those methods call other methods then those methods will be parsed and so on. If, in the course of parsing the constructors and all the methods called by the constructors etc, one of the "GUI initialization" methods is parsed, then jigloo will stop parsing your code.

The "GUI initialization" methods are by default {initGUI, initComponents, initialize, open, createPartControl, createContents, createControl and createDialogArea} but this list can be changed in the Jigloo Preferences Page.

If, however, none of the "GUI initialization" methods have been parsed then Jigloo will search the code for one of these methods (in the order in which they appear in the list) and will parse the first one it finds. Eg, if a class has methods "open" and "initialize", then "initialize" will be parsed because it appears first in the "GUI initialization" list. If none of the "GUI initialization" methods appear in a class, then every method in the class will be parsed.

Therefore if you always use a method "initializeGUI", say, to create your code then you would add "initializeGUI" to the start of the "GUI initialization" list.


By default, Jigloo will not parse code that sets a property of a component outside of the method in which that component is created. For instance, if a JLabel is created inside the initGUI method, say, but an event handler for a JButton's actionPerformed event sets the value of that JLabel's text, then that value will not be applied to the JLabel in the form editor. This prevents Jigloo from displaying a GUI which is only visible under certain conditions (eg, when a button is pressed).

However, if you *do* wish Jigloo to parse such property-setter calls, then there is a setting in the Preferences Page which allows you to do this.



Hiding code from Jigloo

However, Jigloo recognizes certain comment tags which can be used to customize the parsing/code-generation behaviour of Jigloo.

Code blocks can be hidden from Jigloo using the //$hide>>$ and //$hide<<$ tags. ie, the
//$hide>>$ tag should be placed on the line before the start of the block you wish to hide, and the //$hide<<$ tag should be placed on the line after the end of the block. Any code inside a block marked by these tags will not be parsed by Jigloo.

If you wish to hide a single line of code, then you can place the customizable //$hide$ comment at the end of the line.

These tags can be customized in the Preferences Page.

Thus you are able to design a GUI for each case of an if/then clause by hiding one half of the clause at a time.


Protecting code from Jigloo

Code blocks can also be protected from being modified by Jigloo by using the customizable //$protect>>$ and //$protect<<$ (and //$protect$) tags, in the same was as the tags for hiding code. These tags can also be customized in the Preferences Page. Any code marked by these tags will not be modified, though Jigloo may add lines of code inside those blocks.


Class Instantiation

As jigloo tries to render your GUI in it's Form Editor, it needs to insantiate the visual classes used and also any classes which are used as properties of these visual classes. Also, if a method is called on a visual class then Jigloo will try and instantiate the classes passed as parameters for this method. However, Jigloo will not instantiate any other classes. If you find that Jigloo is instantiating a class that you do not want it to instantiate, add this class to the "Forbidden superclasses" list in the "Class creation" tab of
the Jigloo Preferences Page. You can define single classes or packages of superclasses which can or cannot be instantiated. Note, you are specifying superclasses, so if you allow/deny a superclass, then you are also allowing/denying any extensions of that superclass.

Externalizing Strings

Note: If you are working on classes created by Jigloo 2.7.2 which use the getExternalizedString method, then you will need to change this method to be static before Jigloo 3.0 will be able to get the value of the externalized string.

Jigloo recognizes Strings externalized by Eclipse's "externalize strings" action, which creates a ResourceBundle accessor class and the appropriate calls in your code.

Jigloo will parse these calls, search for the properties file related to the ResourceBundle, and display the externalized string in the Form Editor. If it can't find the properties file, or the project has not been built yet, then it will display the key for the externalized string surrounded by "$" signs.



Code Generation

Jigloo will generate new code in accordance with the user-defined preferences set in the Jigloo preferences page. You can choose whether to generate elements inside getter methods (available for Swing forms only) or whether to enclose them inside braces, comment tags or blank lines. The advantages of enclosing elements inside braces are:
If you change your code-generation style, you may want to completely re-format your code according to the new style (say, you decide to change from using spaces to separate code elements to using braces). Jigloo does not do this automatically since it is a time-consuming operation. After changing your preference, you can right-click on the form editor and choose the "Source->Reformat code to current coding style" option.

You can also use this powerful option to re-format code generated by hand or by other GUI builders.

Note on converting from getters: If you are converting from using getters to using code blocks, the getter methods will be deleted from the code, so that if you are explicitly calling these getters from your own code, or from other classes, these getters will need to be regenerated to return the corresponding fields - but the Eclipse context menu options can be used to do this easily. Any references to the getter methods from code that is being controlled by Jigloo, however, will be changed to refer directly to the fields themselves, so the code will only need to be repaired if, for example, you are calling myJFrame.getJPanel1() from an external class after reformatting MyJFrame to not use getters..