How to migrate Domains and Table Definitions with the JHeadstart 10.1.2 Designer Generator
The JHeadstart 10.1.2 release for ADF and JDeveloper 10.1.2 – published late February 2005 – includes a substantial number of improvements over the previous 9.0.5.x releases of June 2004 and October 2004. The main change surely is the support, both Design Time and Run Time, of the ADF Binding Framework that ties View/Controller to the Model and its registered Business Services (based on ADF Business Components).
Among the less visible changes is the rearchitecturing of the JHeadstart Designer Generator (JDG). The JDG is a tool that can read definitions from Oracle Designer – such as Module, Table or View and Domain definitions – and generate them into ADF BC Entity Objects, View Objects, Associations and ViewLinks, the JHeadstart Application Structure File and the Domain Definitions file. Since Oracle Designer is capable of capturing the essence of any Oracle Forms application, with the JDG we have a way to migrate a substantial portion of any Oracle (Web)Forms application, whether generated from Oracle Designer or not.
The 9.0.5.x and previous releases of the JDG allowed us to select individual Tables or Views, Domains and Modules in Oracle Designer for generation to JDeveloper. I should know: I used to developer the JDG! When you selected a Module, all associated Tables and Views were automatically included by the JDG. In the same way, for any selected Table or View, the associated Domains were automatically included.
In this 10.1.2 release, the JDG is built on top of the ‘standard’ JDeveloper Designer-to-ADF BC tool, rather than its own custom code. This as such is a good thing, one that focuses resources on Oracle’s part. However, as a consequence, we have lost the ability to directly select Domains, Tables or Views in Designer. We can only select Modules – and the JDG will include all associated objects for us. While this may not seem a major issue, for organisations that use Designer for Database Design and Generation, but not for Module Design, this does entail a loss of functionality: there no longer is a hook for the JDG to generate any objects in JDeveloper based on Designer definitions. Note that Entity Objects derived by the JDG from table definitions in Designer are much richer than Entity Objects derived by the ADF BC Ã‡reate Business Components from Tables’ wizard: they have such essential or at least time-saving JHeadstart properties as default display type, prompt, display length, domain, server derived (i.e. Refresh After Insert and Not Mandatory in ADF BC), hint text etc.
There is of course simple workaround: create a dummy module in Oracle Designer. Create (default) Module Components for every Table or View in Oracle Designer that you would like to have Entity Objects, Associations and perhaps Default View Objects for. This would also give you entries in the Domain Definitions file for every Domain associated with a column in one of these Tables or Views. In the JDG, just select the Dummy Module. The JDG will process all Tables, Views and Domains and create the desired Entity Objects. It will also create ViewObjects for the Dummy Module’s Module Components. You can either keep them or discard them as you please.
Note that you can easily create ‘default’ ViewObjects for Entity Objects from the RMB menu. Also note that the JDG will derive any custom property’s value by looking at the ViewObject Attribute and then turning to the underlying Entity Object’s attribute for any property not explicitly set at VO level. That means that having derived the Entity Object from Oracle Designer with all display oriented properties on Table and Column definitions is very useful indeed.