The generator


JRE 1.8 and the full 'resources' folder as it is made available in the 'downloads' page.


The easiest way to set the generator laboratory is to download the Eclipse Maven project already equipped with all the needed directories, and letting me out of the responsibility to distribute the licensed dependencies

If you met some trouble getting the SprHibRAD artifacts from the Maven Central Repository you can merge the SprHibRAD artifacts tree in your local Maven repository.

The GUI structure

The generator runs as a single-window desktop application that has no classical menu application at the top of the window: the user-actions area is split in two regions, instead.

The upper region contains commands to address/create the generation project, the corresponding data for getting the jdbc connection to the database and the "generation action area".

The lower region is made up by a hierarchal tab-panes structure where each pane identifies a specific context of definition of the generation project. (there are at the very bottom two status boxes - high level messaging is performed on the left and low level on the right).

The 'Application configuration' tab-pane doesn't require explanation for 'sprHibRad'-prefixed properties more than what said about 'Application layout'; the developer of Spring/Hibernate applications certainly knows about the other properties. Below are the descriptions for the other pane.

Notes about the execution flow

At the start-up the generator requires the creation of a new generation project or opens the currently ongoing project (that one referenced at the last saving-operation). The tool doesn't require the connection to the database until it is needed: typically when the 'generate' command is fired or when the user makes a selection that needs database-meta-data to have the system reacting consistently to the selected value in order to enable and/or populate related items.

The loading of the meta-data clear any selection the user could have done. If you are annoyed by that, I advise you to explicitely load the meta-data with the dedicated command at the beginning of your working session with the generator.

Along the whole user interface, when an arrow connects two listbox (directly or through the selection of a 'switching' radio button) the rows of source list-box can be double-clicked to push the row item to the target list-box.

As the user of the generator proceeds in his/her definition, the project tree grows and when saved into the project file, even an indented flavor of the Jason file is saved. The latter is only written: never read. It worth while to remember that the generation project file must not be modified by hand.

The 'Involved entities' tab-pane

The 'tables' list-box is filled during the loading of the meta-data and is the source of entities that need to be represented in the final application: the adjacent 'Model entities' list-box is the collector of the choices made by a 'pushing' double-click on the rows of the first listbox.

The 'Menu' list-box collects (from the adjacent list on the left) which entities must appear in the application menu (beyond those ones added by the framework: that is, an option between {'user's preferences', 'change password'} and the 'logout' command).

On the right there is a set of drop down lists that identify user and role physical tables in order to let the tool provide the user with users and roles management. These items, even if hosting the selection independently by the meta-data be already loaded in the same session, are not able to display the selected value until the meta-data are loaded.

The 'Roles management' tab-pane

Allows to view or to build the list of application roles.

The 'Entity's tasks' tab-pane

It requires the user to select the entity of interest among those ones 'involved' in the project, it

defines how each entity is processed by the final application or, in other words, when and how the entity appears along the application execution and it is made up by a set of pane, all referring to the entity selection made at the top of its area.

Its sub-panes and respectively contained items are:

The 'Users management' tab-pane

It is an helper feature since a connection to the target database is available and, even, the dedicated tables to users and roles representation are mapped by the generator tool. As clearly highlighted, however the underlying ddl for the dbms level definition of user is provided only for MySql.

In the lower area the attribution of roles to each user is made possible.

The user management is available in the generated web application, too.

The generation

When all the things are set, the developer can fill the boxes within the 'Generation' frame and click (remember the requirements) on the 'Generate' button. It is important, the first time, to set the 'Language file' check-box, else no application-dependent dictionary skeleton is generated.

A full Dynamic web application will be generated, ready to be opened as a Maven-based Eclipse (Oxygen) project.

Note: SprHibRAD generator doesn't create the report design files ('[entityName]List.rptdesign' files) expected by the framework in the 'WebContent/reports' directory when, for some entity, the 'Entity tasks'->'Main'->'Printable' was set): they must be created by hand by using the proper Eclipse flavor built for reporting tools.

If BIRT is needed, the BIRT engine jars must be located in the lib folder of the servlet container or in the 'WebContent/WEB-INF/lib' folder of the web project.

In the 'src/main/resources' path of the project a SprHibRAD dictionary file ( and an application specific dictionary file ( are the only language provided by the generator.

The file needs to be completed by hand in the right part of each row for the application to run in an understandable flavor. The prefix present in each key should be sufficient to the developer to be able either to recall the semantics or to understand the context in which the keyed literal is used along the application structure.

If other languages are desired, it is enough to duplicate the pair of dictionary files making the needed translation in the new pair (a derivation for each adding language is to be done, obviously). The user of the generated application will find all the languages provided in the user's preferences context (when it is available due to a convenient configuration settings - see, for that, the file in the resources folder of the generated project).