Since version 1.1, Balise files and data are organized according to projects. This feature is made necessary by the fact that some files (e.g. icon images files) need to be accessed at edit time by Balise and at run time when the interface is loaded in a totally different context (e.g. jar files). A project defines three directories:
The project root folder. This folder mimics the path structure that will be used at runtime. That is to say that the root subfolder tree at edit time will correspond to the directory structure at run time. Let's suppose a user named john develops an application which is contained in a jar file. The jar file contains two directories, images and interfaces (one folder for images, one for storing the xml buoy interfaces). Let's also suppose that the root folder for this project is set to /home/john/application. The icon images files are stored in /home/john/application/images and interface files in /home/john/application/interfaces.
The images folder. The purpose of the images folder, as explained in the exemple above, is to place every image used by the interface in location that will be accessed at edit time as well as run time. Whenever an image icon is set (e.g. in a button), the image file is copied into this directory if it does not originate from it. At run time, the WidgetDecoder in charge of the interface expects images to be available in ./images, whether the application is run from a jar file or not.
The interfaces folder. This is the place where Balise exports buoy interface files. In previous versions (1.0x), Balise worked directly on buoy interface files. However, this prevents adding Balise specific information in the interface file. As of 1.1, Balise uses its own file format to store interface definition. Balise files can not directly be used by buoy WidgetDecoder. However, each time a balise file is saved, the corresponding buoy interface file is also saved in the interfaces directory. Another benefit from this design is that the prototyping mechanism now knows where the interface is and you no longer need to modify the interface file name in the prototyped code.
Projects are set and edited using the menu of the edit window. It is recommended that they use the .bpr extension.
Interface definition files are standalone balise files. As compared to buoy interface files, they contain additional information, such as which widget is to be prototyped and which is not. Of course, they also contain the whole buoy interface. If you associate a project file to an interface definition file (which *strongly* recommended), then each time you save the interface, the plain buoy xml definition file will also be exported with the same name in the interfaces folder. An advantage of having buoy interfaces stored in interfaces folder is that the file name is specified in the prototyped code. The same project can be used for several interfaces, but you must have one project each time the folders where you place interfaces and images change. The trade off is that once saved project files and balise files must not be moved. If a balise file is moved, then the project must be edited so that the location of project relative to balise file is correct. If you move a project file, then edit the project to set correctly the root folder and reset the project file location in every balise file that points to this project file.