Tuesday, January 29, 2008

JDeveloper Training

We had Chris Muir come in to give us a 5-day JDeveloper/ADF run-down. Our class of 12 were all extremely impressed with the presentation and we have all come away with a vast amount of new knowledge and respect for the new techniques we can employ.

In regards to the viewpoint of some Forms developers, I can see there will be some points of confusion when undertaking development in JDeveloper using ADF Business Components.

For example, when creating Entity Objects we are basically abstracting the database columns as attributes of a java class.
Then, when we create a View Object, those attributes are used to define what is displayed. However, if we want to filter or join 2 entity objects in the view object, we have to return to the database field definition (basically add a WHERE clause to join them).

The reason for this is that a VO can be based directly on database tables and fields without referring to any EOs. So, that is something that people switching between Relational and Object-Oriented related thinking must bear in mind.

There is also the learning curve of Java programming, but I guess this is just something that has to be done. In Forms development, it is easy to put together a Forms module that provides easy access to any database table and provide Enter- and Execute-Query functionality without any PL/SQL coding whatsoever. The same is true for JDeveloper programming - it seems easy enough to put together a basic web application that will give access to any particular table and automatically provide the tools and code to allow a page with that same Enter- and Execute-Query-like functionality.

However, everyone knows that sooner or later (probably sooner), you are going to have to enforce some particularly complicated business rules and calculations that lead to complex navgation rules. As with Forms, where you will have to code up some PL/SQL either in the Form (or PLL) or within the database, the same holds true for JDeveloper. Somewhere along the line you will realize that the simple Enter-Execute methods are not enough, and you will need to place some Java code in a backing bean.

We will be attending an APEX course in a couple of weeks, and I'm sure the same concept will be shown again - all the simple stuff will be visually appealing, of course. But, as soon as some complex algorithms need to be referenced, we will be forced to use Javascript to twist the simple concepts into something that works the way the users want it.

2 comments:

The Peaceful Programmer said...

Thanks so much for your posting and the new blog venture. Myself and my coworkers are hoping that you keep at it and share what you're experiencing as we are in the same boat. If we find any answers or alternatives, we'll be sure to post back.

But great news. This conversion to ADF isn't necessarily smooth all the way through, and it's always good to get the information out there.

Marc Thompson said...

We are looking at an 'upgrade, integrate, migrate' approach. We have upgraded all of our Forms to 10g, and the database to 10g. So, now we are into the 'integrate' stage, we will incorporate new development using new tools (JDev, etc) into the existing Forms app. When we are comforable with that, then the migration of old Forms to a new technology will start...
Ah, the joys!