Metamorphosis from Forms to Java: a tech lead's perspective (paper)


Published on

JSF Paper I did for RMOUG training days conferenece 2007

Published in: Technology
1 Comment
1 Like
  • The presentation is good. Thanks
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Metamorphosis from Forms to Java: a tech lead's perspective (paper)

  1. 1. METAMORPHOSIS FROM FORMS TO JAVA: A TECHNICAL LEAD'S PERSPECTIVE Michael A. Fons, Rohmann Joint Venture/Graebel Many thanks to RMOUG and the tireless volunteers that make it continue to happen year after year… Introduction My hope in producing this paper and the corresponding presentation was to help somebody who was going through what I was (and still am) going through. As Oracle has attempted to distance itself from “old school” client-server-esque tools such as Oracle Forms, Oracle Reports and perhaps even PL/SQL, guys like me and companies that invested in these old-school technologies have to come to grips with reality: we are just going to have to move on. For many this means learning Java, Portal, JDeveloper, JHeadstart, BPEL, or whatever else is appropriate. I figured that as I go through my “personal” transition of this nature and as I work for companies that are also going through it I would simply try to record things that I thought would be helpful to anybody else transitioning in the same way. So here is the paper. I hope it helps you. Reasons for transition Technology issues A company must look at many issues related to technology and technologists when considering what technology to use. Is Oracle planning on de-support of Forms and Reports? Not at this point, as Oracle announced a few months ago, according to Peter Koletzke. I feel though that some day it is probably that Oracle will officially turn its nose up at Forms and maybe Reports, too. (Although Oracle Reports is a stellar performer on the web, Oracle has other ideas, judging from a demo I saw, to replace Oracle Reports with other tools involving using MS Word. How ironic.) On the people side experts, in old technology harder to find for reasonable fee…or at all. Technologists must worry about becoming obsolescent the same way that so many professionals must stay current with whatever their field might come up with. As people learn new things they naturally want to use them in their daily lives to re-enforce the concepts in their mind or because the idea seems particularly apropos to whatever they are working on at the moment. There are some people, however, that do not march to this drummer. Instead they cling to past technologies and spend all their professional efforts supporting old technologies. The companies using the old technologies are grateful, but fear or whatever eventually routes out these folks until somehow there is a lagging minority left supporting the old tools. They must live in a Winnebago and drive from place to place to survive (that is how my nightmare goes anyway). Most companies do not want to get involved in this sort of non-sense so: they move on technologically, too. For their own nightmare-ish reasons, good people may leave a company if they cannot stay marketable; these people may look at where different markets are going; some industry experts agreed in a recent conversation, for instance, that industry RMOUG Training Days 2007
  2. 2. Metamorphosis from Forms to Java … Fons and Oracle shops are going toward Java lately to be sure, although not always to ADF, but some other configuration – perhaps still using JDeveloper though. As technology progresses there will be companies formed all along the business cycle to support these transitions. For example there are third-party vendors which can create J2EE/EE5 applications from Forms web applications. Customer dissatisfaction with current products Why wouldn’t someone love Oracle Forms applications? You can build anything using Forms, so what’s the problem? • Forms by default leans a developer toward the use of enter query mode because it is easy to implement – but some end users find this concept non-intuitive. Those users often prefer entering some search criterion and then pressing Find. • Some think there are some pieces missing from Forms GUI palette. While it is possible to implement just about any widget in Form it is not necessarily “easy” to do so always. • Forms is based on a set of complex trigger interaction which can be difficult to predict and troubleshoot. Triggers and fixes affect other functionality, and fixes you might expect to be intuitive and simple require special knowledge to implement. • Without adequate automation, keeping JInitiator and certificates up to date can be a pain for the user, especially for internet apps – causing users to loath use of the system at hand. So often we find companies, end-users, and developers clamoring for change in this arena. Promises start to surface related to new technologies which will solve any or all of these issues. General managerial ideas It is very easy to want to convert to another technology. Getting managerial buy-in is a different matter altogether. If decision to go to Java (or something) is still being made the GM would usually ask… • If the old technology works why fix it? • We have got too much else to do; why bother? It will just put us even further behind schedule. • Or how about, quot;Is this just another 'cool technology' or Oracle sales gimmick?” But presuming you already have buy-in they will ask questions like… • how do we get our people trained and keep up with current work? • how steep is the learning curve? • how fast can we be productive again? Consider the following in trying to answer these questions. In order to keep up with current work some decisions must be made regarding what approach you will take to converting the forms and reports. You may want to consider what your current work-load is like. Also, do you have programmers that can learn by doing? If you have buy-in from the top one approach is to focus on the soon-to-be-legacy forms/reports system for a year. For that year focus on stabilizing the application and accept no new development. For any new development or major business rule changes try like the dickens to get it put off for a year. After that year do no more non-emergency work on the old system. Do all work on the new system using all your programmer resources. So the users are using the legacy and any change requests they have are being implemented as part of the new system. Then the new system goes on line when it is thoroughly tested and bug free (ha ha ha). This wholesale approach was used by the Naval Academy not too long ago on a major computer system it has. Another approach is to convert piece meal at first. First do some pilot project which converts some part of the system. Perhaps you will have co-existent forms and java code. As your developers come on-line better and better and your new software development infrastructure comes on-line you will be able to manipulate larger and larger portions of your system to fit the new paradigms. If your system is divided into organization specific applications you can eventually work on converting an application at a time. This is the approach our organization is taking. RMOUG Training Days 2007
  3. 3. Metamorphosis from Forms to Java … Fons With these two approaches the answer to the “how quickly will my people be productive again” is slightly different. With the wholesale approach you end up being super-productive for a year then not productive at all on the legacy system and super-productive on the new system. But it is all sort of theoretical productivity until you do the massive cut-over. That is somewhat risky. With the piece-meal approach the IT department is continuously productive but slightly less attentive possibly to the end- users needs since they are also trying to factor in technology learning and pilot projects on top of that. But at least these people get to doing something that someone will truly use faster than the wholesale approach… Either way, do something! This will get you started and combat feeling overwhelmed during the conversion process. Here are some books I have used for research for this paper which I would encourage you to look at (note that some of these books are meant to be read page by page and some are to be used as reference manuals): • Oracle ADF developers Guide for forms and PL/SQL developers: B25947_01, or other such books from the Oracle Technet ADF homepage. • Oracle Containers for J2EE: Configuration and Administration Guide, 10g Release 2 (10.1.3) – Part number: B14432-01 (Note: OC4J is a good lightweight container which is worthy of your study as you go forward in your conversion process.) • From NetLibrary site: Enterprise JavaBeans Java Series (Sebastopol, Calif.) Author: , Monson-Haefel, Richard. Publication: , Sebastopol, CA O'Reilly and Associates, 1999. eBook ISBN: , 1565929519 • Oracle JDeveloper 10g for Forms & PL/SQL Developers, by Peter Koletzke and Duncan Mills, McGraw Hill, 2006. ISBN-13: 978-0-07-225960-5 • Oracle JDeveloper 10g Handbook, by Dr. Avrom Roy-Faderman, Peter Koletzke, and Dr. Paul Dorsey, McGraw Hill, 2004, isbn: 0-07-225583-8 • -- this is Installing Oracle Application Server 10g Release 3 on Linux x86 • JDev help is good too; for example for help on skins and templates enter “skins” on a help search and find the topic of “working with skins in ADF faces”. • OTN is always good; for example, look in the JSF section of the page to see details on the ADF faces tags available. • You can find out about JSF EL and many other topics on • Whatever else you can find… Do demos, join list servers, buy/borrow books, Google code, work with other developers, attend conferences like RMOUG, train other people in your group less knowledgeable than you on the subject (to help them and reinforce concepts for you as well). If possible, interleave working with JDeveloper/ADF/JSF with actually reading and learning about it. I think you need both sides to actually continue learning and stay interested and not get depressed or bored. Try not to let yourself get too down about what you do or don’t know along the way. Remember that you are learning and that can be hard. If someone learns something before you try to see that as an opportunity to learn from them and not an indication that you are dumb. ALLOW YOURSELF AND YOUR TEAM ENOUGH TIME FOR THE LEARNING CURVE DURING THIS PROCESS especially the more advanced topics. Later chapters to most manuals are really impenetrable, especially if you just skip to them without proper background. Probably you will need enough time to work into the advanced concepts chapters and learn the background first. Here are a couple more thoughts on learning tools: Try to get versions and self-help books that are very recent and then dive in before they become antiquated. Also, if you are ever confused on a topic search multiple sources on the same topic until you get enough perspectives to be able to operate. If you don’t know Java, try to learn it somewhat before you work with Oracle’s ADF developer’s Guide for forms and PL/SQL developers. This book expects that you know somewhat what is going on with the java language. If you do not do RMOUG Training Days 2007
  4. 4. Metamorphosis from Forms to Java … Fons this you may get lost or confused. There is a fair amount of java for a book that is supposed to be geared toward forms and PL/SQL developers; and yet the book is usually stepwise and complete in its approach to the subject of learning to code in the ADF. The reason for the amount of Java in this book is that the ADF is really great; but compared to some other frameworks, ADF has not been around that long; so there are still some things that really need automating. Eventually the ADF developers will get around to fixing these things, but they just have not yet because there are only so many hours in a day…which means that you will need to go in and fix things up your self if you cannot wait…which means they need to spend more time about extending the default classes that are a part of ADF. Additionally the following things may be confusing that they mention in this developer’s Guide: when you create java code you create classes. When classes are running they are called objects. When these objects are “instantiated” they are called instances (c.f., “new” keyword in java). In this manual instances are sometimes referred to as objects and so are classes. It is just important to be aware of this distinction to avoid too much confusion. The way they refer to java interfaces in ADF is perhaps confusing for someone just learning Java. Interfaces are a construct in java that contains no code. And yet they have a practice of at time talking about them as if they are interchangeable. Be careful you at least know what an interface is and what it is generally used for. Training Courses I checked out what training for our group might cost for ADF and Java. The two companies that I checked out had costs that were comparable. There were many things that went into pricing for these two companies, and many ways they would allow you to cut corners depending on how much you had to spend. For example one company offered that if we could put them up in the houses our management (since they would be flying in) that they would not charge for room. For another example, if your organization is with the government, they may give you GSA rates. If they offer GSA rates to the government, however, they probably will not be able to go lower than these rates even if you are not with the government or they may end up owing the government money. It looked as though in the two places I checked out that a group of 10 people could be trained in Java and JDeveloper for around $1,000 per day. The entire package a training group offers may include travel expenses and incidentals (or not). It may also include mentoring packages to help you follow up your training. New Blood Bring people into organization that have experience and enthusiasm for helping you get where you want to be. These people should be… • Self-motivated • Comfortable with Changing Technology • People who can build a pilot, then take it to management and convince them to go all the way with that. • People who are capable and really willing to share their knowledge with those who are truly interested in learning and willing to put in the time to learn. Pilot Projects Create pilot projects in the new technology as soon as possible in parallel with your current technology for something you already need done and have to do anyway. This will take lots of work. Here are a couple of approaches to doing pilot projects: • Redo things exactly as they are now only in the new technology. • Redo things to be different – in order to do this you will need a post-mortem on the methodology of the current system: what worked and what did not. For example Oracle Designer’s Forms generator likes generating forms such that they map one-to-one with to tables; but user processes do not always map to tables. So instead of making a form table-driven, could you not develop an application that follows the contours of the user’s processes and aids in their completion? Surely those two contours are not the same. Planning your architecture Here are some ideas and questions which may help you get started planning your architecture in the new paradigms: RMOUG Training Days 2007
  5. 5. Metamorphosis from Forms to Java … Fons • Talk to the users: what do they want changed; someone will need to educate them on what is possible, otherwise they will suggest improvements on what is currently in existence and customary for them. Do a post-mortem with them: what is it about the current system that interferes with the way they do business now? • Where are you going to put the business logic? If you have lots of triggers and tapi and capi and vapi and mapi what are you going to do with it all? You may have millions of dollars invested in your PL/SQL – business logic. And yet you may be missing out if you do not follow the standard idea of putting the business logic in java. And if you choose to migrate your business logic from triggers to Java, will you have to maintain both layers until all your trigger logic is replaced by Java business layer? • ADF BC View Objects – who is going to create standard entities and views? Are they going to base them on what views exist currently? Are they going to analyze the business processes? Are they going to be big so that lots of people can use them? What about deciding what parameters to tie into their where clauses? • CM environment – what are you going to store? What tool will you use? For example will you store all your entity objects in Subversion so that all developers can use the same entities for all their projects? • Testing – are you going to use JUnit? Are you going to test by some other means? • Modeling – are you going to go back in to your models and redo them using use cases or some business process- oriented modeling? • Planning -- whatever you do, write it down so the “next guy” can stand on your shoulders and not be left hanging. • Programming/GUI standards – what components will be available to every programmer? What pictures will you use? What sort of navigation paradigms? What style-sheets or skins? What will the standard resolution(s) be? What sorts of fonts will be used? Deployment issues and Server Planning You need a place to deploy. It is very de-motivating and unrealistic to have motivated developers deploy to their own computer for too long. It seemed like trying to get a place to deploy touched on everybody and made them aware that they did not have enough money, time, servers, memory, whatever to allocate. Also there was risk involved if any servers needed sharing. Even if you want to go the virtual machine route, you need to pay for the software or at least consider the non-free versions to see what they have to offer. That said, you are going to want to deploy somewhere. Here are some hints about how you might go about it. To standalone OC4J You can download an OC4J or you can use the standalone OC4J that comes with any JDeveloper installation of late. There are instructions in JDev help on how to deploy and where the standalone OC4J is located in the JDeveloper home. Here are the basics of deployment for this lightweight deployment target: You will not need to download the ADFinstaller I do not think. I think this would mostly be used in deploying to odd servers that did not already have the right set of libraries to support the application you are deploying. If you did need it you would use the command “java -jar runinstaller.jar” (At the outset you do not need to worry about deployment descriptor alterations from the default settings.) Highlight your ViewController project, right-click, and select new->general->deployment profile on the right-click context menu. Use the option to create a war file (not an ear file). Specify the app name, and accept other defaults; you may want to change the context root to something shorter in length. Once this profile is created, right-click on this new descriptor; deploy to an ear file. It is also possible to create a connection to your target application server that would allow you to deploy directly there without creating this ear file. But it would probably be more portable and more instructive to you if you just used the ear file to deploy up front. On oc4j admin deploy the ear file using two commands in succession (or do the same things with Oracle Enterprise Manager that comes with the standalone OC4J): java -jar $J2EE_HOME/admin.jar ormi://localhost oc4jadmin admin -deploy -file ./lib/myapp.ear -deploymentName myapp java -jar $J2EE_HOME/admin.jar ormi://localhost oc4jadmin admin -bindWebApp myapp myapp-web default-web-site /myapp RMOUG Training Days 2007
  6. 6. Metamorphosis from Forms to Java … Fons In fact when you use the Oracle Enterprise Manager to deploy ear files the enterprise manager uses these admin.jar commands in the background to get its work done. This is evidenced by the output log of the enterprise manager, which produces the same deployment output as using these admin.jar programs, and running the process manually. During the deployment process I observed once that sometimes the deployment does not appear to work and you just need to redeploy...then the app works. I may have done something wrong, but perhaps this is just a delicate process. Heads up to you, dear reader, in any case. If all this talk of ear files makes you nervous you can also create an Application Connection to your machine or whosever machine the oc4j instance is on and deploy to that. JDev will do it all for you and you can just study JDev’s output log if you are curious what happened. To OAS 10.1.3. (10gAS, release 2) I fresh installed OAS 10.1.3 in order to do some actual testing. Our normal web server was still at OAS 10g release 1 (9.0.x.x??). The install went well. I had a sysadmin who had time to get Linux installed for me. I then downloaded the .cpio file which is used for installing OAS 10.1.3. To install this file I just followed the instructions on which work quite well...except that the list of os patches needed were not 100% correct. (use the list that the oracle installer gives you) Initially it alerted me I needed to install some additional OS packages, but my sys admin took care of that for me on the Red Hat site. These instructions reference Red Hat release 4. We were still on 3 so the packages they had listed for 4 did not fit what we were doing. After that the install went very well. I had an ADF app that I was playing with. So I did the deployment manually in case there were restrictions in how we did deployments and were not allowed to use JDeveloper’s deployment-made-easy features. It deployed fine but I thought I could test through Enterprise Manager. You can test through enterprise manager, but enterprise manager application test button did not know anything other than the context root. After the context root you still need “…/faces/yourfrontpage.jspx” Because I forgot that it needed “faces” in there I thought I needed to install the libraries with the ADFinstaller program. So I wasted a lot of effort, and recorded my mistaken efforts in Appendix A of this paper in case anybody really ever *does* need to use the ADFinstaller program on Linux. (That program worked great, by the way) Potential issues deploying to different AS server versions My general advice is to use 10.1.3 AS and JDeveloper versions or later for deployment. I am not too versed in the details of doing otherwise. I know it is possible to generate a 10.1.2 AS compatible version of a JDev application using JDev 10.1.3, because some of the people here are doing that; I just do not know how at the time of this publication. Also I have notes that I took from one of our gurus; here are my notes (I may have gotten some things wrong here): JDev 10.1.3 uses JVM 1.5 by default. Deploying such an application could be a problem deploying to 9ias which does not use this JVM. Also, apparently 10.1.2 and 10.1.3 versions of the OAS require different XML files for the ears you create. Since 10.1.2 of JDev and oas seem to use JVM 1.4 and J2EE 1.3 standard and 10.1.3 JDev and oas use EE 5.0 that means a lot of the XML files in the ear files have a different standard format as per the standards for J2EE 1.3 and EE 5.0. So there are differences in the way the deployment descriptors need to be adjusted for these different kinds of deployment. You might want to set up a sandbox machine or VM software if you need to do a lot of experimenting with different kinds of deployment sources and destinations. For proof of some more difficulties you might run into with versions prior to 10.1.3 of the AS and JDeveloper, here is an email showing some research that a friend of mine discovered after much blood sweat and tears; I do trust the contents of this email for your use and abuse since I was somewhat involved while my friend was working out the details: Peter, We discussed this briefly last Wednesday, but I wanted to document it... I was successful in getting my JDev 10.1.2 EDL prototype running on the OAS install on Camis04. I did need the ADF libraries and have included a list of the jar files installed. JDeveloper has a help document that gives instructions for adding the ADF libs, but I found out the hard way that it's inaccurate. Metalink recommends using JDeveloper to install the libraries by using the Tools->ADF Runtime Installer. This requires that JDev be installed on the same machine that OAS is installed (or samba mounting the ORACLE_HOME dir remotely). I installed JDev and ran the utility. It RMOUG Training Days 2007
  7. 7. Metamorphosis from Forms to Java … Fons installs the 10.1.2 version jars and, where necessary, archives existing older version jars to a directory under ORACLE_HOME (BC4JAR. which can then be used (via JDev) to restore the original jars if necessary. Real slick as long as you use JDeveloper. I did have to add two additional jar files which the server complained about when I tried to run my specific application: ./BC4J/jlib/bc4jdatum.jar ./ord/jlib/ordim11.jar I also added the following lines to the /opt/oracle/J2EE_904/J2EE/home/config/application.xml file to support those files: <library path=quot;../../../BC4J/jlibquot;/> <library path=quot;../../../ord/jlib/ordim11.jarquot;/> After deploying the JSP version of the app, I was able to deploy and run the UIX version and that one is out there now. I will change the link on the DF web page <> to point to the installation on <somecomputername>. I also have a link to the EM console from that page. The password is quot;xxxxxquot;. Thanks for the help with this. I will continue to develop and test on Camis04. I will also set up a meeting with Don V about JDev/OAS versions, authentication, deployment, etc. per our discussion with Scott of last Tuesday. Dave Files needed to run 10.1.2 JDev apps on OAS ./BC4J/lib/collections.jar ./BC4J/lib/bc4jdomorcl.jar ./BC4J/lib/adfm.jar ./BC4J/lib/adfmweb.jar ./BC4J/lib/bc4jimdomains.jar ./BC4J/lib/bc4jmt.jar ./BC4J/lib/bc4jct.jar ./BC4J/lib/bc4jmtejb.jar ./BC4J/lib/bc4jctejb.jar ./BC4J/lib/adfmtl.jar ./BC4J/jlib/bc4jdomgnrc.jar ./BC4J/jlib/adfjclient.jar ./BC4J/jlib/bc4jdatum.jar* ./ord/jlib/ordim.jar ./ord/jlib/ordhttp.jar ./ord/jlib/ordim11.jar* ./jlib/ojmisc.jar ./jlib/jdev-cm.jar ./J2EE/home/applications/BC4J.ear (extracted to BC4J dir in the same applications dir) The technologies It is important to understand some of the differences between the technologies and environment that you are moving away from as it compares to that towards which you are moving: From: forms/reports/PL-SQL/designer Using forms/reports/designer/Headstart (some would argue) eliminates to need to do some up-front planning because many of the decisions have already been made for you. For example you can use forms to query things up a variety of ways, but if you just use form’s out of the box default behavior, or designer/Headstarts default behavior for generating forms you get quite a lot of functionality in a standard format. So if you were not too creative you could simply get things going and have standards automatically by using these tools in their default formats. RMOUG Training Days 2007
  8. 8. Metamorphosis from Forms to Java … Fons When converting forms modules in designer any .plls that you have created will need to be rewritten. Any application logic associated with tables that would normally go into the TAPI will need to be rewritten in business logic (BC or Toplink). Also any module level custom application PL/SQL code you wrote in modules will need to be converted to java. In conversion situations this transfer of these programmatic items represents a large amount of effort in a conversion process. In a forms conversion a single form can have many tabs. Given that the forms are web-based you do not want to put that much on a page. Maybe one parent-child relationship. So one form will sometimes map to many pages. To: JDeveloper/ADF/J2EE With this platform you have many more decisions to make. Much of what you learn is at a lower level. You have to spend more time learning how the pieces fit together. On the other hand if you learn smaller components you will not be as locked into a monolithic solution or IDE; you will simply know about the various components and be able to construct what you need no matter where you are or what you are doing. Developing – general concepts In the JDev IDE there is lots of drag-and-drop; but what do you drag where? The intuition for this comes from more intimate knowledge about how the applications are actually constructed – so keep studying the manuals and experimenting, and the familiarity will come; for example, it is probably best to drag a collection from the data control palette (if your application contains a model project) and then specify what kind of component you want to use from the context menu that pops up rather than to drag a component from the component palette, then try to hook it up with the right collection later on. (This is generally speaking; of course there will be exceptions to this rule. One advantage to dragging a data control is that your iterators are lined up and bound as a result of this drag-and-drop.) Another example of knowing what to drop where comes on a prompt you get with you drag and drop some ADF-faces components. JDev automatically warns you against putting the component into the page without a surrounding form component/element to go with it. It is hard to know when to follow this advice because the correct answer to that question depends on the component. For example there is a component (switcher?) that I ran across which must have a surrounding form or you will get a runtime error. On the other hand there is a menu item component that should nest in a menu bar component that should not have a form or the vertical separator bar between the menu items will not be there. So: same advice, two different correct answers. As you learn and proceed with experimenting and working through manuals do everything over and over until you are satisfied. If you do not understand something do not kid yourself; probably other concepts will be based upon that one you are not getting. Dig in and figure that thing out…whatever it is. Learn the names of the different editors so that you know what people are referring to in manuals. For example there is an editor for every type of model object, another for model project configuration, one for the web.XML file, another for security settings, and many others – each of which require a slightly different technique and bit of knowledge to know where to go, what to click, what pane to visit, what to right-click and so on. The quicker you learn these the sooner you can focus on what the manuals are trying to tell you what to do. One concept which is very appropriate is that of the MVC: Model-View-Controller. If you do not already know what this means or where this concept came from, then you would do well to learn. Basically the Model is the Database or Data side of a program that is using this structure. The View is the part you see, or the GUI part. The Controller is the part that helps the user get from one part of an application to another. It is more complex than all this, but this basic definition may help you get off the ground until you find a more complete definition. What follows are some basic concepts and some highlights about the model layer and the view/controller layers that may help you in dealing with these different parts of the ADF in JDeveloper. MODEL: Like setting up triggers and database-level business logic the Oracle developers Guide spends the first 9 chapters talking exclusively about the Model part of the programs that they would have you build using ADF. So it is important. It is foundational…literally. Especially since you probably have an Oracle background. I imagine it is intuitive to expect that an Oracle developer thinks of the Database as foundational to their database application…same goes for the Model part of an ADF application. RMOUG Training Days 2007
  9. 9. Metamorphosis from Forms to Java … Fons In JDeveloper/ADF the model side is made up of entities, views, and application modules. These three items are concepts, but also they all are classes; so here goes another quick definition of these model parts: entities are like tables (table rows, actually). If you have done ERD’s before in a little depth this should not be a foreign concept to you. Views are like queries against the tables. Application modules are like, uh, something that bundles all the entities and views together so you can move it around as a lump. (Entities are really only needed if you plan on doing updates, inserts or deletes against your tables. If you are entities make these basic operations much simpler than they would be without them.) If you like thinking about things in layers you can think of first databases on the bottom, then entities on top of the databases, then views on top of entities, then application modules which collects instances of view and entity objects. The application module class is a good place to do custom coding in many cases. For example, if there is any code that you want to do every time a new person starts a session on an application if would be best if you overrode a method called prepareSession inside of ApplicationModuleImpl class (your custom version that is.) Here is how you would add such an overridden method to your custom version of the application module class: In the Java node of the application module editor you need to indicate that you want a java class generated to allow you to inherit and modify the functionality of an application module. In order to override the prepareSession function you need to edit the java file that is generated when you turn java customization on for your application module. This java file will have the same name as your application module but will add “Impl” to the end of the name. Edit this java file. In the code editor for this file go into the Sources menu in the JDeveloper main menu. Under this there is an Override Methods… menu sub-option. Click on this. You will see a list of methods in the ApplicationModuleImpl class that you can override. There are two prepareSession methods in this list. Choose the top one (the one with the key next to it…not the one with the lock). Click OK. This will add a basic function to your app modules custom java file. You can then add code to it to do things like change the where clauses of view object queries to limit what people can see based on their log in id. As I said earlier in the paper you need to think seriously about you company’s entity layer and view layer and plan how your model layer is going to improve reusability on an enterprise level. Since Entities generally map one-to-one with tables you do not have to do much thinking to reuse entities. However when you get into custom coding you need to make sure that your entity level business logic does not refer directly to view objects. There is a way (illustrated in the Oracle ADF developer’s Guide) to indirectly use view objects however that is just fine. It is also interesting to note that you can share view objects if you build them in a generic fashion. Also you can build Application modules so that they correspond to a unit of work for a user (a “use case”) so that you can reuse application modules also. It is possible to have instances of application modules inside of other application modules. For this reason in fact you will see references to the “root” application module, since these can be built hierarchically. View Objects (as Oracle calls them) can either be straight queries hitting the database, or they can be queries which hook into Entity objects which refer to tables. In the latter case there is something called the Entity cache which incurs some overhead; so if you are not planning on changing data you probably just need to use the views without the entities. Such views are called read-only. As I said just now Entity Objects actually represent a particular row in a table, not all the rows together. Entity definitions are another object that represents a collection of the rows for a table, and serves as a placeholder for any properties that are more appropriate to the table level than to the row level. It is possible to link entities and views together with other entities and views by using various kinds of connectors that map to primary key and foreign key references in the databases. If two entities are linked together with PK/FK relationships then you can define these connections. Sometimes changing these links to be just what you want is troublesome. For example views links are fairly simple to deal with when you use the default that maps views the same as the entities are linked. However if you then change your mind want to create a view which used two tables. This seemed to create some problems for the links involved. If you use the application module editor it is possible get these links straightened out to match what you are doing, but you have to know that if you want to add a child to a view object instance on the right side of the page then you must select the view object which is a child on the left hand side of the page in order to get the link to occur correctly on the right hand side. It is often useful as you create your model level components (views, entities, application modules) to put them in separate directories or folders (called “packages” in Java parlance). The documentation says that JDeveloper supports moving RMOUG Training Days 2007
  10. 10. Metamorphosis from Forms to Java … Fons packaged objects around into sub-packages fairly easily. I personally would recommend just putting your model-level objects in the right place to begin with rather than putting them somewhere then moving them later to some other place. I have seen refactoring become rather messy unless you know a whole lot about the way all the different XML and java and configuration files fit together. I have seen examples even with the latest JDev build where refactoring has resulted in cryptic runtime errors. Also JDeveloper seems to move some objects better than others. JDeveloper has gotten a lot more complete with its Refactoring capabilities of late though. Still though, if I can get a wizard to put my files in the right package directory up front, then: so much the better. It is possible when using BC wizards (especially the entities from tables wizard) and project wizards to put all entity objects in one sub part of the package tree, the views in another, etc. on the spot. Just be sure to notice with each page of the wizard how your package specification may need to be changed. A standard they seem to like in the ADF developer’s Guide is that entities can be put in a “entities” sub-package, views in a “queries” sub-package and the application module can be put in the parent directory to both of these sub-packages. There is another part of refactoring which allows you to duplicate a file which seems safe enough. It is used in the ADF developers’ Guide. Sometimes when developing the model layer of your application in ADF it is helpful to be able to visualize what you are doing to give you the bigger picture. For that you can experiment with a thing in JDeveloper called a Business Components Diagram. For example, it is possible to drag entities and their links into view objects in the BC Diagrams; this would represent creating a view object based on one or more tables. Also you can drag views and view links into Application Modules in the diagrams; this would represent what queries and data entities you would need to query or change in your application and how they are all connected together. If you drag and drop an application module that was created by a JDeveloper wizard into the Business components diagram you may notice that they are apparent duplicate view object instances. This automated process sometimes creates multiple instances of view objects and their view links within the application module. This is ok; it seems to be a sort of shorthand; perhaps it is to keep link lines from proliferating within the application module and making things really confusing. At any rate you can use whichever instance of your view objects you find most appropriate. One reason developers like ADF is its capabilities to deal with international deployment to different locales. It is possible to set language/locale-specific information in a view through the view object’s control hints. When looking at the view object editor for a view object you will see a tab for Control Hints. For example if you wanted one set of field prompts for your English customers and one set for your French customers you could use the control hints to create language specific bundles through these control hints that would label the fields with either English or French descriptions – depending on the bundles. VIEW/CONTROLLER: It is useful to note that there is a helpful diagram to help you remember what the “controller” is. The main controller part to ADF is encompassed by something called a page flow diagram which maps one-to-one with a file called faces-config.XML. This file (or struts-config.XML when using struts as the controller instead of JSF. Oracle has switched from pushing Struts as a controller to using JSF controller portion. This is because JSF is a widely embraced specification, governed by JCP (Java Community Process) which always seems to draw Oracle in. Also JSF reacts at the component level, whereas struts reacts at the page level only.) In the background when editing a page-flow diagram you are really editing faces-config.XML. The structure of this file is not too complex. Basically this file mainly defines rules and cases within those rules. For each web page in your system you create a rule. Within that rule you create a case for each button or link that navigates to another page. You can also define rules that are more global in scope; for example what if you have a menu bar which you want to be included on every page. You do not want to have to define the menu bar navigation links over and over again with each page, so there is a syntax that allows you to define these rules and cases once and forget it. Also there is also a default rule that will take an errant navigation back to a pre-decided location. Also there is a redirect setting for each case that determines what the URL will say on the browser address bar and whether it will reflect the page you are currently on or not. You want to use redirect for sure if the action taking you from one page to another could cause harm if it is executed more than once (e.g. like charging double on someone’s credit card). In general though you do not need to get too involved in changing the contents of the background navigation XML file if you are using the page flow diagrammer. You intuitively define pages and use actions to connect them. Then when you create a button you have to plug the action into the action property of that button and you are on your way in many cases. RMOUG Training Days 2007
  11. 11. Metamorphosis from Forms to Java … Fons (Please note that the faces-config.XML does many other things as well besides control navigation; it helps you keep track of what sort of managed beans you have associated with your application. It also allows you to alter the life cycle of your application for some advanced techniques.) How do you navigate passing keys from one page to another?? That is a huge question that loomed in my mind when I started learning about going from one page to another. Primarily navigation passing keys is done automatically for you by virtue of how views object instances (collections/iterators) are linked together with view links and view instances with view link instances. If you use the same view object instance/iterator on a couple of different pages the current row will automatically be remembered from page to page in your application. (There are other means of customizing this functionality. You can pass data using parameters or process/request/session beans. You can pass data from one page to another using something called transient view objects, which are like control blocks in forms…that is, they are not really connected to a table, like a normal view is. We will talk more about this later in the paper.) In the page flow diagrammer you will have icons representing your application pages and lines showing what navigations there are from one page to another. The page flow diagrammer has labels on the transitions from page to page. These are actions which will move you from page to page for the buttons/navigation GUI objects; if a component can reference one of these actions to cause navigation there will be an “action” property in that component’s property palette. In this editor just double-click a JSF page icon to create/alter the page and its attributes. This will open the Visual Designer (GUI editor) in JDeveloper. In the Visual Designer, you can drag and drop both GUI objects from the Component Palette and the Data Control Palette onto the Visual Designer. You can also drag operations and drop them on your page. When you drag an operation you must specify how that operation will be manifested (if, for example, it is a button or a link). What manifestable components are offered when you drop something depends on the operation and the component. You can drag and drop onto the Structure window in JDeveloper which is probably easier than trying to select “invisible” elements. For example dropping an existing button into a panel button bar would be easier if you just drop the buttons onto the component in the structure window. Also you can sometimes click on an element and then simply click on a component and the component will go into the highlighted element as applicable. This action is equivalent to click-and-dragging a component to the structure window or the visual editor and dropping the dragged component where you want it. Jspx Page definition files and “bindings” There are lots of references to bindings of various sorts in the Oracle manuals. “Bindings” seems to be a generic term people use when they are bored and want to sound smart. Really though: bindings are used all over the place and are very, very important to learn about. In fact, Peter Koletzke says in Oracle JDeveloper 10g for Forms &PL/SQL Developers that “familiarity with manually creating and editing bindings is the key to success with [ADF]”. Did you hear that? “THE key”. So, before you learn to manually create and edit these bindings you should at least know what the kinds of bindings are that he is referring to. In the Oracle ADF Developer’s Guide it talks about three kinds of bindings -- Iterator bindings, which bind to an iterator that tracks the current row in a data collection; value bindings, which connect UI components to attributes in a data collection; action bindings, which invoke custom or built-it operations on a data control or its data collections. But Peter Koletzke says there are 8 kinds of bindings (he also says Iterator bindings should be considered separately because they are special): Attribute Bindings, Table Bindings, Action Bindings, Method Bindings, List Bindings, Navigation list bindings, Boolean bindings, and Tree bindings. What is being “bound” is stuff on the model and view ends of the MVC spectrum. For example, an XML file that JDeveloper creates and updates for you will bind an instance of a view object to another instance of a different class called a RowSetIterator that allows a program to look at and act on the individual rows selected from the view. Thus the XML file binds a view instance to an iterator instances. Page definition file is the file that is automatically created and kept in synch as you create a page in the Visual Designer. This file is usually full of bindings as described above. (If you want to see the page definition file you must open the System Navigator on the View menu and look under ViewController project yourpackage  pageDefs  yourjspxfilePageDef.XML. Double click on it; you will see how your jspx file’s references to bind variables originate from this file. Seeing this connection should help your understanding branch out in a good way giving you added coding understanding and flexibility. (Hint: you can also get to this file by right-clicking (the context menu) in the visual designer when editing one of your jspx pages)). If you right click a field in a jspx page you will get a context menu that includes an option called “Edit Binding…”. Clicking this will bring up the Attribute Binding Editor; here is another example of a binding: from a view level field to a view object RMOUG Training Days 2007
  12. 12. Metamorphosis from Forms to Java … Fons level attribute. You could look at this information just through the PageDef file for the page, but this presents the information for this field nicer than the page def editor. Here is an example of an instance where you would need to manually create a method binding: if you want to create a custom method to associate with a button or invokeAction or some other component you will need to do the following: • In the application module editor make sure the java node creates a java file for the application module class. Accept this setting exiting the editor. • In the Application Navigator, with the Application Module selected, the structure pane will show a sources folder inside of which there should be your application module java file. Double-click on that to edit the java. • Add your custom java method to this file. Save this file. (is a rebuild necessary at this point??) • Go back into the application module editor and go to the client interface node. Expose this new method you created which should now appear in the left pane of this section – i.e., move it to the right pane by highlighting it and pressing the “>” button. • In the page definition file for the page which has the component that you want to invoke your custom method use the structure pane to insert a method binding into the bindings folder which calls your custom method. When the Action Bindings editor comes up click on the app module data control and you should be able to access your newly exposed method. • Finally create your component or executable invokeAction and associate it with the new method binding. For example if you wanted to create an invokeAction on this page open the page definition for the page. In the structure pane there will be an executables section. In the executeables section will be listed all the iterators (view object instances) which you wanted on the page. Select an iterator before or after which you would like your invoke action to be run. Right-click that iterator. Choose to insert before or after from the context menu. Choose invoke Action from the context submenu. In the editor that comes up for this selection specify an appropriate name in the “id” field and then choose your custom method in the other field. Accept these settings. (Aside: note that since you have put your custom method in the application module implementation code that means that your code is inside the instance of the application module that your application is running against. That means you can access (read, modify) anything the application module instances has access to (which is really all the data-related items in your application…so your code is in a mighty good place. For example you can look up and alter any view object instance – like setting a query bind variable -- in your application.)) A WORD OR TWO ABOUT BEANS The Java code we just talked about in this paper is centered on manipulating areas of the model and the java code that implements those areas. But there is also Java code associated with the view side: managed beans and a subset of those beans called backing beans. A managed bean is a java bean that you create to do something special or to store some special data. A backing bean is a managed bean for a particular page. In these backing beans there is one attribute for every component on a page by default (note that there does not have to be one attribute for each component; if you do auto-binding there will be, but if you manually create the bean you can elect to only create the needed attributes). In the managed beans there can be any attributes at all that you decide to create. These beans have different scopes that last for the request, the session, and the application. Really important (according to Koletzke) that you learn to interact and manipulate the binding data through beans. Learning to manipulate the binding data (metadata) manually and programmatically through managed beans is the key to expanding your skills in JDev/ADF beyond that of a novice. These skills essentially allow you to go anywhere with these tools. To be frank I have not yet learned to do this, but I would recommend studying the subject. From what I have seen you use some managed bean code and a class called a Context to get at the entire layer of binding. It is possible to both get and set binding data from here. On thing I have done to date is to create a bean and get and set bean attribute values declaratively from the view layer in various ways. One thing I learned in so doing was to use beanname.attribute, not sessionscope.beanname.attribute, even though my bean was defined as a session bean…i.e., a bean in the session scope. Specifying the scope prior to the beanname in the ways I was using it seemed to give me an error instead of the desired results. The error itself did not make any sense to me, but I did manage to connect it with referring (wrongly) to the bean attribute in that apparently erroneous way. RMOUG Training Days 2007
  13. 13. Metamorphosis from Forms to Java … Fons In most cases the adaptations you might make to a backing bean will not thwart JDeveloper’s ability to automatically maintain the code in the backing bean to match the components on the page the backing bean is for. So when you create a new component in your .jsp(x) page JDev automatically keeps your backing bean up to date, creating new attributes and accessor functions to match the new components. Unfortunately the automatically-added attributes have cryptic names many times based on what type of component it is instead of being named for the function the component is playing your application/page. So you will want to rename these attributes in a way that will change all references to it simultaneously to avoid errors. The best way to rename and attribute in your backing bean is to click on an element in your page in the structure pane or on the visual editor the in the property sheet change the “id” property. (Make sure the new name begins with a lower case letter; not following this convention could cause an error later.) This change will cascade into the backing bean automatically, renaming the attribute and accessor functions. Here is a description of some of the experiments I did using beans of various kinds to try to pass data from one page to the next. (I want you to know from further reading I have done that it is possible to pass data from one page to the next using a request or session bean, but each supposedly uses a different technique than the other.) I first passed rowKeyStr (a reserved word the value of which is a manufactured unique key to a particular row in a rowset) using a setActionListener to a bean attribute of type String. That worked. I bound an output text to that bean (session bean). That worked, too, putting the rowKeyStr on the new page, since I made the value of a field declaratively set to the bean attribute. Then I tried passing a values from the iterator other than rowKeyStr; I had success in this with String type collection columns but got an type mismatch on numerics. I guess if the source column is numeric it will not map to a java.lang.String, but defining the target attribute in my session bean as java.lang.Number did not seem to help either: the datatype mismatch still occurred. I tried (for the first time) to use the debugger, but it could not find the source for the I found setActionListener.class but the debugger acted like it needed the java to really do some butt-kicking. The library for ADF showed where the source was, but it was in a zip file and the innards of the zip were not organized as I expected so I gave up on that and decided to start pursuing other ideas. My second exploration involved something I heard about called process scope. This solution involved using the binding bean for the page to set the process scope to hold the value desired. Then bind this value to the field on the target page. As it turned out…I did not even have to use a bean. Instead I told the setActionListener to do a (from, to) of (#{row}, #{processScope.detailContacts}); note that “detailContacts” did not refer to any object in existence at the time…just a made- up name. Then I made the target page reference #{processScope.detailContacts.Pid} as is value. This worked great! A downside to this is that you cannot create a URL that will reference this page if you tie it to process scope. However there are several problems (I hear) with using request scope or session scope for the same purpose. I think it is especially odd that I could simply pull something like “detailContacts” out of my…uh…head…and have ADF be OK with me assigning to it and referencing it later. I think in reality I am supposed to be using java to pull and push. But I had problem with some sample code I found on the web, so I waited to use that method until my next experiment. Also it does not seem like “processScope” is in the list of scopes you can assign to a managed bean that you might be creating. Since these attributes and beans are created apparently automatically I guess this makes sense. MISCELLANY The next set of helpful topics and ideas are disparate, so the heading for this section is appropriate. Prepare for a variety of topic, each of which seemed notable at the time I…noted them. ADF trees: There are several kinds of tree components available to the ADF developer. The simplest is the Tree. (not TreeTable or MenuTree). I have also experimented with an in-line table which has a tree component to it that is probably somewhat like that of a TreeTable’s, but I am guessing somewhat here. Here is how to create a tree yourself: Drag the collection from which the root should come from the data control pallete onto the visual editor. When you drop it specify that you want a tree. A tree binding editor will pop up. In order to create the different tree levels you will need to create rules. In fact you will need to create one rule per tree level. Also you will need to specify which data elements you will want to see on each node (space separated). Finally you will need to specify which linked child collections you should specify to connect the current rule to the next child rule you will create. This connection you would specify in the list called the Branch Rule Accessor. It is possible by manipulating the source tags for this tree to be more particular as to how each node will look. In order to do that you will need to do a lot of editing to the contents of the trees facet, NodeStamp. For example this sort of editing would allow you to have one particular link level display a link that would take you to a particular page, rather than just display an informational node. If you do not see the Branch Rule Accessors that you expect to see you need to RMOUG Training Days 2007
  14. 14. Metamorphosis from Forms to Java … Fons possibly create additional view links and view link instances on your business components diagram. Be careful that if you specify a view link for which there is no entity association you will get a compile-time error. If JDev offers to encase your tree in a form, do it. You will get a run-time error if you do not. If you want the tree next to your other items try dropping the current form and the tree form into a horizontal panel component. Turning away from trees we now look at ADF Faces switcher and JSF Facets; If you want to display different components conditionally you can using these components together. Group the n objects in ADF faces panel groups. Drop each panel group into a facet. Drop all facets into the switcher. In the switcher properties make the default facet one of the facets in the switcher In the switcher, set the Facet name to a conditional EL expression using bindings. You can use the ternary (? :) operator to evaluate an EL Boolean expression based on the number of row returned in an iterator, for example. Now we turn to the topic of tables…the kind of table that allows for displaying of multiple rows in the user-interface of an ADF application. As you drag a collection from the data control palette in to your Visual Designer page you will get the option of displaying your data in a tabular format. This allows you to display multiple rows at a time. If you want to do operations on a row in one of these tables you may need a way to select a particular row as the “current” row. Selection of a row in an ADF Faces Core Table component is fortunately not hard: there is a checkbox in the wizard that appears when you create the table that creates the parts of the table that allow you to select a row. Check it and you will get a radio button and a control button which will select the current row and do the operation of your choosing on that row. If you need to add this selection functionality later you can right-click the table component and select Edit Columns… in the context menu in the structure window. (At one point before I realized you could click a checkbox on the ADF Faces table to make selection possible I tried to attach the selection components manually; but I never really got it to work right. Nonetheless here is what I did: under JSF Core there is a Selection component you can add. You can also right click the left-most column header in the table and insert a selection column to the left. Then in the ADF Faces Core components you drag a tableSelectOne component into the AF: table’s “selection” facet.) Let us now look at an operation instead of a component. There is a useful built-in operation called ExecuteWithParams that allows you to query up (i.e., execute) data from a collection passing parameter to the query. The look of this operation as you drop it on a page can be a series of fields and a command button to execute the query (ADF Parameter Form) passing those values to bind variables you can put in your view object SQL statement associated with that collection. The functionality of this operation is pretty straight forward. However if you want to change the prompts to these fields you have to dig a little to figure out how. The place to change the prompt can be found inside the variable iterator which is listed in the structure pane under executables in your PageDef file for the page you are working on. Double-click on each parameter listed to get a property page and change the prompt property. As you proceed through the View layer using JSF components and operations like the ones above you will see the word iterator and another word: collection. At times it seems these seem to refer to the same thing. “What is the difference between an iterator and a collection?” you might be asking yourself -- as I did. An iterator is analogous to a cursor row pointer in PL/SQL in that it navigates through a query result set. Every iterator must have an associated collection of rows that it points to. In Java the concept of a collection can apply to any data structure that holds a series of “things” in it. So an array is a collection, for example. Thus the iterator (or row iterator, as it is sometimes called) points in turn to each sequential row in the collection of rows. These collections of rows map one to one with view object instances in the model side. View Object Instances are what your views turned into after you dragged them into the application module in your initial BC diagram. They are also the main thing inside of an application module. A view object instance, however, is not the same as an iterator. To illustrate this note that when an iterator is refreshed it does not necessarily mean that the underlying view object instance has been re-executed, which would re-query the database. Also note that a data control is the view side analog to the model-side application module…which would make collections/iterators the analog to view object instances respectively. In the page definition file, iterators are bound to a view and a data control, which makes sense since in many ways the page definition files are the seat of many of the linkages or “bindings” which connect the view and model layers. So iterators point to particular rows in a row collection. Whatever these iterators point to is considered the current row. There are various operations like setCurrentRowWithKey that allow you to programmatically set which row is the current row. A rowKeyStr pseudo-column gives you a simple way of uniquely identifying a particular row which is passable on the URL address line so that a particular page is bookmark-able. RMOUG Training Days 2007
  15. 15. Metamorphosis from Forms to Java … Fons Here is another interesting view-layer topic: as you create a web page JDeveloper’s new web page wizard will ask you whether you want your page to be a .jsp page or a .jspx document. What is the difference between .jsp and .jspx? From what If you are using any ADF Faces components there will not be any difference at all except for the file name extension; apparently once you start using ADF: namespace components you are actually required to do straight XML; JDeveloper takes over in this departments, as I understand it. So in such a case your file extension may say .jsp, but it will really be a .jspx. At any rate the main difference between .jsp and .jspx files is that .jsp file can contain embedded servlet code and HTML; the .jspx file is straight XML so instead of embedded servlet code it just uses components instead that will take the place of what the servlet code would have coded before. There is no HTML in .jspx documents. With the embedded servlet code you can use in .jsp files you cannot also have a good portability to non-pc-browser end-user devices…like telnet devices or palm- pilots. In the view layer you will see the acronym JSF a lot. It is present in the controller layer and the view layer.Java Server Faces (JSF) is an open standard that ADF Faces is in compliance with. I have a goal to read more about this standard, but I am not there yet. I would recommend checking it out though. One notable thing I saw about a JSF component though: JSF components have a “binding” property that binds a bean attribute to a UI component. This is completely unrelated to the ADF bindings we have discussed so far. JDeveloper Pitfalls As I have worked more and more with JDeveloper and ADF I have tried to keep a tabs on anything I saw that would throw a monkey wrench into the learning process for newbies. Here are some of the things I observed. • If you move your JDev home to somewhere else on your computer other than where you originally installed it, at least the embedded server.XML and a good many other files will need to be changed. Because I had not done much work in my JDev installation before I moved it, I initially edited all the files by hand using the os search to detect what files still had the old directory. Really though it looked like you really needed to un-deploy anything I had deployed to the embedded server and then let JDev redeploy it. I will have to try that next time if I need to move the JDev home; I think you would have to use the admin.jar program to undeploy from the embedded OC4J instance. If you simply move the directory from one place to another with out this undeployment process, you will get the following runtime error: “06/12/07 09:13:22 Error initializing server: At least one valid code-source or import- shared-library element is required for shared-library quot;global.librariesquot; in /C:/Documents and Settings/scrvl.rjv/Desktop/JDevstudio10131/JDev/system/oracle.J2EE. oc4j/config/server.XML.” • When you start to try experimenting with setting up security for your application you may find there are many options to choose from. The documentation for navigating this subject is divided into the developer’s Guide, the OC4J manuals, and the OAS security Guide…as well as others probably…depending on what you are looking for. One specific thing in this process I found hard was finding how and where to activate the Authorization Editor. In order to get to this you have to open the page definition for the page in question. Then you have to click on the page definition page, then go to the structure window and right click on the Page Def (root) node in that structure window. There you will see an option to “Edit Authorization”. Similarly some more settings will need adjusting in the web.XML in the view part of your application. At the web.XML file in the WEB-INF directory you just right- click and choose properties; this brings up an editor for all the possible settings of web.XML. Also initially you will want to alter your embedded oc4j setting which are at the bottom of your JDeveloper tools menu. • There is a small inconsistency in the naming of the kinds of basic objects you will be working with at the business component level. Entity Objects represent a row in a table. Entity Definitions represent the table itself. Compare this to View Objects which represent the entire query and the view definition, whereas View Row Objects represent rows returned from a view. It seems to me that maybe they should have been named View Definitions and Views, or Entity Definition and Entity Rows, but maybe that is just my inexperience talking. (FWIW, the metadata of the base objects are found in something called a StructureDef and children called AttributeDef’s.). • If you want to create custom properties for either the application module, entities or view objects you will find that the JDeveloper for entering these is annoying. You apparently have to select the entire string in order to add several of these at a time. Also you cannot enter any with a null value so if you try to update the value of the first property you enter to be the second value first then you were going to update the name…that will not work. But do not despair: it is not impossible to create custom properties. • Remember, when you test your applications on your embedded OC4J, that you need to include your ip address in your proxy exceptions. At our site we get timeout errors when we don’t do this. Also the JHeadstart development RMOUG Training Days 2007
  16. 16. Metamorphosis from Forms to Java … Fons Guide warns against this kind of problem, saying you should use localhost instead. To do this you must enter the embedded OC4J configuration tool available in JDeveloper. • I have had to reboot a couple times because the business component diagrammer got confused and locked up the computer doing God-knows what. One oddity is when it starts creating really long link lines when you repeatedly delete and re-add large numbers of model level components. I almost sense that it may be better to just not use the bc diagrammer at all for now until it is a little more stable. • In Chapter 27.9 of Oracle® Application Development Framework Developer’s Guide For Forms/4GL Developers (10g Release 3 ( B25947-01)(hereafter called the ADF Developer’s Guide in this document) the topic is about having view objects with multiple entity object instances within them -- each of which are updatable. Apparently the way to achieve the feat is to check an “updatable” checkbox in the entity object panel for all of your entity object instances that you might want to update. Instead of instructing you to do this common-sense action it soberly and beautifully instructs you to do the exact opposite as far as I can tell (bringing credence to the old adage, you can’t believe everything you read): When you create a view object with multiple entity usages, you can enable a secondary entity usage to be updatable by selecting it in the Selected list of the Entity Objects panel of the View Object Editor, selecting in turn each entity that is part of the view object definition, and deselecting the Updatable checkbox. By the way, view objects based on multiple entity usages seems to be treated specially when it comes to doing some DML operations. It appears to really operate on them you will need to have a very good understanding of how Views and Entities are implemented and how to extend their functionality. Check the developers Guide for more information in some of the advanced chapters in the ADF developers Guide. It would seem that as things progress in the 1000-page ADF Developers Guide from Oracle that there are various typos or omissions. I guess proof-readers can only do so much because they are not necessarily subject matter experts of what they are reading…kind of like when your spell checkers auto-corrects your word to be spelled right but it’s the wrong word for the context. Most of the errors I have run into are pretty obvious when they occur if you have been reading sequentially through this Guide. But in addition to the one above I would like to alert you to a few others: • In section 9.7 right before the first example in that section there is a reference to ServiceHistoryImpl entity row class. This should be ServiceRequestImpl. This typo is somewhat confusing. • In example 9-16 there is a reference to a method called getUserIdForLoggedInUser that they use but they do not explain. I think this would just be a custom method in the SRServiceImpl application module class that would get the current row from the view in question and then get and return the userid attribute from the view. Perhaps I am spoiled but really they had up to this point been so good about explaining where each bit of code comes from. • In section 9.6.1 I got very confused (Creating View Objects at Run Time for Validation). It would have helped me to understand better if they had mentioned that the view object instances that are used for validation would need to be named with a certain naming convention…not the views themselves. The convention for a view with the fully- qualified name of a.b.c.theView is that the view object instance for that view if it is to be used as one of these validation views should be named Validation_a_b_c_theView. Here are some other JDeveloper potential pitfalls: • I think if your JDev instance is forcibly rebooted while it is open and certain changes unsaved, the reboot can corrupt your installation. I ran into a problem and reinstalled JDev and the problem went away. (Here were the problems: if your ADF Faces Core component palette icons turn to all angle brackets (< followed by >) I found a work around to bring JDev back to its senses. (I do not care so much about the icons but rather when you drag these angle brackets into the visual editor the visual display looks completely different…it’s like the visual editor does not know what to do so it reverts so some tag mode…which is not very helpful.) So the work around is to go to the view controller project properties page. Click on jsp tag libraries. Uncheck the box to display the properties in the component palette for the ADF tag libraries. Click OK. Confirm that ADF Core option has disappeared from the component palette. Go back into the project properties and recheck that box. Now the icons will be restored but the drag and drop still brings up the primitive functionality.) • In the property sheet if you change a property and then press Save All button it will reverse the property you just changed, so get out of the property before saving. RMOUG Training Days 2007
  17. 17. Metamorphosis from Forms to Java … Fons • In an oracle document they indicated the Rendered attribute of a ADF Faces component called a PanelHorizontal could receive a data-driven EL expression as a property. In reality it appears you need to edit the jspx file to do this, whereas in the document it indicated you could click on the attribute and there would be an ellipsis (…) allowing you to enter the EL expression. If you set rendered to true or false (these are the only values JDeveloper visual designer editor property sheet would allow you to set rendered to – through a dropdown list) the Source tab of that jspx file will show rendered=”true/false”. If you then enter a boolean EL statement it will conditionally render this component. Oddly enough the property sheet dropdown list will go away and will be replaced by an ellipsis field as described in the documentation. Maybe this is a difference in sub-versions of the JDeveloper product and the documentation; or maybe it is just the author forgetting something. (You can use the Bind To Data button when you are selecting a property that could potentially have EL in it. The icon for this button looks like a database icon (cylinder…like a disk-pack)) • If you use bindings EL expression to keep a record counter against an iterator, and the iterator’s RangeStart expression does not seem to be advancing make sure that the page definition file’s setting of Range size is set to the number of rows displayed on the screen is set to the right number. The default for this attribute for iterators seems to be 10. At various times in my journey of learning ADF I hit various plateaus of learning. One happened when the idea crossed my mind, “How does one go from one page to another and carry the context with you?” This literally threw me off for weeks. I do not know why learning about this topic had to be so hard…I begin to feel like I had been trying to figure this one out forever. As I mentioned before in this paper the table select one component will fairly easily go from one page to another if the in the data control palate you use the same iterator on the source and target pages. In learning about other aspects of passing data from one page and regaining the same context on another I experimented quite a bit; here are some the experiments I underwent: • It would also appear you can create links when you use the setCurrentRowWithKey operation as well as the rowKeyStr pseudo-column. You can drag the operation from the appropriate iterator from the DataControl palate near a column in the table of data. Then it is possible to alter the page definition file of this to alter the value of the parameter of the action binding that was automatically created by this operation-drag. Although this maneuver was described someone in a manual I was reading I was never able to get this to work. • I also tried creating my own managed session bean in the prescribed manner; I initially when I did this I got an error that made it seem as if the bean was never initialized and the constructor method was never called; this was due to the way I was referring to the bean attributes (through the sessionscope) which was not what ADF was expecting. • If you have an ADF Faces table with a current row selection aspect, it would appear from some on-line JDeveloper documentation that you can create an ADF Faces action listener as a child to the command button that comes with this table. The sole purpose of this action listener is to wait for someone to press a button, and then do a copy from some value to some other place right before the action associated with that button is carried out. The action listener component, for example, might have the following as the from and the to values, respectively: from of #{row.rowKeyStr} and to of #{requestScope.rowKeyStr}. At another point in my learning I was trying to delete and create in turn both the model and the ViewController projects. During one of these experiments I got oracle.jbo.ConfigException: JBO-33001: Cannot find the configuration file /edu/usafa/camis/sandbox/test2/model/common/bc4j.xcfg . I looked for quite a while trying to solve this problem before dropping back and going with what I knew at the time. In metalink there is a doc id of Note:267048.1 that related to JBO-33001. This note speaks of JDev producing code that uses libraries that are out of alignment with the oc4j libraries. That problem description did not fit with the basic thing I had tried to do, though. I would recommend at least initially that you create and ADF bc, JSF application and then use the entity from table wizard to have the wizard do as much of this work for you as you can up front, without having to create the individual pieces. At this point I know that a ViewController and a Model project are bound together most easily by looking at the dependencies node in the ViewController project properties. There is a checkbox that needs selecting. But if you do not know that checkbox exists you can spend a long time looking. This may help you if you have to drop and recreate the ViewController project. Here is a good hint: if you run into an error it may be helpful increase the granularity of the logging that occurs while your application is running. Although the online JDev documentation is slightly wrong (they do not tell you the right directory RMOUG Training Days 2007
  18. 18. Metamorphosis from Forms to Java … Fons look in to see the file you have to change to alter the logging level) you can go to <JDevhomedir> In this file you need to set java.util.logging.ConsoleHandler.level=FINE and then add the line to this file: com.sun.faces.level=FINE Then you get messages like the following… FINE: getValue Result:000200000004C3030F4200000003C20863000000120000010E1BF42914 Oct 5, 2006 10:50:02 PM com.sun.faces.el.ValueBindingImpl setValue FINE: setValue Evaluation threw exception: JHeadstart extension to JDeveloper JHeadstart like its predecessor Headstart is something you generally have to pay extra for. But it is a good productivity enhancer most likely depending on your needs. With our site license it is part of our Supplemental Option. JHeadstart extends JDeveloper. Much of its functionality lies in the ViewController section. All the things you learned about setting up the model part of your application are apparently still necessary for this productivity enhancement tool. This tool allows you to more quickly generate the View/Controller layers of your application. The two versions I worked with for this product were easy to install. 10.1.2 was available for free download at the time I investigated. The installation process for this version was manual. The Zip file came with install.html that walks you through the process. It was about 5 steps: unzipping, copying some jars, copying an XML file, open JDev and tell it where jhst home is. But now the update manager pretty much does the whole thing for you. I was fortunate to be able to download the latest version because the company I worked for had paid for the Supplemental Option of our site license which entitled us to download this software. Although I know it is an option of the JHeadstart tool to be able to access and work with module definitions in an Oracle Designer repository I did not experiment with this technology. My focus has been more on learning how to manually work with and understand ADF on the manual level. Other members of our team were tasked with better understanding this technology however. There is apparently quite a bit in the JHeadstart view layer generation that is configurable – just like in Oracle Designer module generation. In some cases JHeadstart creators have tried to parallel the creation development environment of Designer and Headstart in this. One thing is different however; the designers of JHeadstart are no long pushing 100% generation very hard…at least at this point. They are instead touting this tool as a generate until you have done all that is reasonable, then cut over and do manual changes the rest of the way. This tool helps to keep a consistent look and feel just like regular Headstart: Oracle uses a skin type for its portal applications which it calls BLAF (Browser Look and Feel). Also ADF Faces/UIX use BLAF by default. This BLAF was tested in many usability tests by Oracle and is the results of these tests (as well as internal and external comments on it, no doubt). I have heard that there are competitors to JHeadstart but I have not put energy into finding out more information about them. Taking it for a spin. At the time of writing this paper JHeadstart 10.1.2 was available for download by anybody at . That version is compatible with JDev 10.1.2. While this version is informative to play with 10.1.2 to 10.1.3 represented a huge change. It is almost pointless to try and do any real work with these older versions at this point because of the direction it would take you. Whatever version you use I recommend creating a trial application. To do it you really only need a few tables which have parent/child relationships. Create a model for them (entities, views, application module): • Create a db connection on the Connections Navigator. (If you are familiar with tnsping or tnsnames.ora, creating such a db connection should present no issues.) • Once you have the db connection created drag some tables from the db connection to a business components diagram, create some views, drag the entities into the views, connect views with links as appropriate (following fk’s of tables), create an application module, drag the views into the application module, and connect them with view link instances (again follow fk’s of tables). (Note: to edit which db connection your application will use right-click the application module and choose the Configuration Editor. From there you can edit these settings.) RMOUG Training Days 2007
  19. 19. Metamorphosis from Forms to Java … Fons • For the ViewController project, right-click the project and click “Enable Headstart for this application” from the context menu. • After JHeadstart-enabling the ViewController project, you can right-mouse-click the project and choose quot;JHeadstart Application Structure Wizardquot;. In this wizard, you can select any ADF Business Components application module from all model projects included in your workspace to base your web application on. (Note: in 10.1.3 this was renamed to the command “New JHeadstart application definition” in the viewcontroller context menu) • To generate a struts-config (note: in 10.1.3 changed to faces-config) and pages using JHeadstart, right-click the Application Structure File (note: 10.1.3 now called application definition file) and choose quot;Run JHeadstart Application Generatorquot;. • Run the generated application by starting index.html (or by running the ViewController project). • Like most Headstart products the default creation is basic and functional but it is a lot of functionality in a very short period of time. Also changes to the basic generated application vary in difficulty depending on what changes you want to make. • JHeadstart issues/pitfalls • If you are trying to use the version of JDeveloper against a version that is earlier than I have seen a coworker get errors due to that. When you try to run a generated application it may give errors related to “whitespace” being needed. • Note: before running a generated application it is a good habit to always rebuild the viewcontroller project before running. I think the reason for this is that JHeadstart makes a bunch of changes after it is done generating that require rebuilding. It tells you to rebuild in the log, but who reads warnings on the JHeadstart error log…?  At one trial of this product I got the error: code segment of method _jspService(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) too large -- if you remove some attributes from a view with a lot of attributes this clears up. This occurs when you try to run the viewcontroller project sometimes. In my case it seemed to occur when I made a view out of a table/entity that had a huge number of columns. (like 100 or so…) SOA – Service Oriented Architecture The desire of management for going to this type of architecture was to enable us to do implementation of our services with whatever technology is currently available. Today it is Java. Tomorrow it might be…who knows. This means that established data interfaces between two organizations in our company, or two parts of the same organization or system will need to be defined in a way that will balance usability with maintainability. Ask Paul how he feels the proposed technology configuration will support SOA. I think he visualizes anything being put into portlets. So the interface he may be talking about is that we write a program, and it interfaces with OAS’s Portal framework so that it is displayed and is run-able by the clients of our system. I would like to study SOA some more, but this paper is due to the RMOUG office soon for printing. A Few Random Parting Tips Like the Titanic I feel I have just bumped the tip of something very big. My next goal is to make JDeveloper “mine” as it were by continuing to play with it and use it in pilots and eventually production-level work. Here are a few parting ideas that I have encountered for you. • At some point in creating your application JDeveloper asks you what sort of DOCTYPE to use. Don’t use xhtml 1.0 strict; doing so causes an error at runtime with my current build of 10.1.3. • If you need to debug your model code there is already a “main” method built into your application module implementation java file. If you run the application module you can do so in debug mode by using the right-click context menu. JDeveloper will allow you to use the business components browser to test your business tier. This browser is kind of cool anyway. Running it in debug mode is even cooler. • As you publish your custom methods into your client interfaces you may not be able to immediately reference your new modules in java code editor’s insight function (where you are prompted to complete your code automatically) by using the structure pane to request that your client interface be rebuilt for your object. RMOUG Training Days 2007
  20. 20. Metamorphosis from Forms to Java … Fons • There is a neat and simple program (which eventually turns into SRDemo) that the ADF Developers Guide for Forms developers that starts in chapter 5.7 and continues building on that simple program. I found the program extremely useful for demonstrating the reality behind the GUI JDev IDE. Among other things it shows that there really is a class called an ApplicationModule and that that class “contains” View Object Instances, which are findable, queriable and displayable. I recommend copying it and running it for your own sanity. In the same way you down load extensions from technet using JDeveloper, you can download this program and analyze its code to verify and reinforce what you learn. • In application modules when you learn how to create you own custom methods note that nothing much can be done in the constructor with the application module itself. It would appear that the default constructor which is created for you (if you choose to tell your application module to generate a java file) does not represent the true beginning of the application modules life. If you want to reference the application module right after it has been created and set up you must create a “create” method which will override the create method of the super class. So in this method you call super.create(), then you do whatever you want to do with the app module which needs to be done at the beginning of the application module’s true life. • Later when you are a bit more comfortable with writing procedures within the extensions that JDeveloper can automatically create for you for each entity and view object, I would recommend reading (or trying to get through) Chapter 25 of the ADF Developer’s Guide for forms/4GL Developers. It has so many important concepts in that one chapter. For example this chapter alone covers how/why/when to extend base classes, how to call stored procedures and functions, and how to create your own Framework Extension Layer library which will save you lots of headaches down the road. (Really somehow this last topic should be incorporated somehow WAY before chapter 25 I think.) Interviews During the creation of this paper I interviewed many people where I worked. I think these interviews added to my perspective. I would like to thank each of the people I interviewed for sharing their time and their thoughts. I hope I have been able to capture some part of their thoughts in the sentiments of this paper. Resources As you find your favorite learning resources they will lead you to other resources. RMOUG Training Days 2007