Java Hair

For those of you wondering how my presentation turned out in Atlanta this past Monday, I can tell you, it turned out very well technically, but as far as attendance was concerned it wasn’t exactly an arena-sized audience. I think the user’s group itself is more centered around DBA’s which is typical for these types of events.

This post covers one of the basic techniques I demoed in my presentation on Monday. A simple editable list page. I will do a series of posts starting with this basic concept and expanding upon it in subsequent posts adding functionality as we go.

An Editable List Page

A common type of functionality in a lot of Oracle Forms applications is to have a list of records in a block and allow the user to edit those records, delete those records, and even create new records.

In ADF 11g, this would translate to a JSP page that allows you to list the rows in a View, edit and delete from those rows and also create new rows. This functionality is actually very easy to create.

Let’s go over it step by step.

1. Create a new application in JDeveloper (File -> New -> Application(Fusion App)

JDeveloper will use a template to create the basic project and file structures needed for an ADF application.

2. Create the necessary Business Components from Tables.

Right-click on the Model project JDeveloper created in the previous step. In the New dialog, open the Business Tier node and choose ADF Business Components. In the right pane, choose Business Components from Tables.

You will now need to create a new database connection. Click the New button where it appears next to Database Connection. Set the name to something appropriate and set the attributes accordingly. You can use the Test Connection button to insure it gets created correctly.

Click OK and you should be back at the ADF Business Componens Wizard.

Click the Query button to the right of the wizard and JDeveloper will return a list of available tables and views that you can create Entities from. Select Departments and move it over to selected, then click on the Next button.

The next screen is the Updateable View Objects Screen, move the Entity over to the “Selected” column. Press “Next” and take all of the defaults until you can click “Finish”.

Click the “Save All” button.

3. Create the JSP Page

Right click on the ViewController project. Select “New”.

From the left pane, choose Web Tier -> JSF, from the right pane, choose “JSF Page’. Click “OK”.

Give the page a name like departmentList.jspx (We use the x at the end to denote an XML compliant JSP page, but it isn’t necessary).

Once the page has been created, open the Component Palette. Make sure the component list is “ADF Faces”. From the layout pane, choose the panelHeader and drag it onto the page. Click on the properties panel and change the text propery to “Department List”.

From the right side of the IDE, in the Data Controls pane, open the AppModuleDataControl. Click on the DepartmentsView1 object and drag it into the panelHeader. Choose Tables -> ADF Table from the create menu that pops up. At the confirmation dialog check Sorting, Filtering, and Row Selection to enable these features for the table. JDeveloper will create a table on the JSP page.

Next, drag a panelGroupLayout component from the Component Palette over to the panelHeader. Click on the properties list and change the layout from scroll to horizontal.

Next, open the DepartmentsView1 node in the AppModuleDataControl, open the Operations folder, drag the CreateInsert button into the panelGroupLayout. Click on properties and change the name of the button to “Add”.

Drag the delete button from the Operations folder over into the panelGroupLayout.

Open the Operatons folder of the AppModuleDataControl itself, it will have two operations, Commit and Rollback. Drag them over into the panelGroupLayout next to the other two buttons.

Congratulations! You’ve done it. Right click on the JSPX file and choose Run to see your masterpiece in action. You should be able to add rows into the table, edit existing row, and delete existing rows. None of it will be persisted to the database until you click “Commit” and you can always “Rollback” all your changes. You should also be able to filter the table with the input boxes on top and Sort it with the little triangles on the columns.

If you play with this example you may notice a couple little “bugs” or “features”. In my next post I will discuss a couple of these and how to mitigate them.

In the following weeks I will be expanding upon this simple demo to include ADF Task Flows and creating separate pages for creates and edits as well as a Master-Detail page or two.

 If you are looking to migrate your Oracle Forms applications to Oracle ADF applications, you have probably wondered about how they would map. You probably did a google search and ended up at the Oracle ADF Equivalents of Common Oracle Forms Triggers page. This isn’t a bad reference, but it only talks about triggers and there is a lot more to a form than just the triggers.

The basic outline of the mappings we use is shown in the diagram here. We essentially use Task Flows to encapsulate the entire functionality of what used to be a Form. The Task Flow allows all functionality including complex business logic, navigation, included popups and dialogs, and even other Task Flows to be shown visually in the Task Flow Designer page in JDeveloper.

Since transactions can be nested, when one form calls another, that can be shown in the Task Flow diagram also. Task Flows are also nice to use in that they can be used to encapsulate transactions.

Another mapping we typically use is to map what were Windows in Forms to JSPX pages in the ADF application. We typically use the JSPX extension to denote that the page is an XML-compliant JSP page. The Items within the Window or Canvases are mapped to ADF Controls.

Blocks map relatively well to Views if they are Query-based blocks. The attributes in the block become attributes on the view that is associated with the Entity that relates to the table the original Block was based on.

The link above that I included talks about transaction related triggers but what about other triggers, like WHEN-VALIDATE-ITEM? Where do those triggers get mapped? In our experience, those types of triggers require some more thinking to map and cannot just be mapped blindly. While it is true that you could map all of those types of triggers to a Java method if you wanted to, since ADF includes the Groovy expression language you probably wouldn’t really want to. Simple validations (and even some complex ones) can be performed in Groovy and thus would probably be best as Groovy expressions. If you could move the validation that was done at the UI level in the Form to the Entity level in ADF you would be even better off. That way you wouldn’t need to repeat the same expressions in every page that modifies that entity.

As June and ODTUG approaches I will be posting more and more excerpts from my presentation (of which this is one).  They will include more detail on some of the ADF features and how those features may apply to migrating Oracle Forms apps to ADF as well as some more step by step how-to guides that go into some of the development details on creating different types of screens in ADF.

Tech Preview 3 of JDeveloper was released around Christmas, which made a nice present for those of us concerned with such things, but as much as I hoped it would fix some basic issues, instead, it added some missing features that I didn’t really need yet and did not address some of the more, in my humble opinion, important issues.

Of course, some of this is perfectly understandable, but I hope the good developers and product team over at Oracle realize that there are a couple of basics that need to be addressed if JDeveloper is ever going to make it to the mainstream.  Here is a short list of some of the items I found in Jdeveloper that bug me.

1. Fix the in-editor code checking. Sometimes I swear this actually works, actually, I know it does sometimes, but other times it doesn’t pick up on basic errors (like duplicate method signatures in a class) until the compiler finds it. This is a basic of all great IDE’s and is one of the biggest issues I have with JDeveloper right now.

On the plus side, it has a somewhat decent editor checker for some of the declaritive properties and Groovy expressions which leads me to my second point.

2. The expression editor is cool and great idea, but at the moment, it doesn’t provide all of the functionality it should. For instance, not all the keywords available are in the editor and sometimes it marks things as invalid (though does not prevent you from using them) even when they are actually valid. Having everything that you could use in the current expression available to you in the editor would be a huge help, instead I find myself combing the web for “Tips and Tricks” articles to find those keywords I need.

3. Fix the property editor. As nice as it is to have the property editor so you don’t need to worry about the names of all those properties and edit the source code directly, it would be nicer if you could fill in a property and not need to click on something else (or remember to press enter)  in the property panel to get JDeveloper to recognize the change. While it becomes second-nature after a while (as does saving after virtually every change), it is really a problem that needs to be addressed.

4. CVS integration leaves a little to be desired. The synching with the server doesn’t seem to work right, and files that are found under the .adf folder and src folders are not added to the project, or if they are, aren’t updated or synced correctly. Other times, synchronization with the CVS server seems to be a little flakey, it doesn’t always catch all the changes and sometimes you need to restart JDeveloper to force it to. On the plus side, some of the merging works really well. And yes, I know, CVS is sooo 2005, but it’s what we happen to be using right now.

5. It may be a little ahead of it’s time. I say this because it apparently was developed with the idea that all developer have 3600X2100 screens to develop on. I unfortunately am limited to 1680×1050 when my laptop is docked and it just isn’t enough real estate for JDeveloper. Maybe in 5 years when my montior is double the size and I have an updated video card I could make use of all the panels that are displayed at once. What I may do in the intermin is hook up another monitor and see if detaching some of those panels and putting them on another screen helps at all, I assume it should but I wonder how well that will work.

As I mentioned, this is a Tech Preview of the product (Tech Preview 3)  so there is ample opportunity for them to fix some of these issues and I am sure a few of them will be addressed.  I just thought I’d throw them out there to vent a little and see what the rest of the community has to say.

SQL, at least the standard SQL and the SQL that Oracle implements does not support Boolean datatypes. In the decades that SQL has been a standard or even taking into account the liberties technology companies take with standards, I would have expected Boolean variables to appear in databases a long time ago. Since they aren’t there, typically a Boolean attribute is represented by a number in the database.

Anyway, ADF is no exception to this rule of not liking Booleans. I would have thought that you could create a Boolean in an Entity, tie it to a Number field in the database, and then create everything as normal, but, at least in Tech Preview 3, it does not appear to be as simple as that.

So I took a hint from my buddy, Andre (check out his blog in the Blogroll to the right, it is full of great examples), and on his advice, checked out an Undocumented Sample from Steve Muench’s blog.

Here are the steps I took based on Steve’s 10.1.2 example to overcome this limitation in ADF 11g. Perhaps there is a better way, but I am not aware of it yet.

To demonstrate this, I added a Number type attribute to the Employee’s table in the default HR schema. I called it OrganDonor, since it’s always a good idea for companies to know which employee’s are organ donors

Create the Entity and View as you normally would. Open the view and add a transient attribute called “OrganDonorAsBoolean”.

Click on “Java” in the sidebar of the View, then click the little pencil in the top right to bring up the “Select Java Options” dialog.

Check off “Generate View Row Class” and “Include accessors”, then click “OK”.

Open the EmployeesViewrowImpl.java file it created.

Change the getter and setter for the AsBoolean attribute:

/**Gets the attribute value for the calculated attribute OrganDonorAsBoolean.
*/
public Boolean getOrganDonorAsBoolean() {
return (Boolean) (new Number(1)).equals(getOrganDonor());
}

/**Sets <code>value</code> as the attribute value for the calculated attribute OrganDonorAsBoolean.
*/
public void setOrganDonorAsBoolean(Boolean value) {
setOrganDonor((value ? new Number(1):new Number(0)));
}

Save everything (as always).

Next, create the JSPX page, make it a JSF page.

Open the DataControl that contains the EmployeesView1 view.

Drag the view onto the JSPX page, and select Tables -> ADF Table.

Select all the attributes you want displayed in the table, do NOT select the original number-based attribute. It will not let you select a “SelectBooleanCheckbox” as component at this point, so just just “Input Text”.

After it puts the form on the page, put a Commit and Rollback button on the page.

Finally, go to the source of the JSPX page and change the input text component for “OrganDonorAsBoolean” to this:

<af:selectBooleanCheckbox value=”#{row.OrganDonorAsBoolean}” />

Now run the page to test it and your check boxes should be working fine.

If I come across an easier way to do this, particularly, one without having to create a RowImpl class, I will post it here.

Here is an unsorted list of 5 simple JDeveloper tips to help speed things up and prevent unexpected problems.

1. After updating your code from a repository, do a clean and a rebuild, especially if changes are made to the JPR files.

Example: We started getting a JAZN Runtime exception:

oracle.security.jazn.JAZNRuntimeException: JBO-25002: Definition com.demo.model.MyView of type View Definition not found

As it turned out, the views had been updated and JDeveloper had not picked up on all of the changes, after a clean, a rebuild and another test, everything worked as expected.

2. After changing a property in the properties panel, click on another property or press enter so that JDeveloper recognizes the change. If you just move on to another file with changing the field you are on and causing a value change event to occur, it will not register the change you made.

This problem is actually resident in many web and Java based systems mostly because the events provided by JSF and Swing never recognize value changes if you leave the component that caused the change.

3.  Use the BC Browser.  I wrote an earlier blog post about it and why it is important.  Basically it allows you easily test the ADF BC layer in your project.  Since the Model layer is the basis for the rest of the application, it’s an important tool.

4 .  Log out of the Version Control repository you are using.  JDeveloper is constantly rechecking the server to see what has changed and update the “Pending Changes” list in the project.  This can cause a lot of unnecessary overhead if you aren’t waiting around for a particular update to be made.  Logging out fo the Version Control server will prevent that from happening.

5.  Increase the memory allotted to the embedded OC4J server.  Often you will be testing your application using the embedded server and it’s default settings are not adequate for most real projects.  You can increase the default memory allocation by right-clicking on your ViewController project, select “Project Properties”, “Run/Debug/Profile”, Edit the existing profile or add a new profile to select.  In  the profile,  select “Launch Settings” and in the input box for Java Options add the options “-Xmx512m -XX:MaxPermSize=256M” or whatever you deem appropriate.

I have been chosen as a speaker at Oracle’s ODTUG Kaleidoscope Conference which will be going on in June of this year in New Orleans. My presentation is entitled “Using ADF 11g as a Platform for Oracle Client/Server Forms Conversions”.

With the introduction of ADF 11g, including both the back-end Business Components and the front-end ADF Faces Rich Components, Client/Server applications can now viably be converted to Web applications. This presentation explores some of the difficulties in recreating such applications in a Web environment and shows how ADF 11g can be used to alleviate some of those difficulties. The presentation will explore a real-life proof-of-concept project that uses ADF 11g as the target platform for a client/server migration project. Real-life problems, their solutions, and code examples will be reviewed.

If you are in town, be sure to stop by and say hi!