It is made by two contribution: the first one is an actual framework built on the top of Spring MVC, Spring Security and Hibernate ORM, and, as such, it simplifies the development process of a dynamic web application relying on the under-laying frameworks, provided that a well defined layout is accepted for the final result; the second one is a code generator that renders the source code for a complete dynamic web application relying on the framework.

The area of application of SprHibRAD is any physical implementation of a relational data model where each entity owns a well defined single field primary key.

Version 1.0 has been developed and tested using MySql server.

The view layer has been implemented only for the Java Server Pages technology and relies deeply on a JSP Custom Tag Library reducing at the minimum the verbosity of the pages.

The idea to automate the development of a web dynamic application, starting from the database schema, required, first, to identify clear constraints which the requirements of the application should have been conforming to: realism and not an utopia drove me in this challenging work.

In this approach the primary requirement/constraint of this project was the clearly stated rigidity of the navigation layout of the final application: by one side, a static application menu is the entry-point for any user action and a dynamic navigation bar traces the navigation and allows backtracking along the walked path, by another side, there are a search page and a form page associated potentially to any entity qualified for that.

Then, it is a natural matter to expect that the plurality of all aspects bound to the attributes of an entity is linearly manageable, in all contexts it comes into play: the equipment of the criteria for the entity's search page, the colums of each grid associated to an entity.

A little different scenario is found in a data form layout, where each field arbitrarily could be located in some suited position of the available area; well, this is a point where a limitation is clearly assumed: a data form sinthetized by SprHibRAD has all the fields rendered as an array. Customizing the layout is subsequently possible at the jsp level, any way, but only if required.

Even the set of detail entity grids relative to a certain entity take place along an array

Then the navigation model can be made follow the intricacies of the relational model of the database through the composition of each form: any form can collect any number of detail entities which it has a relation with, and the generic detail entity is presented trough a data grid which, always provides a link at any row to the appropriate instance

Another significant contraint which the current version of SprHibRAD is designed on, is that in any many-to-many relation, that relies on a middle entity (corresponding to a relation table in the fisical E-R model), even the middle entity is represented by a ("middle") form, even if the middle entity has no attributes (the associated table contains only the foreign keys to sustain the relation itself).

The final application, the SprHibRAD framework and the use of Spring and Hibernate

Spring configuration for the final application takes place by the Java annotation flavor and occurs like any other Spring MVC web application.

The layering of the technology is the classical one: the Data Access Object layer is invoked by a service layer. The controller layer invokes the service layer.

The DAO layer relies on Hibernate and the javax.persistence.criteria package.

A model, made by classical Pojos, makes entities available to any layer.

Controller layer and service layer are decoupled, at the component level, from the respective underlying layer via appropriate interfaces.

The three main layers are made up with a class for each entity that is represented in the model.

The specific application code descends from the strongly "annotated" Spring MVC and Hibernate assets, but the most of the implementation of each class in encapsulated in the SprHibRAD framework: this scenario is simply obtained making each class of the application inheriting from the appropriate class of the framework, available for each layer and for each entity, since all the contributions of the framework to the three main layers is implemented through java generics.

I came from an "old school" that stated that reflection should have been used a the minimum extent because of the associated lack of programming style, omogeneity, performance and other aspects. Developing SprHibRAD I changed my point of view, a little.

So that reflection and generics are basic in SprHibRAD framework.

In the controller class the default singleton approach is kept so that a customized resort to the http session object is made when needed: for example to recall a crucial SprHibRAD object (the 'Navigator' object) or to get the user preferences. (See here)

The SprHibRAD generator

As a Swing/jdbc application it has no configuration resources required, and does't make use of Spring and Hibernate but generates code based on those frameworks, that is, a Spring and Hibernate annotated code that invokes the SprHibRAD framework APIs (actually SprHibRad generator uses Spring just for password management, since it is equipped with user management feature too, the only feature that doesn't directly impact to the code generation) and jsp pages made by SprHibRAD tags.

The generator maintains an object that collects all the directives for the code generation; this object is the generation project. The project data are maintained in a file that has the same name of the project. One Project can be closed and another can be created or opened and modified or used for code generation.

The project data are organized as a Json tree and the generator code uses and improves the json-simple 1.1.1 library, for managing the project data

As it can be supposed, there are two main activities around the project object, made by the generator: the building of a project and the use of it for the actual code generation.

The building is performed by offering the user a convenient user interface resource that, first, requires to address the physical connection to the database, and after loading the metadata from it, requires the user to represent all the logic of the application architecture: at every user action the SprHibRAD generator builds a part of the project tree corresponding to the well defined context in which the user is operating.

The use of the project means parsing the tree, with more trips, one or more for each area of the final application to be generated, and taking convenient generation actions depending of the content.

Both of these activities conform to a specific grammar stated in the SprHibRAD generator design

SprHibRAD suite or simply SprHibRAD framework

--------------------------------------------------------------------------------