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.

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.

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.

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!

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.

1. SQL and more (PL/SQL, Transact-SQL etc.)

Learn to write a query in standard SQL. If you are a developer, especially these days, all of that crazy SQL code may be masked by some sort of ORM layer, but if you have the opportunity or can make the opportunity, learn some SQL. It comes in handy when you are unit testing your persistence layer or trying to find test cases that meet certain criteria. I know you are a developer, but you may be asked to do these things every once in a while.

2. Database Administration

Learn enough database administration to be able to set up a development instance of a database on your own machine. Know how to create indexes and constraints. You can get copies of virtually any database for development purposes legally and for free, so do so and learn the basics.

3. Linux or Unix

Download a few distributions of Linux or if you have access to Unix systems, use that access to learn a few things. Learn how to get around in the file system. Learn how to change permissions on files, do searches, download and install packages and if you are brave enough, learn how to compile some downloaded source code.

Learn a shell scripting language and gain at least a cursory knowledge of grep, awk, and vi.

4. Perl / PHP / Python

If you are developing Web applications in one of these languages already, then ignore this, you already know it (obviously). If you are a Java developer, keep reading.

Learn one of the P’s. Sometimes you come accross things that are much easier done in a script and may be possible in a shell script, but lots of times these things are easier in a language like Perl, PHP, or Python. If you get really brave, build a simple website in one of the P’s, probably not Perl.

5. TCP/IP

Learn what TCP/IP is. Learn how the internet works. Know what DNS stands for. Basically learn enough so that if you get a new laptop you aren’t pestering the system admins for the first few hours because you can’t connect to the internet.

6. HTML/CSS

Often times you will need to do some basic styling on your pages. Make sure you can read HTML source code (and who can’t these days? Even my cat has a blog) . Know some CSS, nobody is asking application developers to be web designers, but being able to make some simple changes to make your application look good is nice knowledge to have.

7. Javascript

Every non-trivial web application is going to require some javascripting and don’t expect an HTML-wizard to be able to help you out. Most of the time the javascript you’ll need to know is outside of their experience. With JSF frameworks and tools like ADF and JDeveloper, the amount of Javascript you’ll need is less and less with every release, but at some point you will find the need. Plus once you’ve learned Html/CSS and Javascript, think what you could do to your Facebook page

8. Troubleshooting

I think what might be the point of all this is that as a web application developer, many, many things can go wrong. Applications aren’t all built in C anymore, they consist of Javascript / HTML / CSS / Some-server-side-language-of-choice / Probably an Application Server or HTTP Server / SQL / and a database. If your page isn’t displaying, you need to know if it is because you have an error in one of your components or if your query didn’t return any data.

If you don’t have the opportunity to learn such things on the job, then find a cheap machine in a junk pile somewhere, install a linux distro on it along with a database, the Apache web server, and a decent version of Perl and go nuts. I am always disappointed if I ask a potential candidate if they have Linux installed on a machine at home and they say no. If they say yes, it’s a plus, if they say yes and it is installed on their Wii, then I hire them on the spot.

That’s my list. What types of things do you feel a Web Application Developer needs to know these days?

About a year ago I learned of a guy who records under the nom de plume of Girl Talk. He is really a DJ and Mash-Up artist and not so much a singer/songwriter or a musician but in some cases he makes some great music just the same.

Though his latest album is a masterpiece, some of his earlier stuff is pretty bad. “Secret Diary” from 2002 is difficult for me to listen to. If you want to hear something really awful or feel like punishing your cube-mates, blast some of that, really it doesn’t matter which song.

With “Secret Diary” and on into “Unstoppable” you can see the seeds of what eventually became “Nightripper” which he released in 2006. With “Nightripper”, Greg Gillis aka Girl Talk combined all of those great samples he must have catologued in that head of his into something musical. With the first album, he had some great samples but wasn’t really sure how to put them together musically and instead strung them together with lots of noise, a lot of times sounding like someone was turning a radio dial, and sometimes sounding like someone running their nails across a chalkboard. Like I said earlier, this one can be painful to take.

On the other hand, if you want to listen to an example of what Mash-Up artistry really is take a listen to “Night Ripper”. This album combines riffs and samples from a huge variety of songs, from Elton John and Cyndi Lauper to 2 Live Crew and Eminem, into one cohesive collection of actual musical noise. In my opinion it is really a work of genius that can only be fully explained by listening to it. In this album he takes all those great samples and instead of putting them together with random noise, incorporates them into actual songs. I’m pretty sure I said that he wasn’t a musician, but anyone who can write songs like this has got to be classified as a musician, don’t you think?

Steve Muench’s blog has a post with tips and tricks for ADF 11g and one section is devoted to the use of Groovy script in ADF. In it he makes mention of some of the more useful keywords and names available to you via Groovy expressions in ADF.

Some useful expressions:

#{securityContext.userName} : Get the user’s name from the Security Context

#{bindings.permissionInfo[’PageAPageDef’].allowsView} : Determine if a user has permission to view a page

#{controllerContext.currentViewPort.exceptionData.message} : Display the message from the current exception.

There is also a handy expression builder that can be brought up wherever you can input an expression as an argument to a property.

Additional information on the Groovy scripting language can be found on the Groovy homepage.

What isn’t great is what you need to do to actually determine which table is selected on the page all because of a quirk in the selection event on the table itself. It seems the selection listener only gets called when the selection in the table changes. So, if you select row 1 from table A, then select row 2 from table B, if you go back and select row 1 from table A again, the selection listener doesn’t get called because it was the same row that was originally selected. This makes it more challeging than simply adding code to the selection listener.

To keep track of the table that is selected, I elected to create a hidden input variable on the page, and then a javascript function that updated that variable with a parameter that is passed in. That function is then called by the selection listener.

The javascript funtion looks like this:

function tableClicked(var value) {
var selected = document.getElementById(”selectionMade”);
selected.value = value;
}

The hidden input value on the page is then tied to a backing bean. The method that needs to make a decision based on which table is selected simply checks the selectionMade value of the backing bean.

In order to get the table to call the javascript function, go to the source of the JSP file and add the following:

<af:clientListener method=”tableClicked(’tab1′)” type=”click”/>

One thing to look out for is that this particular way of doing things will not work if you want to check the value of the backing bean from an action that is performed with imediate=”true”.

1. Simply put in the JDBC connection information for the database

2. Check off the tables you wish to generate code for in your desired schema.

3. Go to the mapping tab and add or remove relationships between the tables (if you have foreign keys defined in your database, they will appear automatically).

4. Change any field names you’d like in that screen.

5. Go to the Constructor tab.

6. Choose the type of output you’d like, various Java flavors or even a PHP application.

7. Fill in the project options. If you have a supported application sserver, be sure to check off the deploy target as default.

8. Click the ANT button to build your project and deploy it (if applicable).

That’s it, you have successfully generated a fully working CRUD application in the flavor of your choice. Rev has left you with all of the source code so if you like working by example, you can take this fully functioning example and start adding to it right away.

There is a more detailed walk-through that can be found at the Vgo Software site.

It is a product that has a price tag, but it’s low, and you can get a free 15 day trial download from Vgo Software.

Please, give it a try, and send us your feedback, we are always looking for ways to improve the product.