Tuesday, January 29, 2008

ADF - Using Proxy Authentication

An interesting article has appeared on JHeadstart's Blog that outlines the approach to use if you currently have an application that uses database login credentials to define authentication and access. Once you move to a web application, database connections are channeled through a connection pool that consists of one pre-defined login user.

Using proxy authentication allows you to maintain the user details of logged-in users. This article steps through the options available when this approach is needed.

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.

Friday, January 18, 2008

Forms Lingo translated to JDeveloper using ADF (Part 1)

Oracle Forms packages a lot of functionality up for us so that we don't have to worry too much about things like data binding.
Creating an application using ADF in JDeveloper requires us to do a lot of thinking that was previously done for us by Forms, but also attempts to provide us with some flexibility.

In Forms, we usually create a Forms Module by firstly determining the base table/view that we are going to use, then creating a block based on one or more of those tables/views.
In JDeveloper, this process is more involved, as its inherent flexibility allows you to define the tables/views you are going to use, as well as specifying whether you want to allow that data to be read-only or updateable. Specifying this accessibility level early on allows you to restrict the data access methods that are auto-generated later. The application construction methods used by JDeveloper aid in using a bottom-up approach to development. The developer is made to think about the transactions that are to be involved in the module, and apply specific coding style to the development of each screen depending on the final required functionality, as well as being given the flexibility of changing the entire approach if more functionality is later required.

In Forms, once a base table block is set up, you have control over the fields that are to be returned and populated from the query, as well as the physical layout characteristics of those fields. This concept is slightly separated in JDeveloper. At the point where you specify the query (or queries) that you are going to use within the app, you only have control over the suggested physical labelling of the returned fields at that time. The other physical characteristics are handled in the View component. Because ADF development promotes the separation of the visual aspects from the business logic components, its development is split up into what is referred to as MVC - the Model/View/Controller. The Model component takes care of the data model and its relationship structure(s). The View components take care of how the user interface is presented. The Controller components hold the events and actions that interaction with the View components have on the Model components, such as pressing button, or clicking a link.

MVC terminology can be translated into Forms components. The Model is the underlying database tables (or stored procedures or dynamic SQL statements, etc) on which you base your blocks. The View is the physical canvas layout of your Forms Items - all of the UI components such as items, tabs, buttons, trees, drop-down lists etc. The Controller is all of the triggers and program units that translate events and user actions into business logic - as well as the Forms built-ins that control the flow of triggers.