54
Metamorphosis from Forms to Java: a technical lead's perspective Michael A. Fons RMOUG Training Days February 2007

Metamorphosis from Forms to Java: a technical lead's perspective

Embed Size (px)

DESCRIPTION

JSF Presentation I did for RMOUG training days conferenece 2007

Citation preview

Page 1: Metamorphosis from Forms to Java:  a technical lead's perspective

Metamorphosis from Forms to Java: a technical lead's

perspective Michael A. Fons

RMOUG Training Days

February 2007

Page 2: Metamorphosis from Forms to Java:  a technical lead's perspective

Think…

• “A change of any consequence to an Oracle Form of any consequence is complex and convoluted.”

– somebodyorother

Page 3: Metamorphosis from Forms to Java:  a technical lead's perspective

“Greetingthz…” (apologies to Ernie Kovaks)

• I researched this topic as part of a strategic move while working as a team lead at the US Air Force Academy. I am now at Graebel Companies, Inc.

• I have 16.5 years of experience with PL/SQL and Forms.• Along the way I have done some work with Java…not

“gobs.”• For this paper I researched several publications (by Peter

Koletzke, Steve Muench, and others), studied blogs, and interviewed experts and co-workers.

• I want to share what I have learned during this process.• The paper will give more detail if you need it.• This presentation is ½ planning issues, ½ technical issues.• This presentation covers a lot of ground. Details are

usually just “highlights.”

Page 4: Metamorphosis from Forms to Java:  a technical lead's perspective

Planning Highlights

Page 5: Metamorphosis from Forms to Java:  a technical lead's perspective

Why Switch?

• Oracle claims they have no plans to de-support Forms, so why switch?

• Forms feels more and more like COBOL every day to me…(I was just called an “old-school Forms programmer” by a potential employer – no kidding!).

• New developers are educated in different technologies like Java. This changes the market place.

• JSF may be “lighter” than Forms on the web.• Possible reasons to dislike the Forms paradigm:

– inadequate GUI palette– enter query mode is non-intuitive– complex trigger interaction makes troubleshooting and

programming difficult– JInitiator admin/installation on the fly may be a pain

Page 6: Metamorphosis from Forms to Java:  a technical lead's perspective

Why Switch?

• More Reasons:– Oracle is migrating/has migrated their own

applications to Java (c.f., Metalink, Apps?).– IDC (40+-year-old market intelligence

provider) seems to indicate ultimate strategic direction of Oracle is toward Java.

– Java is powerful and open source.– JDBC provides DB independence and

portability.

Page 7: Metamorphosis from Forms to Java:  a technical lead's perspective

So you’re gonna switch to Java…

• This presentation assumes you have already decided to switch from Forms to Java.

• …then just do the following:– Convert (or replace) current existing applications– Train non-Java employees

• Get to know how individuals learn best (by course, by seat-of-the-pants, etc.).

• Get to know what training options exist and at what cost.• Give prototype assignments to people who handle it.• Find time for the STEEP LEARNING CURVE for…

– JDeveloper– ADF– J2EE/OOP

• Find money…for training, hardware, software…

Page 8: Metamorphosis from Forms to Java:  a technical lead's perspective

Conversion Approaches

• Approach 1: All-at-once– First phase:

• accept no new development projects

• focus on stabilizing old system

• put all new development projects off until second phase

– Second phase:• do all new development on

new system• do no new work on old

system

• Naval academy did this not too long ago.

Page 9: Metamorphosis from Forms to Java:  a technical lead's perspective

Conversion Approaches

• Approach 2: A-bit-at-a-time– Do some pilot projects to

convert parts of your system.

– Work out what you need to do to allow Forms and Java code to co-exist.

– As developers come on-line with Java you can convert more and more of your code.

• This may be a more popular approach.

Page 10: Metamorphosis from Forms to Java:  a technical lead's perspective

Analysis of Approaches

• With all-at-once approach…– The development team is super-productive on…

• old system during the first phase.• new system in the second phase.

– The only distractions to conversion are emergency fixes in both phases.

– This approach requires serious buy-in from the top.– This approach is higher risk because second phase

“productivity” is theoretical until massive cutover.

Page 11: Metamorphosis from Forms to Java:  a technical lead's perspective

Analysis of Approaches

• With a bit at a time approach…– End-users will see…

• fewer radical changes to how much productivity they receive.• (due to learning curve) a medium-sized drop in the number

of– Fixes

– Enhancements

– New Developments

• an increase in IT flexibility (due to extra victories, challenges, and new learning opportunities)

• increased opportunities to give feedback to the IT staff.

Page 12: Metamorphosis from Forms to Java:  a technical lead's perspective

Whichever approach you use…

• …do SOMETHING!!– Action…

• gets you started down the path.• suppresses feeling overwhelmed and depressed.

– Start…• Planning.• Learning.• Experimenting.

Page 13: Metamorphosis from Forms to Java:  a technical lead's perspective

Planning• Form-level pl/sql logic will need converting (.pll’s, Form triggers, Form

program units). Where will the new business logic go?– at database level?

• triggers, stored procedures• this may save corporate investment

– at Business component level? • App Modules, View Objects• this may save unnecessary trips to the database

– in the presentation layer? • Managed Bean code• some logic may “fit” better technologically here

• Are you going to share ADF BC Entity/View Objects between applications?• What are you going to use for…

– Configuration Management (CM) (e.g., subversion)? – Testing (e.g., JUnit)? – Modeling (e.g., UML, Use Case)? – Coding/GUI (e.g., Java, ADF, JSF)?

Page 14: Metamorphosis from Forms to Java:  a technical lead's perspective

Planning

• More on converting your Forms– Forms look and feel (LAF) is different from

JSF GUI LAF. How will you map it?– Forms components may not map 1:1 with

JSF/ADF components.– Are you going to use any automated

conversion tools? • Google on “migrate oracle forms to java” for lots of

hits on tools to do this.

Page 15: Metamorphosis from Forms to Java:  a technical lead's perspective

Learning

• Interleave code practice with “book-learnin’.”• Free learning:

– Read Blogs (Muench, Nimphius, etc.), Technet docs/examples, buy/borrow books, attend free/cheap conferences, ask around.

– Share what you have learned with co-workers like with • brown-bags • simple conversations

• Not-free learning:– Group Training

• Checked out a couple companies– comparable…about $1000/day for 10 people. – May offer mentoring packages.– Government can get GSA rates.– Oracle Corp training is a lot more expensive.

Page 16: Metamorphosis from Forms to Java:  a technical lead's perspective

Learning• Psychology of learning:

– Don’t get too down if you do not “get it.”– Don’t get jealous (unless you find that motivating):

• others may learn some things before you• try to accept the challenge to learn from them, without

beating yourself up too much.

• Other ideas:– Approach technical problems by consulting lots of

sources, if possible, to get different points of view.– Technical guides, manuals, and versions of software

must be used quickly before they get antiquated.

Page 17: Metamorphosis from Forms to Java:  a technical lead's perspective

Learning

• Hire one or more Java experts, and they can help train your Forms people.

– They should be…• Self-motivated.• OK with

– teaching and being around learning people– changing technology.– build a pilot, take it to management, and cajole them into

walking their talk.• Able to leap tall buildings…

Page 18: Metamorphosis from Forms to Java:  a technical lead's perspective

Learning

• JDeveloper Concepts:– There are many details to learn

• what are all the pieces? • How do they fit together?

– What can you drag to where in the IDE?– Highly customizable. In doc it says you can fix their

bugs if you are impatient through extensions. • How do you override and extend Java code in this

framework?• How hard is it to extend a framework vs waiting for future

versions?

Page 19: Metamorphosis from Forms to Java:  a technical lead's perspective

Experimenting

• If you have an pilot/assignment to do you could…– Do something you need to do anyway, only in the new

technology (and old technology in parallel?).– Do a POST-MORTEM on the old way of doing things.

• Get together with everybody (users, programmers, et al) agree what you did/did not like.

• Do some story boards or your favorite requirements-gathering method

– Train your users on what is possible with the new technology so they can think outside their current “box”.

Page 20: Metamorphosis from Forms to Java:  a technical lead's perspective

Technical Highlights

Page 21: Metamorphosis from Forms to Java:  a technical lead's perspective

Issues and Highlights• What follows are more technical issue and highlights of ADF and

JDeveloper features.• Main resources I used were

– Oracle Application Development Framework Developer’s Guide for Forms/4GL Developers

– Oracle JDeveloper 10g for Forms & PL/SQL Developers: A Guide to Web Development with Oracle ADF

– Dive Into ADF Blog, AMIS website, Frank Nimphius…• These two books cover this material in great detail. I can fill in the

blanks offline or these books will help. I recommend them both highly.

• JDeveloper allows access to many technology stacks; – I only cover one here. – These two books also cover this same stack I am covering. (ADF BC,

JSF)

Page 22: Metamorphosis from Forms to Java:  a technical lead's perspective

First Subject: Deployment

• OC4J: learn about it; work with it. Great container! Fully functional. Gives you deployment practice…

• OC4J will only take you so far. Need to deploy to real test bed to feel confident and remain motivated.

• May need to get some more hardware (used is OK); deploying to existing servers can be too scary at first to inexperienced system administrators.

• Might consider virtual machine software (like VMWare or Xen)

• The paper which accompanies this presentation has instructions if you want to set up 10.1.3 OAS on a Red Hat install. This is pretty easy.

Page 23: Metamorphosis from Forms to Java:  a technical lead's perspective

Deployment• If you are deploying to OC4J or

OAS you can deploy several ways:

– Developers using JDeveloper can create an application connection to deploy easily.

– Other deployment methods require an EAR file or something like it. To make an EAR file…

• create a WAR deployment profile in JDev (use New…on context menu for ViewController Resource Folder).

• In deployment profile context menu deploy to an EAR file.

– With an EAR file you can use…• Oracle Enterprise Manager to

deploy from anywhere.• admin.jar to deploy from the

server side.

Page 24: Metamorphosis from Forms to Java:  a technical lead's perspective

Deployment

• Cautions:– OAS 9.0.4, 10.1.2 and 10.1.3 have different

deployment requirements partially because they run different versions of the JDK; so your deployment target matters when attempting a deployment.

– JDeveloper help has deployment instructions, which are somewhat helpful and somewhat erroneous depending on what version you are deploying to (see paper).

– Save time: follow the Oracle compatibility matrix.

Page 25: Metamorphosis from Forms to Java:  a technical lead's perspective

MVC (Model-view-controller)

• In a web program – the “view” is what you see and interact with. – the “model” is the data and the data access.– changing one can affect the other.

• MVC promotes having an intermediate layer called the “controller” layer to allow changes to view or model without affecting the other.

Page 26: Metamorphosis from Forms to Java:  a technical lead's perspective

MVC: the Model side

• ADF BC is what I have worked with on the model side. (I do not know TopLink, etc.)

• Generally you need an Entity pointing to a database table if you want to update/insert/delete that table’s data.

• A View Object needed when you want to select.• Entities and View Objects can be linked together, like with tables

and their PK/FK’s, with Associations and Link Objects.• All these objects fit into Application Module objects (hence: the icon

for application module is a suitcase.) • Application modules should contain the data controls that represent

a Use Case or a “unit of work” (building blocks)

Page 27: Metamorphosis from Forms to Java:  a technical lead's perspective

MVC: Model

• Drag and drop on Business Component diagrams – may help visual-learners.

• Entities/associations often come from tables/referential constraints. – Can drag

• entities into views to make a query/view based on a table/entity.

• views/view links into application modules to make instances of these objects.

• application modules into other application modules

• View Object control hints will allow you to more easily deploy your application to different locales (countries) with very few configuration changes.

Page 28: Metamorphosis from Forms to Java:  a technical lead's perspective

MVC: View/Controller• Thoughts:

– Not sure why View and Controller are bundled separate from model. All three are of equal importance and interrelated.

– Controller: JSF favored by Oracle over Struts because of

• wide acceptance and government by JCP (Java Community Process).

• Also JSF reacts at the component level, where Struts reacts at the page level.

• SUN may like Struts better

– Faces-config.xml tracks • navigation rules

– nice diagramming tool for this– Names: navigation modeler, navigation

diagrammer, and page-flow diagrammer (?)

• what beans/properties your application has

• lots of other stuff

Page 29: Metamorphosis from Forms to Java:  a technical lead's perspective

Inter-page data passing

• Can use parameters for passing information.• Other data can be stored in session or process-level

beans (more about them in a minute…).• Like passing data: If you use the same iterator crossing

pages you will not lose the current-row marker setting.

Page 30: Metamorphosis from Forms to Java:  a technical lead's perspective

Visual Designer

Page 31: Metamorphosis from Forms to Java:  a technical lead's perspective

Visual Designer• Double-click a web page icon on

the Navigation Diagrammer to edit a page with the Visual Designer editor.

• Can drag individual GUI components or data-based data-control components and operations onto the page or structure pane.

• Can drag-and-drop, or select and click (for components).

Page 32: Metamorphosis from Forms to Java:  a technical lead's perspective

Bindings• Can mean different things

depending on context (bind variables, data bindings)

• Very important to understand how to manually create and edit bindings (Koletzke).

• Bindings connect things: – GUI components to iterators,– GUI components to data elements,– GUI components to actions and

methods

• Right-click on your visual designer page and choose the Page Definition file to see your page’s bindings so far.

Page 33: Metamorphosis from Forms to Java:  a technical lead's perspective

Bindings

• Another way to see bindings: in the visual designer you can click on and then right-click in a data field and choose Edit Bindings to open up the Attribute binding editor.

• To make your page to use custom model code you write you will need to do the following:– Commonly you would create or override a Java method in your

extended application module file.– Expose this method on the Client Interface Node of the App

Module editor. (Double-click the application module to enter this editor.)

– Insert a method binding into the page definition file structure pane.

– Now you can call your code from a button or an invokeAction executable.

Page 34: Metamorphosis from Forms to Java:  a technical lead's perspective

New Subject: Beans

• What are beans? – reusable Java programs

• According to wikipedia.com, the required conventions of JavaBeans are…– The class should be serializable (able to persistently

save and restore its state) – no-argument constructor – have get/set “accessors” for each class attribute – It should contain any required event-handling

methods

Page 35: Metamorphosis from Forms to Java:  a technical lead's perspective

Beans

• Where are beans found in ADF?• There appears to be both View-layer and

Model-layer beans in ADF apps.– GUI/Presentation layer validation– Storing inter-page persistent data.

Page 36: Metamorphosis from Forms to Java:  a technical lead's perspective

Beans

• Model versus View beans– Model layer

• Model-level Java programs accessible within the Sources folder in the structure pane when the BC component is highlighted in the Application Navigator;

• java settings for this component must have java code option turned on.

• JDev documentation does not refer to these programs as beans.– View layer

• You can create/manage (View layer) managed beans through your configuration editor (faces-config.xml overview tab).

• Binding layer calls these beans.• It is possible to interact and manipulate binding through bean code.

(Koletzke: this is a really good thing to learn how to do.)

Page 37: Metamorphosis from Forms to Java:  a technical lead's perspective

Beans

• Helpful facts about beans:– You can bind an input field on a page directly to a bean attribute.

Use the EL format “<beanname>.<attribute>” to reference it. (Note: “<scope>.<beanname>.<attribute>” may cause an error.)

– You can opt to have JDev automatically maintain backing beans so when you add a new attribute to a page the backing bean gets a corresponding attribute added. (You can also double-click on a GUI component and create a bean from there.)

– Can change name (id) property of your fields and beans by altering the id in your property sheet. This editing method allows you to have better names for your fields to references in your custom code later.

Page 38: Metamorphosis from Forms to Java:  a technical lead's perspective

Scope

• like “automatic” beans…(not aeromatic).• Request, Process, Session, Application Scope “beans”

are created dynamically. • Inter-page data storage

– SetActionListener component is dropped onto a button, and sets a value prior to executing the action associated with the button.

– I told the SetActionListener to do a (from, to) of (#{row}, #{processScope.detailContacts}). Then I made the target page reference #{processScope.detailContacts.Pid} as its value.

– The result was values were passed from page to page painlessly.

– Request or other scope works just as well for inter-page value passing.

Page 39: Metamorphosis from Forms to Java:  a technical lead's perspective

GUI Components

• There are Model- and View-layer components.– Model

• View Objects, • Application Modules, • Entities

– View- or Presentation-layer (GUI) components• what you see (or not) on a web page like a

– button, – field, – drop-down list

• JSF and ADF Faces have many View-layer components to choose from.

Page 40: Metamorphosis from Forms to Java:  a technical lead's perspective

GUIComponents

• Form – vertical field layout• Table – horizontal, multi-row layout• Tree

– Tree binding editor– What data elements do you want to see on each level?– Link current rule to next (branch rule accessors)

• Adf Faces switcher and JSF facets – conditionally showing parts of your web page.

• Drop Collection-level action “executeWithParams” to get ADF Parameter Form

• So many more…

Page 41: Metamorphosis from Forms to Java:  a technical lead's perspective

Collection vs. Iterator• Initially it was difficult for me to understand

what a collection was and what an iterator was.

• Model has Application Modules and View Object instances inside of it. ViewController has DataControl with Collections inside of it. I think they are two ways of looking at the nearly the same things respectively.

• Iterators are like cursor pointers in pl/sql; they point at a particular row in a returned set of data rows (a collection…which is a rowset inside a view object instance).

Page 42: Metamorphosis from Forms to Java:  a technical lead's perspective

Oddballs and Whiney-bits

• While learning and experimenting I ran into things that threw me for a loop.

• The following section will help you be prepared for these same stumbling blocks, hopefully.

• Many other gotchas are highlighted in the ADF Developer’s Guide.

• New versions of JDev will makes these disappear and others appear, no doubt.

Page 43: Metamorphosis from Forms to Java:  a technical lead's perspective

Odd-balls…

• If you move your JDev home…– any applications that you have run against JDev’s

embedded OC4J server has imiplicitly been deployed there, and would need to be un-deployed and redeployed to make this move successful.

– No EM on this server instance so you would probably need to use admin.jar to do this.

– It is probably easier to just reinstall JDev to the new location and open your application in the new JDev.

Page 44: Metamorphosis from Forms to Java:  a technical lead's perspective

Oddballs…

• Your pages, iterators and fields on your page can be granted access to roles through Authorization Editor.

• Authorization Editor hard to find. – open the page definition for the page in question. – click on the page definition page, – go to the structure window– right click on the Page Def (root) node in that structure window. – select the option to “Edit Authorization”

• Other security settings occur in web.xml and in the embedded OC4J settings. Also jazn.xml

Page 45: Metamorphosis from Forms to Java:  a technical lead's perspective

Oddballs…• Entity Definitions are to Entities as View Objects

are to ViewRow Objects. Why not View Def/View Row, or Entity Object/EntityRow?

• Creating custom properties in AppModules, View Objects or Entities is possible…but is annoying.

• If you normally set proxy exceptions in your intranet may need to set Embedded OC4J Server Preferences Startup to use localhost instead of your machine name.

• Deleting and re-adding things to Data Model diagrams can create really long link lines.

Page 46: Metamorphosis from Forms to Java:  a technical lead's perspective

Oddballs…• Make view objects that are

based on multiple entities able to update all its entities with the click of a checkbox (might need some additional programming, too).

• ADF manual for Forms/4GL Developers, Chapter 9 has some typos and omissions that are handy to know about – see the paper.

• If computer is forcibly rebooted while you have changes to save it can mess up your JDev installation; so can certain mistaken uses of JDev functionality. (need reinstall)

Page 47: Metamorphosis from Forms to Java:  a technical lead's perspective

Oddballs…

• On a Form component, if you use bindings EL expression to keep a record counter against an iterator (to create “page 3 of 10” and the like) and the iterator’s RangeStart expression does not seem to be advancing, …– make sure that the page definition file’s setting of

RangeSize is set to the number of rows displayed on the screen (i.e., 1 for a Form).

– The default for this attribute for iterators is 10. – It should instead match the number of records you

are displaying on that page (1 for a form component).

Page 48: Metamorphosis from Forms to Java:  a technical lead's perspective

Oddballs…

• The ADF Developer’s Guide says Table components will not allow you to bind a database table to a list element within it. – But I tried it, and it worked fine.

• Watch out for java.lang.Number versus oracle.jbo.domain.Number ; datatype mismatch errors involving numbers are probably caused by these.

Page 49: Metamorphosis from Forms to Java:  a technical lead's perspective

A Word about JHeadstart

• Good productivity tool• Consistant UI• Costs extra• JHeadstart authors not so emphatic about 100%

generation as in Headstart product.• Will factor in Designer repository modules.• You would have to learn yet another

“declarative” layer though…• May help Designer users migrate to ADF

Page 50: Metamorphosis from Forms to Java:  a technical lead's perspective

Some Tips…

• I have a few things left to say which will help someone out there…

• Then we are done.

Page 51: Metamorphosis from Forms to Java:  a technical lead's perspective

Tips

• Good things to remember about ADF…– As you are building your page, drag items from the Data Control

palette rather than the Component Palette when possible.– Learn names of different components, editors, panes/panels,

etc. This will help in reading documentation.– Refactoring: a year ago refactoring was not safe. Now it is. Go

for it. Only a few thing need doing manually (e.g., change DataBinding.cpx if you change the name of a page).

Page 52: Metamorphosis from Forms to Java:  a technical lead's perspective

Tips

• Your application module has a “main” method in it if you need to run your model in debug mode. It works great!

• If you publish your custom method in the client interface you may need to rebuild your client interface code so that “code insight” in your code editors shows your new code changes.

• SRDemo great to study. Oracle ADF Guide for Forms/4GL Developer’s works with this app in code examples.

Page 53: Metamorphosis from Forms to Java:  a technical lead's perspective

Final Tips…

• The application module’s constructor does not represent the start of the life of the application module. Instead, override “create” method if you want to do something which coincides with the beginning of the App Module’s life.

• Try to create your Framework Extension Layer as soon as you can stomach it– check out chapter 25.1 through 25.3 in Developer’s

Guide to do so. – This will give you flexibility in the long run.

Page 54: Metamorphosis from Forms to Java:  a technical lead's perspective

Enjoy Training Days!

• Hope you enjoyed this presentation.

• Any questions?

• Contact me at [email protected]