About This Page

This page discusses the JSF CRUD Generator enhancements to be included in NetBeans 6.5. For information on the JSF CRUD Generator in NetBeans 6.1, see JsfCrudGenerator. For information on a use case to feature in tutorials and demos, see JsfCrudGeneratorConsultingAgency.

Generate Default Stylesheets

The stylesheets in stylesheets.zip will be generated automatically, and the generated pages will use them. In NetBeans 6.1, the same effect can be achieved manually by following the steps in the "Styling the Application" section of JsfCrudGeneratorConsultingAgency.

Provide Option to Generate Ajax-Enabled Application

The final pane of the JSF Pages from Entity Classes wizard will include a checkbox labeled "Ajax-enable generated pages (requires plugin: Project Dynamic Faces Ajax Components and Samples)". Alternatively, the checkbox may just be labeled "Ajax-enable generated pages" and a separate note may appear below the checkbox that reads "Note: Ajax-enabling the generated pages requires the Project Dynamic Faces Ajax Components and Samples plugin." If the user does not have the plugin already installed, the checkbox will be unchecked and disabled. If the user does have the plugin installed and checks the box, the wizard will extract from the dynamicfaces.complib the commons-logging, jsf-extensions-common, jsf-extensions-dynamic-faces, and shale-remoting jars and add them to the project. The wizard will also add an entry in the web.xml file and generate jsfcrud.js and JsfExtScripts.jspf files. As a result, the generated application will use Ajax requests instead of conventional ones. One possibility for additional gloss is to display an animated image while the user is waiting for the Ajax response to arrive.

Improve Ease of Customization (WAS: Support Database Modifications Even After Customizing the Generated Application)

This is the second proposal for enhancements to the JSF CRUD Generator and related functionality. The first proposal was titled "Support Database Modifications Even After Customizing the Generated Application," and considered using comments to identify parts of the generated JSF application with the intent of comparing the code to be generated with any comparable code generated earlier.

I proposed such behavior tentatively based on requests for offering a "round-trip" use case where the JSF CRUD Generator can be rerun even after a user has customized the generated application and modified the database schema. However, we must consider how a user will likely use the JSF CRUD Generator. In many real-world scenarios, the developer begins with the endpoints of the architecture, namely, the database schema and HTML mockups, and must undertake hooking them up. In such scenarios, the user will want to to generate the entities and JSF application, and, with the least possible effort, leverage the generated code to wire the mockups and entities.

The obvious process is for the user to pluck elements from the generated JSPs and plug them into the HTML mockups. After doing so, the user will likely relegate the generated JSPs to an old desk drawer for safekeeping. Then the user is likely to want a clear sense of what parts of the generated controller and converter code can be used as-is versus those parts that are specific to the generated JSPs and thus must either be customized, or, alternatively, serve as example code for the user to write new application logic.

Currently, the JSF CRUD Generator generates JPA controller logic as part of the generated controller classes. This JPA controller logic performs the work of creating, editing, or destroying an entity, and is not specific to the generated JSPs or even to JSF. This logic could be separated from the generated controller classes for general use. In fact, it would be more appropriate if generating a set of classes containing this logic were an option in the Entity Generator wizard. That wizard could, for instance, feature a checkbox labeled "Generate JPA CRUD controller classes." Of course, we have to consider whether doing so would adversely affect the user experience in combination with other wizards--such as the REST wizard. (Alternatively, though risking the perception of too many wizards, these classes could be generated via a separate wizard.)

Provided that the JPA controller logic has been moved to separate classes, we can also move general logic that is useful in any JSF application, and which currently is being duplicated in every generated controller, into a general utility class (except for such logic pertaining to paging, which can be moved into a specific class for that purpose).

The remaining code in the controller classes is specific to the generated JSPs and will likely serve as example code for the user's own controller logic. This includes the code that invokes methods in the JPA controller classes and demonstrates which exceptions to catch.

The converter classes can be used as-is, without customizing.

Presuming the user customizes (or rewrites) the controller classes and not the entities, JPA controller classes, or converters, what happens if the database schema requires modification? It turns out that with a small change to the JSF CRUD Generator wizard's own logic (generating a "converter" attribute on select-many listboxes), no per-property code will be generated in the controller classes. This means that short of removing or adding a table to the database, modifying the database schema will not result in any change to the generated controller classes.

To summarize, the flow of events I envision is as follows: the user generates entities, JPA controller classes (from the Entity Generator wizard), converters, two utility classes (JsfUtil.java and PagingInfo.java--names subject to change), some exception classes, JSPs, and controllers--and customizes/rewrites only the JSPs and controllers. If the user modifies the database schema, the user can rerun the wizards and simply use the new entities, JPA controller classes, and converters. The utility and exception classes will not change after the database modification; the controller classes generated will be the same ones generated earlier, prior to customization. Naturally, the user will only have to customize the controller classes and JSPs according to the application requirements after the database modification.

There has been some discussion about possibly permitting the user to customize the generated code from one or both wizards through the use of templates. Below is a summary of my thoughts according to file type:

JSPs

Templating is unlikely to be useful to the user, since each HTML mockup will vary rather than follow a pattern established by the database schema. This is true also for languages other than Java.

Controller classes

Templating might be useful to the user for Java and non-Java applications, but I think we would need evidence of user demand for this.

Entity classes

I do not understand why a user would want to customize this logic (via templates) for Java applications, though apparently some users have requested this capability. It could be useful for non-Java applications, but at present I have no reason to believe non-Java developers would be interested in such a feature. I think we would need evidence of user demand for this.

JPA controller classes

I do not understand why a user would want to customize this logic (via templates) for Java applications, though perhaps some users have requested this capability. It might be useful to the user for non-Java applications, but I think we would need evidence of user demand for this.

Converters

Templating might be useful to the user for JSF applcations, but I think we would need evidence of user demand for this.

Utility and Exception classes

Templating would not be useful to the user for these, since they do not depend on the database schema.

Overall, I think I need to better understand why a user would want to customize the entities and JPA controller classes. And it seems we would be wise to confirm user demand for templating these or any other files in the equation. We can continue to consider templating for this release, but strictly on a time-permitting basis rather than as a requirement.