JMX DataControl and Flume monitoring tool

   This time I would like to put more atention to the data controls. I've been taking a part in one big data project. My role was to create a dashboard that would present businiess values. From the UI point of view it was easy choice to pick DVT components like gauge. 

   There were discussion about data sources. It was unarguable that Java Management Extension (JMX) is the proper way for communication. First, because the software in the technology stack already implements the JMX MBeans. Second, because ADF is providing JMX Data Control type to access JMX. But the second argument wasn't so good as it sounds... JMX connection can be done just for T3 protocol and to Weblogic application server. 

   By the name it promises a lot. But then it is limited to simple use case in which you want to expose some admin options for your users within the application in the declarative way (instead of invoking WLST scripts from Java code in beans). Still useful, but not this time.

   The solution for the opportunity found here is similar to integration with WebServices described by Frank Nimphus. There are three layers, similar to MVC model. The Model layer is responsible for establish the communication with MBeans and receive data (there were no insert/updates). Controller layer was mapping received values into local POJO classes. And the View layer presents the POJO classess as POJO Data Control. Changes within the MBeans interface doesn't influence on the UI in ADF-Faces because of the abstraction layer under POJO Data Control.

   Simple, efficient and, still, drag&drop at the end :)

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 :)

af:form default command use-case

   Recently I've done some simple application. As usually, there was a logging page, which I have developed following rules from the documentation. The mechanisms were working fine, but there was one user who has pointed a change request - he wanted to facilitate the logging in process. Now he need to use a mouse to click the button, instead he wants the form to be submitted with Enter key. Useful change, to improve user experience with the app I should start with the login page. 

   I've been checking for <af:commandButton> properties in order to find an attribute that would solve it. Unfortunately there was nothing suitable, and, it is not a place for specifying default action. In many cases developers may set such property to more than one components. During short and temporary insanity I've thought about JavaScript function to do the work :)

   Fortunately there is a solution. Simple and quick. Similar to rendered attribute, it is not the component that should be triggered in order to present (or hide) itself. It is the container. There is an attribute, defaultCommand, which must be set in <af:form> tag. And that's it :)

   And short quick note at the end - it supports EL expressions, so the action may be parameterized.