Jheadstart Migrating .pll library from designer

Question

Hello..
As teh library is concerned I have the total code for my forms in the library. The library contains all the trigger code on form level, block level and item level. This library contains the code for nearly 70-80 forms and the total business of the application is present in these forms.
As the forms internally call this library will I need to add the code manually in the java environment forms or can I migrate the library along with the form migration itself.
One more thing; I have a runtime database and designer database. After migration of the database how can I attach the generated Application with the runtime database so that I will be able to get connected to the database and retrive the existing data into the newly generated forms.
Hope to hear from you in this regard.

Answer 1

Azher,
What JHeadstart migrates is the declarative, transactional behaviour of the blocks in the form. So basically the stuff that works without PL/SQL code. The J2EE architecture you are migrating to is very different from the Forms architecture. There are no form-, block- or item-level triggers, and what's more, there's probably code in those triggers that calls Forms built-ins that do not exist and have no replacement in the J2EE architecture we are using.
Therefore you will have to migrate any trigger/library logic that still makes sense to have in the new situation. Note that often not all code NEEDS migration, simply due to the fact that an HTML web application is a very different TYPE of application than a Forms client.
If you went overboard on 'thick-client UI features', where items and buttons are enabled/disabled/shown/hidden/coloured/filled with every action of the end user, you will either end up writing tons of javascript code, or you will give up and decide that an HTML application should not depend so heavily on this type of interaction.
For the code that you do want to migrate, the most important thing to do is to determine WHERE in the new architecture this needs to be implemented. You will have to think more in terms of 'migrating functionality' than 'migrating lines of code'.
I would recommend just trying the JHeadstart Designer Generator on a couple of Forms, running the application and determining what functionality is missing (compared to the original Form). Then you will need to think about where and how you would implement this functionality in the new architecture. Is is something that could/should be done in the ADF BC objects, or in the View pages, or in the controller, or perhaps a combination of those. Chances are that you will not even need to look at the original PL/SQL code that implemented this functionality in the Forms.
As to your question about connecting to your runtime database: the JHeadstart Designer Generator wizard will prompt you to create/specify two JDeveloper Database Connections, one to connect to the Repository, and one to connect to the runtime database. Your generated application will by default connect to the latter when running it. Of course this can be changed when deploying your application in another (production) environment.
This an much more information can be found in the JHeadstart Developers Guide, in the chapter on the Designer Generator.
Kind regards,
Peter Ebell
JHeadstart Team