OpenXava is a framework for Rapid Web Development, well-suited for business- and database-oriented applications.
OpenXava lets you develop applications just by writing simple domain classes with Java or Groovy. The user interface is generated automatically in runtime, without code generation.
The main differences with Grails are:
- it does not use code generation— you write less code for the first version of your app, but you also have to manage less code for all application lifecycles.
- it's based in Java standards— it uses JPA, Portlets, Dependency Injection, Bean Validation and other Java standards, so you can move your code to other frameworks in any moment.
- the application generated by default by OpenXava is richer than the one generated by Grails— An OpenXava application is ready for production from the first time.
OpenXava 4.6 has some new interesting features such as:
Custom reports generation from list.
It’s possible to customize the list mode defining your own editor.
You can assign a model object (an entity or a transient object) directly to a View to populate it.
In the jUnit tests you can assert the content of generated PDFs
New @RowAction annotation for collections.
Labels and messages available in Russian.
The file name for generated reports includes model name and time.
And many other useful new features and bug fixes.
Custom reports generation from list
In list mode there is a new action called Custom report:
When the user clicks on it he gets the next dialog:
This dialog allows the user to define his own report. He can add and remove columns, specify filters, ordering and set the report title. It’s true that the features are almost the same of the already existing Generate PDF, because the user has always been able to add, remove and move columns, and filter and order in the list. Maybe the only advantage of the new UI is that the user can specify ordering for more than 2 columns and that he can specify the report title. The important thing is that this new UI for reporting will allow us to add new interesting features in future versions, such as storing the reports by name to recover them afterwards, specifying labels and width for columns, using hidden columns for filtering and ordering, etc.
Custom editors for list mode
The standard list mode is very powerful and suitable for most case, but sometimes you need something special for your list. To meet this necessity we have added the possibility to define custom editors for @Tabs. Therefore, if you want the customers list would be displayed in this way:
You have to define a @Tab in your entity as following:
@Tab ( name ="Cards", editor="CustomerCardList",
properties="number, name, type, address.city, address.state.name"
And also define the editor in the editors.xml file of your project:
<editor name="CustomerCardList" url="customerCardListEditor.jsp"/>
Of course, you have to write customerCardListEditor.jsp to render the customers in your own way. Learn more details about how to choose an editor for a @Tab in the reference guide.
Moreover, it’s possible to define an editor for all the lists of a model or even for all the lists of your application. Look at the customizing chapter of the reference guide.
With the addition of lists now we have editors for properties, references, collections and lists, thus the customization of the UI generated by OpenXava is total. You get exactly the UI you want.
Assigning model objects directly to View
Until now to put and get the data from a view based on a transient class you needed to use getView().get/setValue() with simple values or getView().get/setValues() with maps, you couldn’t use the model object directly. Since OpenXava 4.6 you can use model objects to populate the view. So, a code like this is possible:
DateRange range = … // DateRange can be an entity or a transient class
getView().setModel(range); // Populate the view with range data
This code populate the view with data from the DateRange object, even if the view currently is not displaying a DateRange the view is changed to display it.
Asserting PDF content in jUnit tests
Now you can verify that the content of the generated PDFs in your jUnit tests is the correct one. To do this ModuleTestBase has the following new methods: getPopupPDFAsText(), printPopupPDFAsText(), getPopupPDFLine(), assertPopupPDFLine(), assertPopupPDFLinesCount() and getPopupPDFLinesCount(). From now on you can write test code as following:
assertPopupPDFLine(1, "jUnit Carrier report");
assertPopupPDFLine(2, "Name Number Zone");
assertPopupPDFLine(3, "CUATRO 4 1");
A good news for all of us that love automated testing.
@RowAction for collections
@RowAction allows to define an action to be show in each row, but not in the collection button bar. If you write a code like this:
Collection<OrderDetail> details = new ArrayList<OrderDetail>()
You’ll get the next user interface for the collection:
Note as Reduce quantity action is in the row but not in the button bar. Read more about @RowAction at wiki.