Java Hair

The 11g release of JDeveloper includes a utility to perform code audits without having to install additional plugins. While the information it provides out of the box is minimal, for some violations you can also ask JDeveloper to fix the code automatically.

The metrics it provides:

NOS: Number of Statements in the construct.
V(G): Cyclomatic Complexity, a metric that captures the number of branches that can be taken through a method.
DIT: Depth of Inheritance Tree, this metric describes how far a class is from it’s furthest ancestor, or really, how many classes has it inherited from.

You can run audit reports on your projects pretty easily.
1. Select the project node in the Application Navigator.

Select the Project to Audit

2. Select Run from the main menu bar.

3. Select Audit Project.jpr

4. Choose All Metrics

View Audit Reports in JDeveloper

5. View the report in the log window

You can also run audit reports on rules violations. You can easily modify which rules you would like to include and which you wouldn’t along with which available metrics you’d like to include.

Change the Rules to Audit in JDeveloper

A couple things to keep in mind as you view the metrics:

1. The V(G) of RowImpl classes is going to be high because of the case statement within the getAttrInvokeAccessor method. This is normal for ADF.

2. The DIT is going to be above the default threshold for some of your Impl classes also, for instance, any Application Module Implementation. This is the class you need to extend is already so far down in the chain.

There are only a couple metrics that can be run from the audit tool built into JDeveloper and I’m sure there are ways to integrate other code auditing tools in JDev, but at least it’s a start.

One tool I was hoping to see which I imagine is a long way off is some type of auditing tool for ADF itself.  Since so much of it is declarative and new, no existing tools are going to work on it, but it’d be nice to be able to audit the declaritive part of ADF projects for best practices.

I am going to be at OOW this year, as usual, and this time I will be presenting my talk on using ADF 11g as a platform for Oracle Form conversions.

My presentation outlines the use of 11g ADF Faces, ADF Business Components and JDeveloper as a target platform for applications that were previously written in Oracle Forms. The 11g version of ADF contains many new features that make it a much better framework for such conversions than others. These include the use of Task Flows and richer JSF components. . 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 and what difficulties still remain.

I signed up for the Unconference early to reserver a spot, so right now it is scheduled for 11am on Tuesday morning in Overlook I. Hopefully when I get there to sign up, the slot will still be available, stop by the booth before then if you are interested in attending or check the schedule that will be posted there.

If you are going to be there, be sure to stop by!

Be sure to check out the rest of the Unconference Schedule.

One of the cool features of the ADF Business Components layer in 11g is the ability to add custom properties to Entity or View objects. It’s a neat feataure but up until this point I hadn’t really any need to use them.

Then, when I was trying to implement a View object as only allowing updates, not inserts or deletes, I learned that there isn’t really a way to declaritively do this in ADF 11g. It seemed like one of those things that should be available, but the help says this:
“Some 4GL tools like Oracle Forms provide declarative properties that control whether a given data collection allows inserts, updates, or deletes. While the view object does not yet support this as a built-in feature in the current release, it’s easy to add this facility using a framework extension class that exploits custom metadata properties as the developer-supplied flags to control insert, update, or delete on a view object.”

The above quote is from section 37.11 of the Fusion Developer’s Guide for Oracle ADF. The section is actually titled “Declaratively Preventing Insert, Update, and Delete” which sounded like exactly what I wanted, but when i read the section I found that little bit of discouraging news. The last few words were encouraging, I thought using custom proerties to control insert, update, or deletes would be perfect, then I read on.

The next couple paragraphs seem to indicate that it would be a good idea to create instances of the view object that are called ViewObjectInsert, ViewObjectUpdate, and ViewObjectDelete, generic framework code could be used to look for these View instances and based on if a custom property is set then blah, blah, blah. I think it actually said something about looking up the phase of the moon also.

I’m not sure why you would want to have custom instances to determine whether or not customer properties should be looked up or not, why not just use custom properties? Anyway, that is the route I decided to take and it turned out to be pretty simple.

Chirs Muir had written an article on using custom properties to automatically convert the case of input and I used his article along with the help section of the Fusion Developer’s guide to come up with this solution. Thanks Chris!

1. Create a custom ViewObject implementation class.
This is done by creating a class that extends the Oracle View Object.

Create a New Java Class

1a. Right click on the package you would like your custom class to reside in.
1b. Click on Simple File in the left pane and Java Class on the right pane.
1c. Name the file and make sure it extends the ViewObjectImpl class.

2. Create a method to check the custom property.

     private boolean isAllowed(String action) {
         boolean result = true;
         if (getViewDef() != null) {
             if (getViewDef().getProperty(action) != null) {
                String actionProperty = (String) getViewDef().getProperty(action);
                if (actionProperty != null) {
                    if ("false".equals(actionProperty)) {
                        result = false;
                    }
                }
             }
         }
         return result;
     }

3. Override the appropriate methods.
3a. Override the createRow method to check if Create is allowed, and if it isn’t throw an exception.

    public Row createRow() {
        if (isAllowed("insert")) {
            return super.createRow();
         } else {
            throw new JboException("Create not allowed in this view");
         }
    }

3b. Override the removeCurrentRow method in the same way.

    public void removeCurrentRow() {
        if (isAllowed("delete")) {
             super.remove();
         } else {
            throw new JboException("Delete not allowed in this view");
         }
    }

4. Add the necessary declarations to the View Object you wish to have these features.
4a. Add the following line to the attributes of the View Object to have it implement the framework class.

	ComponentClass="com.vgo.demo.framework.MyCustomViewObjectImpl"

Add Custom View Properties

4b. Add the necessary custom properties to the View Ojbect. Click on the General section of the Overview tab of the view object. Open the section for Custom Properties and click the green plus. Change the name to “insert” and the value to “false”. Click on the green plus to add another cusom property, name this one “delete” and set the value to “false”.

5. That’s it, it is that simple. Now run an Application Module that contains that View and try to insert or delete, when you do, you should see the exception that is thrown to inform the user that the action is not permitted.

Error Message for Insert Shown

As you can see, custom properties in ADF 11g are sure to prove extremely useful in the future, I am sure this is but one potential use for them.

Conditional breakpoints are a great way to reduce debugging time and one of those features you might not even have known existed. This article will cover how to use them in 3 different ide’s including NetBeans, Eclipse and JDeveloper.

Have you ever tried to debug a problem that only occurs somewhere in a list of 100 objects? It can be a bit of a hassle.

You could put in a breakpoint and hit continue each time that breakpoint is hit until you find the problem object. This is acceptable the first time, but often the first time isn’t going to cut it.

You could put an if statement in your code to check for the condition that is causing the problem, but then you need to remember to remove that if statement after you fix the problem. Often my if statements in the past would have looked like this:

i f (problem.exists()) {

System.out.println(”This is the problem.”);

}

And I’d set a breakpoint on the System.out.println line.

A much better approach is to make use of conditional breakpoints available in most modern IDE’s.

In NetBeans, create a breakpoint, the right click on the little pink square that signifies the break. Click on “Customize”. When the customize dialog comes up, check “Condition” and fill in the condition. Above is an example of this dialog in NetBeans.

To accomplish the same thing in Eclipse, create your breakpoint, then right-click on the little blue dot signifying the breakpoint and choose “Breakpoint Properties”. In the Properties window, check “Enable Condition” and then fill in your condition or conditions in the box provided. An example is shown above.

Finally, to accomplish the same in JDeveloper (TP4, anyway), set your breakpoint, right click on the little red circle that appears. Then click on “Edit Breakpoint” and in the dialog that pops up, move to the “Conditions” tab. You can set your conditions there as shown in the picture above.

So now that you know, from now on, no more useless breakpoints!

And if you’ve still been debugging using System.out’s, I’m sorry I wasted your time. I’m sure Vi is just sitting there flashing it’s cursor at you waiting for you to save those changes.

The talk I presented at ODTUG this year went over very well with the people who attended, but unfortunately, there were not all that many in attendance.  Since I missed the deadline for the normal submissions to Oracle Open World this year, I submitted by talk to Oracle Mix’s session submission area.  As one person put it, Oracle Mix is pretty much facebook for people working with Oracle technologies.

Anyway, you can vote to see my session at Open World by clicking here.  I promise you that my presentation is not a vendor presentation, I don’t talk at all about Vgo Software or the tool(s) that we make that make the process of modernizing forms easier.  What I do talk about is how ADF 11g allows you to rewrite Oracle Forms applications in a web environment and some of the pitfalls you will run into when you try to do this.

The presentation also includes a demonstration of creating a Master-Detail page in ADF 11g, much like some of my previous blog-posts.  It is after all, one of the cornerstones of an Oracle Forms application.

This tutorial explains how to add some useful functionality to the Master-detail page we created in the last tutorial. The first thing you will need to do in order to follow along is to follow the steps in that post.

Today we will add some functionality to allow the user to add, edit, and delete employee records from the detail table.

1. Adding Read-Only Views

1a. Before we get started with the view, let’s add a couple of ADF Business Components to our Model layer. We are going to want to create a couple of drop down lists, so to do that, we need a Read Only view that can populate the drop down list.

1b. Right-click the Model project, choose New, then choose ADF Business Components from Tables.

1c. Do not choose to create any Entity objects since we have the two we already need from last time. Same deal with Updateable Views, so click Next on both of those screens.

1d.On Step 3 of the “Create Business Components from Tables” wizard, select Employees and Locations and choose to create Read-Only Views for those two tables. Rename the new Employee View to ManagerView.

2. Adding “List of Values”

2a. Open the EmployeView in the Model project. Click on the ManagerId attribute.

2b. Underneath, on the toolbar that says “List of Value” click the green plus-sign to open the List of Values wizard. Click the green plus and choose the ManagerView from the left-hand list of available view and move it to the right-side list of View Accessors. Click OK.

2c. In the top pane, open the ManagerView and click on EmployeeId, then click the green plus underneath the “List Data Source” pane. JDeveloper should add ManagerId under View Attribute and EmployeeId under List Attribute which means it is linking the managerid in the EmployeeView to the EmployeeId in the ManagerView.

2d. Click on the UI Hints tab and choose “Choice List”.

2e. Repeat the steps to create a “List of Values” for Department using the Departments view.

3. Create an Edit Page

3a. Make an Edit page for Employees. Create a new JSF JSP page in the ViewController project. Let’s name this page employeeEdit.jspx. If you feel like it, drag a panelHeader onto the page and change the label to “Employee Edit”.

3b. Open the AppModuleDataControl under the Data Controls pane on the left-hand side of JDeveloper. Open the DepartmentsView1 node and drag EmployeesView3 onto the panelHeader in your jspx page.

3c. The ManagerId and DepartmentId fields should show that the component is a choice list based on the UI Hint we provided to the View. You can change it here, but you do not have the option here to change it to a popup List of Values, to do that, you must change it back in the UI Hints on the View. Click on “Include Submit Button” and click “OK”.

4. Create a Task Flow

4a. Let’s create our first Task Flow. To do this, right-click on the View project and select New. From the menu, select Web Tier -> JSF on the right side of the wizard and ADF Task Flow on the left.

4b. Name the task flow masterDetail-task-flow-definition.xml. Make sure you don’t have “Create with Page Fragments” checked and click OK.

4c. In the properties of the task flow, on the behavior tab, set the data-control-scope to “isolated”. In TP4 it is set to “shared” by default and would therefore require a parent task flow.

4d. Drag a “View” component from the ADF Task Flow component toolbar onto the Task Flow design sreen. Name this View “masterDetail”. In the properties panel, set it’s page property to the masterDetail.jspx page.

4e. Drag another “View” component, set it’s name to “employeeEdit” and set the page property to the employeeEdit.jspx page you just created.

4f. Drag a “Control Flow Case” component and drop it onto the masterDetail View object. Then drag it over to the employeEdit View object. Name the Control Flow Case “edit”.

4g. Create a Control Flow Case going from employeeEdit to masterDetail and name it “return”.

4h. Back on the emoplyeeEdit.jspx page set the action for submit to “return”.

5. Getting it to actually Do Something

5a. To make the components lay out nicely, drag a panelGroup layout component over in between the department table and the employee table. Then drag the employee table into the panel group.

5b. Add a button to the panel group. Change the label on the button to “Edit”. Set the action to “edit”. Notice that the name you had provided in the Control Flow Case is available for use as an action for the button. This is a beautiful thing.

5c. Add Commit and Rollback buttons to the page by dragging them from the AppModuleDataControl.

6. Play With It!

You now have added a seperate edit page to the application, hooked it up using a task flow, and rolled all of it into one transaction, all without writing a single line of Java code. If you are a Java developer, you may be wondering what’s going on under the covers and I encourage you to dig in and find out! You’ll especially want to understand how task flows work and how the transactions are managed.

Anyway, I’ll leave as a next step for the student to add a create button.

I haven’t posted much in the last couple weeks, too much traveling, most of it business unfortunately.  Anyway, this is a quick update to be followed up with a more interesting how to article involved JDeveloper and ADF.  I hope to get that posted by the end of the week.

ODTUG is coming up in just one week.  It is being held in New Orleans this year, and if you get there early on Saturday you can be one of the many volunteers to help with reconstruction by, I believe, building a home.

I will be there from Saturday until Thursday.  My presentation is on Tuesday, June 17th, from 12:45 to 1:45 and is titled “Using ADF 11g as  Platform for Oracle Client/Server Forms Conversions.”

I hope to see you there!

On another note, Andrejus Baranovskis, an Oracle ACE director who works for Vgo Software and will also be presenting at ODTUG this year, has created a place to discuss all things regarding Oracle Form’s Modernization. You can find it here.  It is part of the Oracle Mix site, so you will need an account there.

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.

My last post about frameworks criticized the Spring JDBC Template construct. I don’t really have anything against Spring in particular, I had just stumbled across the JDBC Template a few days earlier and thought it may help make my point. My point, which I attempted to illustrate by that post, was not that the Spring JDBC Template is useless, it is that frameworks in general, which exist to simplify development of complex technologies, by their nature redirect that complexity somewhere else. Hopefully that new complexity is less than the underlying technology and this is often the case. As an architect/designer/developer you should be aware of that the trade-off exists, what the trade off is going to be and make an informed decision.

1.  Configuration Files

Since I used Spring as an example once before, let’s move on to another one of my other favorite frameworks, Struts. Struts has seemed to have fallen out of favor of late, with many developers now hopping on the JSF bandwagon, including our shop. I had to basically be dragged away from it and forced into JSF. However, even though Struts was my framework of choice for years, it had some problems that really bugged me and are issues that still exist today in many frameworks.

One of the nice things about Java is that you can use a smart IDE and it will spot a lot of careless errors for you, especially simple typos. This is important for someone like me who likes to type fast and can tend to be somewhat careless. What I found with Struts is that I often had problems first setting up projects. For some reason I would always end up with a typo in the struts-config.xml file that would cause it to break when starting my application. Struts was never very good at letting me know what the exact problem was and this never ceased to infuriate me, so much so in fact, that one of our products, Rev, was born out of that frustration because it insured that I wouldn’t have to worry about typos impeding my ability to get an application up and running quickly. I continued to use Struts because it’s benefits outweighed it’s difficulties, it didn’t abstract too much of the HTTP layer so I could still understand what was going on pretty easily.

2.  Too much abstraction

Next, for me, came JSF. I actually only started using it because a project we were working on required a technology that was built upon JSF. Once I started using it, I could appreciate how it’s abstraction of the HTTP layer really made things easier for developers, especially for newbies who didn’t really know much about the HTTP layer. All of this abstraction, however, made it difficult to understand what was happening underneath the covers or exactly how it was happening. Some of the simple Javascript patterns I had been using in Struts to solve some common problems became more difficult. Have you ever looked at the source HTML to a JSF-backed page? It’s not nearly as simple and straight-forward as a page developed from Struts. I am still uncomfortable with the fact that I don’t know exactly how to create a request in JSF to accomplish some things seemingly trivial things, whereas the same things in Struts were really easy.

The other problem that I found as we continued to use the framework was that I could have developers who understood JSF and worked in it really well, but they didn’t understand some of the underlying concepts. When something unexpected happened, they weren’t sure where to look. This would occur when a developer’s first experience with developing web applications was with JSF.

That same problem occurs with any framework, since by their nature they abstract the complexity of some underlying technology. This is all well and good until things break. Obviously, Java itself is an abstraction of underlying technology, do I think we’d all be better off going back to assembly language and programming web applications in that? Of course not, but I think as a developer you should be aware of the pro’s and con’s of the frameworks you use.

You should also take it upon yourself to learn something of the underlying technologies so you aren’t completely clueless. I have interviewed plenty of so-called JSP developers who couldn’t tell me what pieces of code were executed on the server and which on the client, who didn’t understand the underlying concept that once your page was executing in the browser, you weren’t able to execute java commands inside a function in a page. I could understand how a newbie might have some problems with that, but an “experienced” JSP programmer?

3.  The Problem with Fixing #1 and #2

Often, with frameworks that become popular, it’s because the abstraction they provide is more useful than the underlying technology by itself and any new complexities it may introduce, it allows developers to become more productive, hopefully much more productive.

In my opinion, Oracle’s new version of ADF, 11g, is a framework that does just that, but it isn’t without it’s share of compexities either. ADF 11g makes a lot of building a web application declaritive. This may be a good thing, but again, you run into the problem of having to deal with many XML files. Oracle alleviated this problem to a very large degree by creating JDeveloper 11g which can handle building and validating the XML files for you. However, now we have a new problem. There are some mismatches between JDeveloper 11g and ADF 11g. In some cases, just because JDeveloper tells you something is wrong doesn’t mean it is wrong and won’t work. This hints at a larger problem: that both JDeveloper and ADF need to be maintained and released on the same cycles. If one falls behind in respect to changes that were made to the other, the usefulness of the collaboration between the two is degraded.

Also, again in ADF 11g, there is a larger issue. That is, if something acts in an unexpected manner, the developer now needs to understand an additional layer of complexity in order to debug the problem. Often the developer will need to resort to asking the experts via a forum or a bug report. Even if the product is open source and the developer could access the code itself, finding and fixing a problem deep within the framework will obviously detract from the usefulness of the framework itself.

None of these “dark sides”of frameworks are reasons not to use them, I use or have-used all of them, these are just issues that you should be aware of and investigate before using a framework. My “issues” (some may describe these as pet peeves) can be distilled into two main items, 1. Increased abstraction often leads to less understanding and 2. Declarative programming creates its own problems.

Obviously we are going the way of more abstraction, not less.  It will be  a great day when we no longer have to worry about the framework we are using breaking and exposing us to the dirty underbelly of technology behind it all.

</rant>

I have always fallen on the practical side of technical architecture. I think it is because I started my professional life as a developer and have evolved into more of an architectural role on the projects I work on. I have worked with many architects over the years, though, I’m not sure where their background lies as most of them seem to fall more on the theoretical side of the fence.  It isn’t too often I run across a so-called architect who has the practical side of software down also.

These theory architects are good at writing documents and drawing pictures, and they even have some really great ideas. The downside of these theoretical architects have, is that though they tend to do a lot of research and generally know what all the best practices are, they don’t generally get down and dirty with the tool set and thus don’t know what the real or potential problems are with some of the practices that they suggest.  If there isn’t someone involved in the design who is fluent in the toolset, you could waste a lot of time trying to implement something that isn’t going to work or even just making a lot of small changes that aren’t going to matter in the overall scheme of things.

Regarding this point, I was involved in an interesting conversation with a technical architect on a client’s project recently. This architect is a great guy and in general I respect his opinions and suggestions much more than I generally do when dealing with architect types. However, this time, his tendency to constantly push theoretical best practices over practical approaches was apparent to me and even the client.

In creating an ADF BC layer in JDeveloper, a developer will typically, no always, use the wizard included in JDevleoper (unless, of course, they are using Evo). The way the BC layer is defined, various Entities xml files are created from tables in the database and views are built from those entities. Finally, in what is called an Application Module, the Views are used by defining instances of those views for use in the module. Since these view instances are generated automatically, each view instance has a number appended to it to make it unique. Makes sense, right?

Well, this architect said that it was a “best practice” rename those instance variables into something more meaningful. Now while I agree that it may be nice to rename some of those instance vairables to be something more meaningful, is it really practical, and thus is it really a “best practice” or is it just a good idea?

I interjected that though it may be a good idea, it hardly seemed practical, afterall, if JDeveloper automatically generates the instance names, don’t you lose some of the benefit of the automatic generation when you need to go back and rename all of those instances? At this point, the client joined in the converstation and asked if he had used this best practice in the past.

The architect replied that it is always a best practice to rename files or variables such as those so that the names have meaning. The client asked again, “yes, but do people actually do that in a project? Have you worked on a project in which that was done?”

The architect, much to my surprise, replied with, “well, to tell you the truth, I have never actually seen it done.” I actually had to laugh a little bit. It was actually refreshing to hear an architect say that though something was theoretically a best practice, in reality, it wasn’t done because it wasn’t practical. In a lot of organizations, practicality often loses out to so-called “best practices” many a time. The funny thing was, that in this project, it actually made sense to name our view instances as he suggested, but only because the tool we were using, Evo, would be automatically generating the instance names.

Maybe this article was just an excuse to print one of my favorite Yogi Berra quotes, “In theory, there is no difference between theory and practice. In practice, there is.”