A new release of the ADF EMG Audit Rules has been out, version: 12.2.1.1.20170129.1659
You can find the artefacts on the download page here.
Or just use the Help -> Check for Updates function and find it in the Open Source section.
Resources:
New Release: SonarQube ojaudit plugin
There is a new release of the ojaudit plugin for SonarQube on github.
Version 2.0 of this plugin is now compatible with SonarQube 5.6 and 6.0.
For the release, please go to: https://github.com/adfemg/sonarqube-ojaudit/releases/tag/2.0
The sources can be found on github under adfemg: https://github.com/adfemg/sonarqube-ojaudit
Version 2.0 of this plugin is now compatible with SonarQube 5.6 and 6.0.
For the release, please go to: https://github.com/adfemg/sonarqube-ojaudit/releases/tag/2.0
The sources can be found on github under adfemg: https://github.com/adfemg/sonarqube-ojaudit
Put Component References in the correct memory scope
Memory scopes itself can be confusing enough, therefor I always advise my fellow developers to use the ADF scopes as much as possible and avoid the JSF scopes if they can.
When using taskflows, a lot of times, we want to store values in a pageFlowScope bean, for example to use during the lifecycle of the taskflow on several pages. Now a common mistakes is to have the UI components bind to the same bean as the values.
Usually this happens, because there is an actionListener that refreshes the component in the pageFlowScope bean, that also sets values in that same bean.
I am always a fan of splitting up beans in smaller logical blocks of code, but in this case it is necessary as well. There is a good blog by the a-team on the best practises for bindings in ADF. Next to that, there is also a Code Guideline on the ADF Architecture Square:
• [ADFcg1-03009] – Store UI components in requestScope and backingBeanScope beans - only store references to UI components in requestScope and backingBeanScope beans. Never store references to UI components in applicationScope, sessionScope, viewScope or pageFlowScope beans.
Not doing this, can cause problems on a HA clustered environment, but the main and best reason in my eyes for this is because the UI component tree might not be released correctly. This has two side effects, mostly a significantly increasing of memory load of your application, but I have also seen some strange behaviour of the UI component, leading to inconsistent state of the component in the browser.
The tricks is to split the beans in separated concerns, one that manages the UI components, holding the component references, as well as the actionlisteners. In the taskflow we inject the pageFlowScope bean holding the values in this backingBeanScoped bean that manages the UI state.
Because we have access to the values through the injected bean, we can use the getters and setters to read or modify the value in the pageFlowScope bean, while making sure our UI component references never exceed the backingBeanScope.
My next blogpost will show an example of how to set up this beans including code examples.
Resources:
When using taskflows, a lot of times, we want to store values in a pageFlowScope bean, for example to use during the lifecycle of the taskflow on several pages. Now a common mistakes is to have the UI components bind to the same bean as the values.
Usually this happens, because there is an actionListener that refreshes the component in the pageFlowScope bean, that also sets values in that same bean.
I am always a fan of splitting up beans in smaller logical blocks of code, but in this case it is necessary as well. There is a good blog by the a-team on the best practises for bindings in ADF. Next to that, there is also a Code Guideline on the ADF Architecture Square:
• [ADFcg1-03009] – Store UI components in requestScope and backingBeanScope beans - only store references to UI components in requestScope and backingBeanScope beans. Never store references to UI components in applicationScope, sessionScope, viewScope or pageFlowScope beans.
Not doing this, can cause problems on a HA clustered environment, but the main and best reason in my eyes for this is because the UI component tree might not be released correctly. This has two side effects, mostly a significantly increasing of memory load of your application, but I have also seen some strange behaviour of the UI component, leading to inconsistent state of the component in the browser.
The tricks is to split the beans in separated concerns, one that manages the UI components, holding the component references, as well as the actionlisteners. In the taskflow we inject the pageFlowScope bean holding the values in this backingBeanScoped bean that manages the UI state.
Because we have access to the values through the injected bean, we can use the getters and setters to read or modify the value in the pageFlowScope bean, while making sure our UI component references never exceed the backingBeanScope.
My next blogpost will show an example of how to set up this beans including code examples.
Resources:
Subscribe to:
Posts (Atom)