Triggered by Steve Muench’s weblog, I stumbled across a recent posting by the JHeadstart Team on their current and future activity: The Future of JHeadstart. The big news of course is that the ADF Faces releases of JHeadstart, based on JDeveloper 10.1.3, is currently planned for March 2006. To be frank, that is a little later than I had hoped for. Of course the ongoing slippage of the JDeveloper 10.1.3 Production Release was bound to push the jHeadstart release date backwards, but still – March is late and we all know that planned release dates tend to later rather than sooner.
Having said all that, given the work the team is putting in this new release, it is no surprise it takes them quite some time. They are rearchitecturing the framework, both the design time tools like the JAG and the runtime framework. The latter obviously is required for ADF Faces, that will completely replace UIX as View Technology. That means: UIX is no longer supported as of JHeadstart 10.1.3! And the same goes for Struts: “We will be using JSF as the Controller instead of Struts. As a result
we will generate managed bean definitions and navigation rules in the
faces-config, instead of the old struts-config generation.” Also the current JSP/JSTL View technology will be substantially changed: “What is now known as View Type “JSP” will also result in .jspx pages
using JSF tags. We are still investigating what mix of JSF
implementations (RI, ADF Faces, MyFaces?) we want to use in these pages.”
There does not seem to be a realistic migration path for existing UIX applications to ADF Faces. JHeadstart may be the best what Oracle has to offer in that respect. That means: when you generate your existing JHeadstart Application Structure file again, instead of UIX you will get ADF Faces – and thereby you realize a migration. You cannot take UIX pages and migrate them to ADF Faces. Any post-generation changes in your UIX pages will have to be reapplied to the generated ADF Faces pages. However, many of these post generation steps can probably be turned into generatable features, given the more enhanced functionality of the coming JHeadstart Application Generator for ADF Faces.
Generator Architecture
That design time generator is the second area of major overhaul going to JHeadstart 10.1.3:
“A new extendable and pluggable generator architecture. As you
might know, the JHeadstart Application Generator is driven by generator
templates. These templates contain tokens that are resolved and
replaced with dynamic content. Currenty, the tokens are resolved by a
mix of XSLT stylesheets and java classes. In the next release, we will
go for java classes only and we will use the Spring Bean Factory to
instantiate the JHeadstart Token Resolver classes. This will make it
very easy to plug in your own customized token resolvers: just register
them in the bean factory xml file.” This enhanced generator architecture means that we will need far fewer post-generation changes, as we can now do it through generator-changes. It is very much like the Java Template Design Pattern that I am to present about later today: the algoritm of the generation process is fixed in the JHeadstart application generator but we can override/complement its functionality in specific spots.
Another aspect of the generator’s rearchitecturing is the appearance of Item Level templates: “In the current release, one single token
represents all items in a form or table layout. This limits the
flexibility in generating non-standard layouts. For example,
conditionally rendering or disabling items, and adding other
non-databound content in between items currently requires
post-generation modifications. Item level templates will allow for much
finer-grained customizations of the layout generation. If you want, you
can even define the exact position of each item, by using index-based
or named-based item tokens.”
Reduced dependency on ADF Business Components
One of my personal favorites, and a topic I blogged about more than a year ago, is this one:”Items included in Application Structure Editor. In the current
release, the custom attribute properties are recorded against the ADF
BC View Objects. At times, this can be annoying when the ViewObject is
used in multiple groups with conflicting attribute settings (for
example display of a parent-referencing attribute). Furthermore, it
limits the JHeadstart Application Generator to using ADF Business
Componenst as a Business Service. In the next release, the group items
(attributes) will be defined inside the application structure file. We
will provide a “Synchronize” option to automatically load the
attributes from the Data Control Collection (the View Object Usage in
case of ADF BC) that is associated with the group. This will make it
possible to support Toplink and other Business Services in the future
(not planned for the first 10.1.3 release).” So instead of ab-using the ADF Business Components as a kind of meta-data store, even to a small extent at run-time, we will see a separate ‘repository’ with the JHeadstart meta-data. It opens up the way for the support of other Model technologies besides ADF BC – not planned for the 10.1.3 JHeadstart release – and it opens up other possibilities as well. The ADF BC configuration files are tricky to manipulate, objects cannot easily be copied – that’s what we created the AMIS View Object Copy plug in for JDeveloper for – or be compared etc. With the meta-data in a place separate from ADF BC, there are quite a few things we can do. It also potentially to a certain level frees up JHeadstart from Oracle JDeveloper! Of course there is a still the dependency on ADF Binding Framework and now on ADF Faces, but stricly speaking these can be used with other IDEs as well – or even without IDE if you can generate the ADF Bindings. I do not really expect the JHeadstart team to go down this road in the short term, but the option will be there..
Generator functionality
The team promises us a number of new features in the Application Generator. The one most attracting my attention is: “Support for unbound items and action items. In addition to items
that are bound to an underlying model attribute, we will support
unbound items. The existing display types will be supported for these
items. Action items can be displayed as hyperlink, button or image.” It does not say with so many words, but I have to presume that this means we will be able to define navigation between groups and have JHeadstart generator the logic for that. For example: in my Employees page I have a reference to the Department that the current Employee is working for. I can now generate a button that will take me to the Department page for that particular Department – possibly even a popup page.
Furthermore there is a number of new layout-styles such as overflow right and below – familiar to previous Oracle Designer users (you may wonder: where is the SpreadTable for complex hand-eye coordination) – and Tabbed Regions – stacked item groups – and Stacked Child Groups (currently supported through a custom generator template). There is also a Wizard layout style, one I have hoped to see for some time and had to create at some point by hand. Not pretty.
Finally the post continues to discuss some smaller enhancements – some of which I had planned on creating for 10.1.2.1 just last week, like showInQuickSearch and showInAdvancedSearch. I will probably do them anyway, as we need them right now.
Conclusions
JHeadstart is very much alive and kicking! The new functionality looks cool. It also demonstrates the vitality of the basic concepts underneath JHeadstart: it is reincarnating for the third time since 2001. It has survived the Oracle 9iAS MVC Framework for J2EE (aka Cleveland) and now it will survive Struts, plain JSP and UIX. If you never made post-generation changes, you might have taken your application from 2001 to 2006 without substantial effort. Meta-data driven – no, let’s rephrase: Model Driven – Development is incredibly valuable.
