AMIS Query: The Future of Oracle Designer (and other tools)

Roads Ahead – What will or could happen around Oracle Designer?

In this after dinner session – we had a fine Chinese meal with ice cream as desert and coffee to top it off – we discussed some of the developments around Designer we may expect or fantasize about. The motherlode of meta-data we find in Oracle Designer represents such an enormous wealth – as well as investment for many organizations – that we can and probably should to look for opportunities to make further use of it. And we may also reluctantly spy out for migration paths…

The generation of HTML DB applications from the module definitions in Designer seems very atractive: the structure of the data as well as the underlying technologies provide an excellent fit. I am not sure how much HTML DB will be used and it seems not very plausible for people to actually build such as migration bridge from Designer to HTML DB. It is an interesting option nevertheless.

I also demonstrated some extensions to Repository Object Browser that I developed during the Summer. As former developer of the Oracle Designer Web Assistant – for 98% the same code as the ROB, I find it fairly easy to extend the ROB’s functionality. The ROB provides an interesting opportunity for extending Oracle Designer – the PL/SQL source of the ROB is shipped to all Designer customers, and , contrary to the Visual C++ code behind the RON and the Design Editor, can easily be extended. I wonder whether we can turn such a ROB Extension undertaking into an Open Source project. It depends probably on Oracle Product Management, since such an effort is probably a violation of many license conditions.

The Oracle Forms Post Generator – enhanced generation of Forms

One of the options discussed is the following: using the Java Development API of Oracle Forms, it has become viable for mere mortals to programmatically manipulate FMBs – Forms source files. This opens up the following route:

• A Form is generated from Oracle Designer
• The generated form is copied; the copy will be used a reference later on.
• Manual changes are applied post-generation – because some features are not supported by the Designer Forms Generator, and maybe also because the developer does not want to spend 80% of development time of trying to get the Oracle Forms Generator to do something that takes approximately 10 seconds in Forms Builder.
• Both pure generated form and post-generation-manipulated copy are converted to XML – this is supported by WebForms 9i and later
• The two XML files are compared – standard XML comparison software is available. The result of this comparison is an XML representation of the post-generation changes. It is stored, for example in the Module Definition in Oracle Designer.
• When the Form is generated again, the manual post-generation steps can be applied automatically by running the Post-Forms-Generator; it reads the XML representation of post-generation changes and uses the JDAPI to manipulate the FMB file accordingly. This amounts to the same thing as applying these changes manually to the FMB file. We should even be able to automatically invoke the post-generator after the Forms Generator has run.

I did a brief demonstration of using the Forms JDAPI to apply some post-generation changes to a Form I had first generated from Oracle Designer. (in this demo, the post-gen changes were recorded in hard-code in a small Java program) The Post generation changes involved changing size, prompt and position of an item, including a boilerplate image and changing the appearance of a Scrollbar. The effect made quite an impression on the audience and the over-all feeling seemed to be that this might indeed prove a viable route for bridging the gap between Oracle Designer’s OFG and Oracle Forms, that will widen as time progresses. I intend to further extend my demo into a prototyp for the entire procedure. At that point I will open discussions with Oracle Consulting and/or start an open source project for further development.

JHeadstart Designer Generator – Generation of Java/J2EE Applications from Oracle Designer

Always a pleasure to demonstrate: without writing any Java Code, I can create a fullblown, completely functional Java/J2EE Web (HTML) Application from a Module definition in Oracle Designer. It is very powerful indeed.

Should we migrate from Designer & Forms to Java/J2EE?

Of course we also ended up having the discussion: should we migrate from Designer/Forms to Java/J2EE. I cannot pretend to speak for all present, but I have very strong views on this one – that were echoed by several voices in the audience:

existing Forms applications are seldomly likely candidates for migration to Java/J2EE (which typically means an HTML user interface). Apart from the fact that it is a very costly exercise that by itself does not render any business value – after all the migration will by and large give you what you started with -, it does not make sense for any other reason except for a zealous belief that Oracle should be chucked as a vendor for one’s organisation.

For new applications – and subsets of existing Forms applications for a new user community – targeted at potentially untrained end-users for performing simple, infrequent tasks (often indicated with the term self-service style) – HTML user interfaces driven from a Java middle tier are probably a good idea.

There is no compelling reason to move to Java/J2EE perse. If anything, the SoDs on Designer and Forms are a reason to only consider Java/J2EE for new, self-service applications. That happens to be the exact same strategy followed by Oracle Applications!

That is not to say of course that Java (and XML) technology will not be ery beneficial to organizations doing application development with Designer and Forms. As discussed before, Forms is opening up to Java in many ways that offer tremendous opportunities. The EAI – Application Integration – objectives are often best met by Java & XML technology. I would encourage any organization to starting dipping toes in Java. However I would strongly advise against rushing into Java because it feels like a ‘must’. You must be very sure as to why you want to use Java/J2EE technology – not just start using it. In many respects, Java based application development is not nearly as productive as Designer/Forms based development and it currently is much more complex. Do not expect typical Deisgner/Forms developers to become really productive – let alone self-sufficient developers who can do without guidance- with Java/J2EE development within one year (and even that is quite optimistic, no matter what Oracle claims about ADF).