JsfCrudGenerator65

Revision as of 13:06, 5 November 2009 by Admin (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

About This Page

This page discusses the JSF CRUD Generator enhancements in NetBeans 6.5.

For information on the JSF CRUD Generator in NetBeans 6.1, see JsfCrudGenerator.

For information on the consulting agency database for use with NetBeans 6.1, see JsfCrudGeneratorConsultingAgency.

For information on the Timecard application, which extends the consulting agency use case, see JsfCrudGenerator65Timecard.

For information on the JSF CRUD Generator in NetBeans 7.0, see JsfCrudGenerator70.

Generate Default Stylesheets

In NetBeans 6.5, a jsfcrud.css stylesheet is generated automatically and used by the generated pages. In NetBeans 6.1, a similar effect can be achieved manually by following the steps in the "Styling the Application" section of JsfCrudGeneratorConsultingAgency.

Provide Option to Generate Ajax-Enabled Application

In NetBeans 6.5, the final pane of the JSF Pages from Entity Classes wizard includes a checkbox labeled "Ajax-enable generated pages". If the user checks the box, the wizard adds the commons-logging, jsf-extensions-common, jsf-extensions-dynamic-faces, and shale-remoting jars to the project. The wizard also adds an entry in the web.xml file and generates jsfcrud.js and AjaxScripts.jspf files. As a result, the generated application uses Ajax requests instead of conventional ones. For additional gloss, an animated image is displayed at runtime while the user waits for the Ajax response to arrive.

Improve Ease of Customization

The JSF CRUD Generator feature in NetBeans 6.1 provides advanced support for generating a JavaServer Faces application from a database schema, well exceeding comparable functionality in Ruby on Rails. In further evolving this feature 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 Java 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.

In NetBeans 6.1, the JSF CRUD Generator generates JPA controller logic as part of the generated JSF 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. In NetBeans 6.5, I have separated this logic into JPA controller classes for general use. I have also written four new exception classes for use by the JPA controllers. The user generates the JPA controller and exception classes via a new wizard, namely, JPA Controller Classes from Entity Classes.

Whereas in NetBeans 6.1 general JSF logic is duplicated in every JSF controller, in NetBeans 6.5 I have moved such logic into two utility classes, namely, JsfUtil and PagingInfo.

The remaining code in the JSF controller classes is specific to the generated JSPs and will likely serve as example code for the user's own JSF 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, and have undergone only minor changes in NetBeans 6.5.

Presuming the user customizes (or rewrites) the JSF controller classes and not the entities, JPA controller classes, or converters, what happens if the database schema requires modification? In order to support this scenario, it is advantageous for the JSF controllers to be free of per-property code, so that the database modifications do not impact the customized JSF controllers. In NetBeans 6.5, I achieve this via a new ELResolver, namely, JsfCrudELResolver, which is created as a sibling of JsfUtil and PagingInfo.

To summarize, the flow of events I envision is as follows: the user generates entities, JPA controller classes, four exception classes related to the JPA controllers, converters, three JSF utility classes (JsfUtil, PagingInfo, and JsfCrudELResolver), JSPs, and JSF controllers--and customizes/rewrites only the JSPs and JSF 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 exception and utility classes will not change after the database modification; the JSF controller classes generated will be the same ones generated earlier, prior to customization. Naturally, the user will only have to customize the JSF controller classes and JSPs according to the application requirements after the database modification.

The various files and folders are treated as follows when either the JPA Controller wizard or the JSF Pages wizard is rerun.

welcomeJSF.jsp
(JSF Pages wizard) Regenerated only if not found. If found, only links not already present are inserted.
jsfcrud.js, jsfcrud.css, busy.gif
(JSF Pages wizard) Regenerated only if not found.
AjaxScripts.jsfp
(JSF Pages wizard) Regenerated only if not found.
faces-config.xml
(JSF Pages wizard) Modified as necessary, but references JSP subfolders, JSF controllers, JPA controllers, and converters that correspond directly to the entity names, rather than artifacts generated subsequently that have a number appended to the name.
JSP Subfolders
(JSF Pages wizard) Regenerated, appending a number to the filename as necessary, matching with the corresponding JSF controller name.
JPA Controllers
(JPA Controllers wizard) Regenerated, appending a number to the filename as necessary. (JSF Pages Wizard) Regenerated only if not found.
JPA Controller Exception Classes
(JPA Controllers wizard, JSF Pages wizard) Regenerated only if not found.
JSF Controllers
(JSF Pages wizard) Regenerated, appending a number to the filename as necessary. Contain member variables of the JPA controller and converter types that correspond directly to the entity names, rather than types generated subsequently that have a number appended to the name.
JSF Utility Classes
(JSF Pages wizard) Regenerated only if not found.
Converters
(JSF Pages Wizard) Regenerated, appending a number to the filename as necessary, matching with the corresponding JSF controller name. Contain local variables of the JPA controller types that that correspond directly to the entity names, rather than types generated subsequently that have a number appended to the name.
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo