After becoming much more literate in ADF UIX over the last two days in the workshop, today was the day to see how JHeadstart could take us to the next level of productivity. The executive summary was that I was very impressed after getting real hands-on time using the facilities that it brings to the table. The seamless ADF JHeadstart plugin for JDeveloper 10.1.2 installed in a second and made itself useful in short order. Starting from a new ADF application module exposing the data model to support several "back office" use cases involved in the workshop, we generated a default JHeadstart application structure file. This XML file captures declarative info about how you want your application UI organized into logical groups of information. The JHeadstart plugin adds declarative editors to let you tweak all of the various preferences that control the generated application and automate the process of generating and/or regenerating the application based on these preferences using the JHeadstart Application Generator.
To start the process off quickly, the JHeadstart plugin gives you a default application organization that reflects the hierarchical structure of your application module's data model, including picking up all the places where foreign-key lookups make sense. You can start from this and evolve it to be what you need for your application, introducing different groupings, nested groupings, logical regions of related information within a group. We iteratively advanced our backoffice application by changing some preferences, using the JHeadstart Application Generator, then running our application, all from the comfort of the JDeveloper environment.
We went through progressive refinements of the initial design by picking from a rich set of layout styles including table displays, form displays, and trees, and make quick work of configuring how the user would be able to "drill down" from some master information to its one or more details. We explored setting preferences to generate our foreign-key lookups as both drop-down lists and Oracle Forms style filterable LOV's with use-LOV-for-validation, or alternatively as basic drop-down lists. A nice touch was that table displays could support multi-row editing, master/detail editing on the same page, and that the drop-down lists automatically would include "null" entries in the list when fields were optional. By indicating which fields were important enough to be in a summary table display, other fields were automatically moved to be shown only when the user clicked to see more info. We added powerful quicksearch filtering fields or full-fledged advanced search forms to our pages where needed with other settings in the application structure file.
The cool thing is that what JHeadstart is generating is not any new Java code. It's fully leveraging the ADF framework and its various extensibility points and best practice techniques, but saves you the time of individually creating the pages in the application, their UI Models containing relevant ADF bindings, and the event-driven page flow between the pages. The generated result, to complement your existing ADF business service, is the full "view" and "controller" layer to go with it. This comprises a set of JSP or UIX pages, their corresponding ADF binding UI model files, the struts-config.xml entries to describe the page flow between the pages, and nicely organized message bundles if you indicate you want an internationalizable web application. Some of the more sophisticated application features depend on having a few extended JHeadstart versions of classes like the ADF application module and the ADF data action, but the JHeadstart Application Generator takes care of setting this usage up for you. Such framework extensions are a best practice you will find leveraged in virtually every well-written ADF-based application. The only difference is that the JHeadstart team wrote them instead of your having to. Once you're iterative application generation arrives at an application that has the look, organization, and navigation that you like, should you need to you can customize the application artifacts in JDeveloper in exactly the same way as for pages that you have built without the generator. The JHeadstart Application Generator has properties you can set to selectively "freeze" areas of the application structure after doing this kind of post-generation customization so that those certain pages won't get re-generated by the JAG. We'll learn more about it tomorrow in the last day of the workshop, but the exercises we did today hinted at how the JAG is template-driven to have good control over customizing what gets generated by default as well.
In summary, in the first two days of the workshop we proved to ourselves that the features like what JHeadstart generates can be achieved by building the pages incrementally using JDeveloper's Struts Page Flow diagrammer, Visual Web Page Editor, Data Control Palette, Property Inspector, UI Model window, and Code Editor. Knowing how to use the base JDeveloper editors and ADF features to build such pages is important in order to build your applicaton's showcase pages that require a custom UI treatment that the JAG might not yet be able to automatically generate. However, for cranking out the large majority of your ADF-based web application in a consistent, highly functional, and declarative way, leveraging the JHeadstart application generator seems like a really compelling jumpstart from where I'm sitting.
2:23:30 AM 
|
|
