Wednesday, 16 November 2016

parameterized bind iterator name as a mean to achieve reusable UI part in ADF12c

    This is a real-life use case that I'm usually hitting at the customers. There is a table which appears in the data model more than once. The business rules are the same, reusable, because they're implemented on the entity level. But to make it much more reusable, I want also to have the same front-end for them. In other words, I don't want to drag and drop each iterator from the data control and adjust the same visual rules to them each time (and change them in several places). Is there a way to do it just once per project? Well, there is.

    Lets start with preparation of the environment. I will base on REGIONS and COUNTRIES tables from HR scheme. My reusable part of the UI will be a region. There will be just one input parameter - iterator name. In the taskflow, I don't need nothing more than the view page. Just to create all needed files, structures and bindings, I'm drag and dropping one of the CountriesView iterator on it.

    And now the most important step of all. The taskflow parameter must be set in the page definition. When you select iterator binding, in the Property Inspector you get Binds attribute. It can accept EL expressions, but as I can see, in 12c you must type it manually. Another important note here, it must be evaluated with $ sign instead of #. Put ${pageFlowScope.iterName} there.

    To finish this proof of concept, create a test page, drag Regions iterator as a table. Drag and drop countriesBTF as a region and put CountriesView iterator names for both of them. After that you can run the test.

    One of the region is filtered with the view link, second is not filtered by default. First is refreshed after you'll change the current row of the Regions (master) iterator. Such behavior is an implication of shared data control scope.

    Hope you'll find it useful :)

No comments:

Post a Comment