Skip to main content

Posts

Showing posts from April, 2010

Avoid using DBSequence as the foriegn key in master-details relationship

The reason of why to avoid using DBSequence as the foreign key in the Master-details relationship when you need to post the data into the database. A user case for this scenario: you have two tables: User and UserGrant tables. User table has columns related to user info: user_id, user_name, user_password, user_address, etc. UserGrant has columns related to user and group info: grant_id, role_id, user_id, etc. User is the master table and has the primary key user_Id as a DBSequence. The user_id is also a foreign key in UserGrant table. You create VO based on the entities that based on the two tables, and drag the UserVO to the ADF page to create a new row. When a new role (which means a new user) created in UserEO, you want a new role (which means a new grant: a new user with a role) to be created the same time in UserGrantEO. The issue rises because the posting order of the two entity objects. This is because when a new role is created (before posting data and commit), the DBSequence

Create Data in ADF

Suppose you have to handle a process of user registration in ADF fusion application. Then you will have the page for user to put their user info (user name, user password, and other personal info) into your database. So to implement the process of create data in ADF, you need to do the following: 1. create entity objects for the database tables. 2. create view objects for the data objects that will be handled with user interaction. 3. expose the VO to AM and we need to write some custom codes in AMImpl java file we will use later. The method is about to create a new row in the VO. Expose this method after creation. For example: public void simpleRegistrationCreate(String userType, Number assignedBy, String userRole) { ViewObject userVO = this.getWebUserVO(); Row currRow = userVO.createRow(); currRow.setAttribute("UserType", userType); currRow.setAttribute("AssignedBy", assignedBy); currRow.setAttribute("UserRole", userRole); userVO.insertRow(currRow)

ADF Business Validation: password have to match confirm password.

There are many business validations we need to handle in ADF. Most of them are done at the attribute level. But one of them: password/email have to match confirm password/email scenoria has to be done via entity level. This can also be done not using the business level validation instead by using UI handling. Here is code example:

Create or CreateInsert

Taken from Jdeveloper 11g handbook: Create or CreateInsert? The two different create operations provided by ADF, Create and CreateInsert, can be a little confusing because they seem to accomplish the same task. The row created by the Create operation is managed as a temporary object by the framework. If the user abandons an input screen without submitting the new record, the row will simply disappear, leaving the programmer with no clean-up to do. CreateInsert, however, requires clean-up. Although the Create behavior is generally more useful, there are still some circumstances where CreateInsert should be used. Typically, this will be when the side effects of entity object creation are desirable. For example, the create method on the entity object adds information defined as defaults for attributes such as dates and reference numbers. With CreateInsert, this default information will be visible to the user on the created (blank) record. If the Create operation is used, the

Dynamic Tab Functionality

I followed a recent blog from Andrejus Baranovskis on a Dynamic Tab Functionality . Actually this functionality is very similar to Dynamic Region Functionality. An example of dynamic region can be found here . To summarize how to implement dynamic region functionality: 1. create several bounded task flows that you wish to be a member of the dynamic region. 2. drag the task flow you wish to be displayed by default into the region on a JSF page, and choose "dynamic region" tag, you will be asked to set a bean to handle the regions switch. 3. drag the other task flow to the region you want to control the region switch (like the navigation panel), and choose "dynamic link" and choose the dynamic region you created in step 2 (the name is "dynamicRegion1" by default). Jdeveloper will create the codes in the bean to handle the region switch when you hit any of the command links you created in this step. For Dynamic Tab Functionality, the steps are: 1.