Wednesday Feb 29, 2012

Oracle JHeadstart 11.1.1.4 Now Available

Oracle JHeadstart 11.1.1.4 is now available for download (build 11.1.1.4.26).
See the support matrix for supported JDeveloper releases.
Customers who own a JHeadstart supplement option license can download it from the Consulting Supplement Option portal.

This release is mainly a bug fix release. In addition, some small small enhancements have been added: 

  • Enhanced Support for Dynamic Tabs: The implementation of dynamic tabs has been changed and enhanced. There is no longer a dependency on the standard oracle uishell dynamic tabs implementation. A new oracle.jheadstart.view.dyntab.DyntabContext class is now used instead of the oracle.ui.pattern.dynamicShell.TabContext class that supports additional features like updating the document title based on the current tab, setting the maximum number of tabs, and displaying initial tabs.
  • Enhanced Support for Function Keys: New function keys have been added for first row, previous row, next row, and last row, and go to details. In addition when changing a page fragment or tab within a page fragment, the cursor focus will be set on the first item.
  • Control over Generated Value Bindings: At the service level, two new properties have been added. The property Always Generate Form Value Bindings controls whether individual attributeValues bindings are generated for a group that does not have form layout. The property Generate Value Bindings for Hidden Items controls whether a value binding is generated whe the item is hidden. To ensure upwards compatibility the default value of both properties is true, however, if you create a new service definition, both properies are set to false. If one or both if these service-level properties are set to false, you can still force generation of an individual value binding using the two new item properties Generate Form Value Binding and Generate Table Value Binding. Both these new service properties, and new item properties are only visible in advanced mode in the Application Definition Editor.
  • Enhanced Implementation of Dependent Items: In previous releases, dependent items were refreshed using the partialTriggers property. This caused the dependent items to be validated as well as part of the optimized lifecycle, forcing usage of showRequired property rather than the required property to prevent premature client-side validations. In this release, the dependent items are refreshed programtically by adding them as partial target inside the DependsOnItem bean. This means all items can have client-side validations as desired.
  • Enhanced Implementation of Display New Row on Entry: The check whether a new row must be displayed is now performed inside the task flow itself, instead of in the calling task flow. This allows for a proper implementation of the "when no rows found" option in this property.
  • Enhanced Implementation of JHeadstart LOV's: The JHeadstart web-tier LOV implementation has been completely rewritten. The new implementation uses one generic LOV popup per page, with one associated generic LOV task flow binding and one genwric LOV Task flow manager bean. LOV for validation has been implemented using a generic dynamic task flow call (in the task flow template). This new implementation is easier, more robust, and generates significantly less managed beans. The pages will also load faster since every page has only one LOV popup included, instead of separate popups for each and every lov item (which were even repeated for each row in a table)
  • Enhanced Implementation of Custom Properties: Custom properties can now also be accessed using the name of the property (previously labeled description). There are three expression you can now use now, for example for group custom properties you can use:
    • ${JHS.current.group.property1}, this is the existing expression that also works when no name is entered for the property.
    • ${JHS.current.group.getCustomProperty("propertyName")}, where propertyName should be substituted with the name you entered for this property.
    • ${JHS.current.group.propertyName}, where propertyName should be substituted with the name you entered for this property. If you use this expression and the group does not have this custom property defined, you will get an error during generation.
We recommend to use the new second or third expression, these expressions dot not care which custom property number you used to enter the name and value. In addition, if you use the second or third expression, you never run out of custom properties, because you can also enter a comma-delimited list of names and values in the name and value property.

For a complete list of all existing features, use this link. For detailed information on all the features, check out the comprehensive JHeadstart Developer's guide. Want to try JHeadstart yourself? Do the tutorial using the JHeadstart evaluation version.

Friday Feb 10, 2012

Model-based Cascading LOV's For JHeadstart

Written By Peter Koletzke, 8 February, 2012 (posted by Steven)

SCENARIO

While searching for employees, users need to find a department by first finding a location from a City LOV (dropdown list). After selecting a city, the City and Postal Code appear on the screen.  LocationId also returns from the LOV, but is hidden because users should not see the ID.  

Then the user opens a Departments LOV (pop up LOV with query fields), which displays only departments within the selected city. After selecting a department, the Department ID and Department Name are returned to the screen. 

CONCLUSION

Implementing a cascading LOV consists mostly of work in the Model project. It is important that you prove that the cascading LOV works in the Model project before implementing it in the ViewController project. A brief list of the special components and settings needed to implement a cascading LOV follows. 

You can access a detailed recipe for this technique here. A sample application that results from this recipe is here.

MODEL PROJECT

  • Base view object for the Employees entity object: EmployeeMaster
  • Read-only view objects for the Locations LOV and Departments LOV queries
  • View criteria on the Departments LOV to represent a WHERE clause for location_id = :bind_variable
  • Locations and Departments added as reference entity objects to EmployeeMaster
  • Calculated attributes in EmployeesMaster as follows. All have Queryable as “true” and Display Hint as “Display.”
    • LocCity (LOCATIONS.CITY)
    • LocPostalCode (LOCATIONS.POSTAL_CODE)
    • LocLocationId (LOCATIONS.LOCATION_ID)
    • DeptDepartmentName (DEPARTMENTS.DEPARTMENT_ID)
  • Locations LOV on the Employees.LocCity attribute, returns city, location ID (hidden), and postal code
  • Departments LOV on the Employees.DepartmentName, returns DepartmentName and DepartmentId, uses DepartmentsLOV view object accessor with the detail LOV view criteria mentioned above (parameter value = LocLocationId)
  • AutoSubmit UI hint set for the two LOV items: LocCity, DeptDepartmentName
  • Dependencies to LocCity from DeptDepartmentName and DepartmentId (so they clear when the city changes)
  • View criteria on EmployeeMaster for a list of attributes needed in Quick Search area. An additional view criteria is needed for the Advanced Search area. LocLocationId is listed in both view criteria, but its UI Hint for Rendered Mode is “Never.” Deselect Show in List on the UI Hints tab.

VIEWCONTROLLER PROJECT

All actions are in the JHS application definition editor unless noted.

  • Set the LocLocationId item so it does not display in the table or in the form.
  • Set Quick Search View criteria and Advanced Search View criteria properties to the names of the appropriate (but separate) view criteria you created for to list attributes in these search sections
  • Set Depends On Item(s) properties for LocPostalCode as “LocCity,” for DepartmentId as “DeptDepartmentName,LocCity” so the LOV return fields on the edit page are set after an LOV selection.
  • Select the Clear/Refresh Value? property for DepartmentId so it clears when the city or department name changes.
  • For JHS 11.1.1.4: select Clear/Refresh? Value for DeptDepartmentName.
  • For JHS 11.1.1.3: edit adf-config-EmployeeMaster.xml after generation to define a depends-on refresh for DeptDepartmentName.


About

Java EE Consultants - JHeadstart, ADF, JSF

Search

Archives
« February 2012 »
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
   
       
Today