Sneak preview of ADF JHeadstart

Yesterday we (Hans, Harm, Rob, Wiene and myself) had a session with the Oracle JHeadstart team (Steven and Peter) where they demonstrated the upcoming ADF JHeadstart release. We also discussed new functionality, the uptake of ADF, the release schedule, our joint efforts on JHeadstart and the future of the JHeadstart 9.0.5.1 (non ADF) release.

Tentative dates suggested by the Oracle JHeadstart guys: early September a preview of ADF JHeadstart on OTN, early November – just following the JDeveloper 10.1.2 release – the first ADF JHeadstart production release. We received the alpha release of the software to start playing with it, testing it and ideally developing bits and pieces for it.

There will be a migration tool built into the JHeadstart tools: it will recognize and “old” JHeadstart (pre 10.0.1) application and automatically upgrade the application. This basically means: remove redundant attributes from EO and VO definitions and the Application Structure file. It also includes adding newly supported attributes with sensible default values.

The JHeadstart Designer Generator will be enhanced to make use of some of the new capabilities of ADF JHeadstart.

For the time being, ADF BC (pka BC4J) is the only available Persistence implementation. Over the coming months, support for Toplink should be added. However, since JHeadstart relies on the runtime DataBinding, you should be able to generate an application with JHeadstart against ADF BC, then update the data-binding definitions to use Toplink rather than ADF BC if you like. The Oracle team suggested that ADF Binding was currently much more advanced for ADF BC than for Toplink; it may be that we need to wait for JDeveloper 10.1.2 for better Toplink support.

Steven gave an extensive and impressive demonstration. He can generate almost as much already with ADF JHeadstart – in some instances even more – and has some nice features up his sleeve to follow shortly. It seems that UIX will be somewhat favored over JSP: UIX makes generation of fairly advanced UI elements relatively easy. Generating similar functionality for JSP application would be much more complex, typically requiring tons of JavaScript. UIX uses quite a lot of server-side processing in combination with Partial Page Rendering (or partial page refresh). It looks amazing sometimes. At the same time, it seems to require high bandwidth connections as the frequent server access – even for partial page refresh – would become annoying if it were to take too long. Steven indicated that JHeadstart will generate UIX pages more aligned with the Oracle BLAF guidelines (and they looked more organized indeed).

Steven was very enthusiastic about ADF UIX. Especially the many more options for customizing the look and feel with UIT-templates for each UI element and the use of skins makes UIX much more suitable for many customers. No longer is a Oracle look and feel forced upon you with UIX (one of the previous complaints); you can create applications that do not seem UIX at all, while still having all the benefits that UIX offers. ADF UIX 3.0 – to be available in the Fall 2004 – will start implementing JSF, making UIX even more acceptable to the market.

One very neat feature of ADF JHeadstart: when you create the application structure file for a certain ADF BC Application Module in a Model-project, ADF JHeadstart will automatically create default Groups, Detail Groups and Lookups, directly derived from the structures defined through ViewLinks. This means that literally within minutes you have an application running. It is a bit like the ADF BC Tester, but provides a more advanced application including HTML-selects elements for Lookups.

Generation of JSPs is now based on JSTL tags, an improvement over the Struts-tags only generation in 9.0.5.1 and before.

New features
A number of new features that ADF JHeadstart can generate:

• List of Values: autoQuery, useTableRange?, tableRangeSize, multi-value-passback
• LOV type-in-support and LOV for validation (using UIX partial page rendering, this yields impressive results!)
• MultiSelect List of Values (for creation of intersection-table entries)
• New rows in combination with TableRange
• All layout combinations for master and detail, including table-table same page
• Tree-structure
• Quick Search/Advanced Search with toggle
• Default Display values (for Find as well as Data entry)
• more control over titles and other boilerplate text, more distinction between form/find/table page texts, more control over (CSS) styles etc.
• Column Alignment setting per VO Attribute

als not yet reached but still on the list for Steven and Peter:

• unlimited group nesting
• support for ‘action items’
• support for (unlimited) breadcrumbs
• partial generation (the JAG has become quite a bit slower and in the discussion yesterday we wondered whether generation per group might be feasible)

Interesting to note how many of the things I recently created for JHeadstart 9.0.5.1 simultaneously were created for ADF JHeadstart (yesterday morning I completed the LOV autoquery, table range and pass back multiple descriptor items for 9.0.5.1, only to be demonstrated the same features in the ADF JHeadstart release). However, there are still a large number of features I did for 9.0.5.1 that are not yet available for ADF JHeadstart. One point of debate it whether and how we should make these 9.0.5.1 extensions available.

The generated struts-config.xml is much smaller than it used to be. Most of the routing JHeadstart did in there has been relocated to the JhsDataAction class, and extension of the ADF DataForwardAction. The elaborate FormBean definitions, with JHeadstart specific properties such as persistentAttribute and caseInsensitive have vanished; JHeadstart now uses the ADF BC meta-data at runtime. (I am not sure whether that means you can change them on the fly as well).

Domains are used in the same way, though we discussed implementing domains using ResourceBundles linked with keys hardcoded in the pages or, alternatively, by loading the domaindefinitions.xml using a struts plugin at application initialization – perhaps wrapping it in some interface that UIX requires or that can provide NLS support – and working from there (getting rid of the specific Struts FormBean that does hardly support proper EL and JSTL access).

Architecture of the JHeadstart Application Generator
The architecture of the JHeadstart Application Generator has changed considerably. XSLT is still at the heart of it, but much better organized and highly extensible and configurable. It makes my mouth water what it offers us in terms of opportunities for generic extensions, customer specific support etc.

The basic idea is this: the JHeadstart Application Generator recognizes a number of tags, such as $GROUP$, $CHILD_GROUP$ ,$TABLE_GROUP_HEADING$ , $PARENT_CONTEXT$, $SEARCH_REGION$ . These tags are placed in JSP-templates, JSP or UIX fragments or that are the starting point for the JAG. Some of these tags refer directly to properties in the Service, Group or Lookup section of the Application Structure file and are replaced with their corresponding value by the JAG. Note that you can even defined User Defined Properties in the Application Structure and access them through these tags. Other tags direct the JAG to other UIX or JSP fragments to be included at the location of the tag. The JAG will replace those tags with the result produced from generating the indicated fragment. You can specify your own fragments to be used as generation templates, both at the Application and the individual group level.

This basically means that you develop a prototype in HTML/JSP and include the dynamic sections with the relevant tags: here comes the Title, here go the scroll buttons, here will be the actual table-of-records. This gives you incredible control over both presentation and layout of the generated pages!

I look forward to experimenting with this release. It looks like we need not worry whether JHeadstart will still have added value now we have ADF around: the additional level of declarative programming in combination with JHeadstart’s generation capabilities add a substantial productivity gain as well as ensuring a structured development approach along with an internally consistent application. If the migration proves as simple as it looks right now, doing JHeadstart development with 9.0.5.1 will effortlessly spill over into ADF JHeadstart development – at least for the completely generated pages.