Java Hair

This article builds upon the last article in which we created an updatable Departments list page. In this tutorial, I will expand upon that page by adding a detailed list of Employess in the page that refreshes when the user clicks on a new department row. I will use a partial page refresh so that only the Employee table refreshes, not the entire page.

1. The first thing to do is to create the business components as described in the first tutorial. When you are creating the business components from tables be sure to select Departments and Employees both.

2. Next, create a JSPX page in the ViewController Project.

3. Drag a panelHeader component onto the page and set the text property to “Department Master Detail”.

4. Drag a panelGroupLayout component onto the page and set the alignment property to “Horizontal”.

5. Drag the DepartmentsView1 view instance from the AppModuleDataControl into the panelGroupLayout and choose Tables -> ADF Table from the menu presented to you. In the pop-up I deleted all the fields except for DepartmentId and DepartmentName, select row selection at least from the options on top, in this example I selected all three options, row selection, sort, and filter. Set the id property of the table to “departmentMaster”. You need to make sure that row selection is enabled so that ADF will enable you to select a row in the table and this is the event that will trigger the detail table to refresh. Be sure to Save All.

6. In the AppModuleDataControl, open the DepartmentsView1 node and drag the EmployeesView3 view instance into the panelGroupLayout. Choose Tables -> ADF Read-Only Table and select the columns you want to appear. Also check off at least row selection when creating the table. The key for this is to make sure that you use the view instance that is associated with your “master” view, in this case DepartmentsView1, if you use the other EmployeesView instance, the list of employees will not be in sync with what you select in the Departments table.

7. In the properties of the of the emplyees table set the id to “employeesDetail” and set the partial triggers property, found in the Behavior tab to the id of the master table, i.e. “departmentMaster”. This will tell ADF to refresh the employees table when an event is fired on the departments table. Be sure to Save All.

At this point, you have created a page that will allow you to select a row in Departments thereby refreshing the list of associated employees. We have not yet added any button to actually accomplish anything really useful yet, but we will get to it soon.

One item to note is that this will work as described in Tech Preview 3 of JDeveloper 11g, if you are using Tech Preview 4 to follow this tutorial you will notice that this will only work once or twice before you get a whole mess of validation errors. This is because of a problem with the Technical Preview 4 build that includes a JSF library that isn’t what it was developed with, the discussion is described here. The best fix for now is in the view of the jspx page, switch to the source view and comment out all of the tags that you find in there.

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.

Ernst and I spoke at the Northeast Oracle User’s Group Training Day last Thursday.  We were really expecting more of a turnout, as it happened, there were about 75 attendees and about 10 attended our session.  They were expecting 200 attendees and blamed the weather on the poor turnout.  I suppose the weather was pretty bad in the morning, it was raining so hard that a few roads were actually shut down due to flooding.  However, this is New England we are talking about, it should be no less than a Nor ‘Easter to slow things down.

Tomorrow we speak at the New York Oracle User’s Group general meeting.  Hopefully the turnout there will be a little better.

Ernst needed some more technical “meat” in his presentation so I agreed to extract some of the technical overview in my presentation for ODTUG and present it as the second portion in his presentation.  It turned out to be a decent presentation with a nice overview of where Oracle Forms is headed and what customers options are combined with an overview of where ADF is now and why it is a good choice for customers looking to move their applications.

I will be doing a very similar presentation to the one I will be presenting at ODTUG in Georgia on the 24th of March for the Georgia Oracle User’s Group.  This one is actually a conference so it should be a little more lively than the other two.  Also, since Ernst isn’t presenting, I’m doing more of a straight technical talk to try it out for ODTUG in June.

If any of you are able to make the trip, I encourage you to check out the talks.  If you show up and let me know you heard about it on this blog then I’ll make sure you get a very cool Vgo Software t-shirt.

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.

So, I get this all the time “Why should I convert my perfectly good Forms?”. The answer is you should if you have a good reason to. If you don’t, by all means stay there (until, of course, one day Oracle decides you will not have Forms at all anymore; around 1213 or so, and then you’ll need to do something). I see TON’s of blog’s about the topic. Mostly these entries are on Oracle-centric sites and are not, perhaps, as objective as they could be. So, here’s my opinion on the matter (as I find myself to be a relatively objective person).

Wait, before beginning, I need to pull out a blog-shaped soap box.

These efforts aren’t “conversions”. This isn’t a translation exercise. Meaning, if you think you can change from one computing architecture to a completely different one by pushing a button, you’re nuts. It’s just not realistic. From the outset of Vgo Software (and prior to that, NEOS) we used the word “evolution” or “modernize”. To reach a stage of evolution, you have to work at it to reach the full potential of the modernized state (whoa… I’m feeling a little Zen here).

Think about this, Oracle DBA’s out there: when you upgraded from v7 to v8 of the database, did you use consider the cool new features like partitions, a better cost-based optimizer (though, in my ex-DBA opinions, still not great then) or materialized views (I’m publishing my age here)? If you did, did you get all that stuff by upgrading? NO. You had to reconsider your applications using the DB and what impact that the changes would have on them. 

I shouldn’t mention that your manager wouldn’t give you time to implement any of the good stuff as I’m sure that wasn’t/isn’t common at all.

So, back to Forms and Java.  The people that should want to convert would be those folks who want to integrate applications in a standard way.  They want to move towards service orientation and can see integration across application silo’s.  These folks may want to move away from Oracle as an application solution and move toward open-source, allowing them to use a wide community of development resources.  Of course, Oracle has been making great strides as we can attest to. 

But why is Forms evolution hard?  It’s hard because there is alot to do to create a solid JEE app.  In a code translation (of which there are a large number), an engine maps each construct to a “Java equivalent” which may, or may not, be proprietary to the translator.  What you do in those cases is create at least 2 different source files (possibly 10 times more) for every Forms program unit, trigger, etc. creating a huge mess.  Maybe it works, most likely it will not, but then your stuck with 1 million source files and no way to maintain them.

We put in a lot of effort to try to allow people to clean up and consolidate code in forms applications (we’re the only one’s who do that, BTW) and even build customized classes from existing forms components.  Our last release allows you to do this across different forms applications, creating true enterprise-class applications and services.

There is also discussion about modernizing Forms apps by putting all of the PL/SQL in the form into the database (perhaps the re-surgence of mainframe computing is making it into the distributed database market).  This approach was taken by forward thinking companies in the mid-to-late ’90’s by taking core business rules out of their forms and wrapping them in CRUD procedures in Oracle to thin out the front end.  A good approach back in the client/server days.  In fact, I did that myself with a large annuities application.  But now you have application servers that run real Java; why would you want to isolate your business logic in a single database?  What about sharing that logic with other apps (yes, I know you can do that to some degree in Oracle)?  What about exposure as a web service from different platforms?  And how many PL/SQL programmers can be found to manage really large apps that stuff all of their logic in a database?  In my opinion, fattening the database isn’t a viable architectural solution in this day and age.  If you want to thin-out your front end, that’s great, just don’t dump all of it in the database. 

So, I’ve written this over a vast amount of time, being a poor blogger (Rob may suspend my blogging privileges after this release).  Maybe it’s insightful to you; therapeutic to me.

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!

One of the many features that Oracle got right in JDeveloper is the Oracle Business Component Browser. This little tool is a built-in testing suite for a persistence layer that has been created in ADF BC.

Not only does it provide the ability to perform CRUD operations on the data that your Views are based on, but since some UI elements are influenced by “Hints” on the Model layer, including LOVs and validation, you can test those aspects of your Model as well.

To run it, simply right click on the Application Module that you’d like to test. When the browser starts, all of the views associated with that Application Module will be available to you to run and test. If the view requires a parameter, you will be prompted to provide it.

This is a great little feature that lets you ensure your persistence layer is up to snuff before you start worrying about the presentation. Of course, since we are all excellent programmers here we always unit test anyway, but this way your unit tests are written for you.

We’ve been doing a lot of work here lately with Oracle’s ADF framework. It is a framework based on JSF, though to anyone who asks, I usually tell them that Oracle’s ADF Faces is to JSF just as Oracle Forms is to C. It may be based on JSF, but knowing JSF isn’t going to help you too much.

Before I go on, I should specify. Oracle’s ADF Framework actually consists of a front-end called ADF Faces and a back-end, ADF Business Components. Despite that it is theoretically possible to create ADF based applications in any IDE, if you are using ADF Faces and ADF Business Components, it really doesn’t make sense to not use JDeveloper. The current production release of JDeveloper (and ADF) is 10.1.3, but 10.1.3 doesn’t quite provide everything that we need for the project we are working on, and so we are working with JDeveloper 11g (TP3).

ADF Faces in itself is actually just a set of JSF tags, previous versions of which have been donated to the Apache MyFaces project. The new set of tags which are referred to by the name, ADF Rich Faces provide some great functionality with all sorts of AJAX tricks built-in.

The ADF BC Layer itself is no slouch either. It is another persistence layer and it attempts to tackle some of the more interesting problems that come up when you are in the business of translating client-server applications to web-based applications.  It consists of an Entity layer for objects that need to update the database and a View layer which consists of Views based on Entities or Read-Only views based on SQL queries.

Since the Entity Layer is cached on the server-side, it performs nicely and it allows you implement some long-running transactions that would otherwise be more difficult to implement in a multi-tiered environment.

Of course, all of these benefits don’t come without a cost, but we can talk more about that later.  For now, if you are interested in taking a look at what’s out there that can help you with that next enterprise application you are building, take a look at the latest release of Oracle’s ADF.  Be sure to check out some of the ADF blogs for some  good tips and tutorials.

As you probably saw in Ernt’s earlier post, we exhibited at ODTUG Kaleidoscope this year. It was our first year at the show, but I don’t think it will be our last. To me the show was more valuable than Oracle Open World which we’ve exhibited at for the past 3 years. It may be that as a vendor, exhibiting at OOW is a necessity, but as a developer, exhibiting at the ODTUG show was much better.

What was most encouraging was being able to demo our products to a wide range of people who understood what we were talking about and what our products are trying to achieve. I believe that anyone who believes in code generation as a viable “enhancement’ to custom development should take a look at Rev and see what it can do. I was encouraged to speak to one person who said that he believed we are getting to the point where everything can be done by code generation. I certainly believe that any software project that persists data to a database can benefit from code generation.

Enough about Rev. We had the chance to demo Evo to a number of folks who had some great insight and advice. To me, that was what made the conference such a success. The ability to be able to network with such a great community of people who really want to see a product that can do things right was encouraging.

I had long wanted to speak with Wilfred van der Deijl about his solution to the ADF/Forms integration problem and get his impression on Forms to ADF conversions. At this conference I had the chance to do that. Even though I missed his presentation (the time had changed and I didn’t check the board), he was kind enough to stop by the booth and show it to us personally. It’s a great solution for a problem that we have been asked about many times. If you are into Forms or ADF developement, you should definitely check out his blog. It was nice to see from his blog that he believes we are on the right path.

Peter Ebell over at AMIS in the Netherlands stopped by. If you are into hardcore ADF development, checkout the AMIS blog where Peter is a contributor. Anyway, he stopped by to get a demo of our Forms conversions and hopefully will post his thoughts about it. We talked a lot about Forms Conversions, JHeadstart, and even Whirlyball.

I, unfortunately, did not have the time to attend any of the sessions I wanted to. In each case, when the time for one of those sessions rolled around I was engaged in a product demo or an interesting discussion with one of the attendees. I suppose it’s better to network at these things than sit in on sessions all day, but a nice mix would have been appreciated.

It was a great show and we all had a good time. Though I am not a NASCAR fan in particular, I did get to Daytona USA as guest of Oracle’s at the ODTUG party they held there, and though I was less than impressed, when I stopped by the following day as we were leaving Daytona and got a chance to check out the grandstands with some cars on the track, it was very cool. I don’t think I’ll be watching any NASCAR races on the tube at home, but if I get the chance to attend a race in person, I think I’ll take it. Just the sound of those engines as the cars go screaming by is quite impressive. Not quite as impressive as Evo or Rev, but impressive nonetheless