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.

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>