Personalisation: Is the ability by the end user to change the look and feel of the application per their preferences. Like re-arranging, hiding columns in a table. Hiding or showing a detailed region, etc. Personalisations can persist within the same user sessions or can be configured to persist along user sessions.
Customisation (Seeded changes): Allow for design time customisation of a generic for specific sites or industries. These are done in jdeveloper using the customisation role. Its part of the deployment process.
Design time at Runtime: It is also possible to have a design time experience at runtime where administrators and analysts can used advanced components to create and model pages for the end user without the need for writing any code. This feature is provided by web centre which is a separately licensed product. We will not discuss that here since this comes in the domain of web 2.0 domain which has many other more powerful and useful features to exploit from.
Topics to be covered
- Customizing the appearance using style and skins
- Internationalizing and localizing pages
- Developing Accessible ADF pages
Personalisation:
The application can be configured to allow user personalisation changes to persist within the same user session or across sessions.
- Same User Session: Any changes that the user makes to the application will persist throughout the session. If they log off and log in again then the changes will be lost and they will the see the UI in the default mode. The application has to be configured to allow session persistence. If allowed then all component behviourial properties that can be persisted will be persisted for the session. You cannot choose specific ones to allow persistance for the session.
- Across Sessions (MDS persistance) : The application can be configured to allow changes to certain type of changes to certain widgets to persist across user sessions. At design time it can be decided that changes to which behviourial property of which components should be allowed to persist across user session. In a sense the user preference is stored for good. The setting for the components and their properties can be overriden at individual instance of it. Which means that if a persistance change for a certain component's behaviour might not be allowed at the application level, but it can be allowed for the specific instance of that component on a particular page / UI. The component and their properties that are chosen for MDS persistance are recorded in adf-config.xml
Templates and Regions used across mutliple pages: Any changes made in properties of components on these behave as follows:
Session persistance: The changes made by the end user will only reflect on the page in whose context the change has been made.
MDS persistance: the changes made will appear on all pages that use the region or template.
This is because of a difference in the way the persistance is applied in either scenario.
To be covered: Implementing User Customisations (sections 35.5 and .6)
Most end user of generic applications (typically application products) like to customise the application to suite their specific needs both in terms of validations applicable and the appearance of the application. For example customer software teams implementing a generic application at different sites can have a different customisation for each of their sites. In addition customisations can also be done for group of users such as different appearance for user with different roles and responsibilities.
Static Customisation: Static customisation is the one where the applicable customisation is visible to all users of that application. For example a site level customisation will be meant for all users at that site.
Dynamic Customisation: Dynamic Customisation is the one where the customisation applies differently to different users using the same application. This differentiation can be based on user roles.
Layered approach to Customisations:
Customisations are defined and applied in a layered way making the whole process of customisation more modular and easier to manage. The base application can have multiple layers of customisations.
For example a first layer can be 'industry' where different set of customisation can be configured for different industries in which the application might be used. Hence a different customisation set can be defined for say 'financial' industry and a different one for 'healthcase' or 'education' etc. These are called the layer values (i.e. 'financial','education','healthcare').
The next layer could be the 'site' layer. Where different sites can have different customisations.
The one after that could be a dynamic customisation layer for a user group such as a user role. Different roles have different customisations applicable to them.
As is evident here the customisation is defined at a customisation layer value. Which means that a set of customisation modifications would be defined for example education industry, another one for a site in New York.
The final behaviour of an application for the end user would depend upon the different layers of customisation applicable for that user. Hence at runtime the base layer is picked up then each customisation layer is applied (in the sequence in which is defined in the cust-config section of adf-config.xml) to it, depending upon the layer values derived from the context in which the application is running and the specific user using it.
diagram
This layered approach to customisations keeps the customisations as upgrade safe. The base layer can change without impacting the customisation layers.
Note: I dont think all customisations can be performed in the layer approach. This can be studied more to identify instance of customisations that cannot be applied through this approach. But this is definetely a good first step to try make customisations isolated from the base application and make the process of upgrading the base app less of a pain for the customers
Customisations on ADF model and business components are applicable all across the app since they are loaded only once. They cannot be controlled to behave differently for different users.
Customisations on controller or view level cane be configured based upon user role. Examples: different sets of users can be shown different sets of fields based upon their role.
The end user of the application can make certain changes to the UI they interact with as per their preferences.
Examples of these changes are:
- behaviour of widgets that show detail information (typically with a plus sign) can be changed to hide or show the detail by default.
- behaviour of widgets that show detail information (typically with a plus sign) can be changed to hide or show the detail by default.
- Resizable components can be resized, for example columns in a table, a frame.
- Panel splitter can be resized or collapsed.
- In a Calendar the view mode, whether year, month or week can switched. Active day can be selected
- Columns in a table can be re-ordered, frozen, visible, hidden, width changed. etc
- Panel splitter can be resized or collapsed.
- In a Calendar the view mode, whether year, month or week can switched. Active day can be selected
- Columns in a table can be re-ordered, frozen, visible, hidden, width changed. etc
Using MDS and the full Fusion stack also provides the following additional persistence functionality:
- Persisting additional attribute values
- Persisting search criteria
- Persisting the results of drag and drop gestures in the UI
- Reordering components on a page at runtime
- Adding and removing components and facets from the page at runtime
The application can be configured to allow user personalisation changes to persist within the same user session or across sessions.
- Same User Session: Any changes that the user makes to the application will persist throughout the session. If they log off and log in again then the changes will be lost and they will the see the UI in the default mode. The application has to be configured to allow session persistence. If allowed then all component behviourial properties that can be persisted will be persisted for the session. You cannot choose specific ones to allow persistance for the session.
- Across Sessions (MDS persistance) : The application can be configured to allow changes to certain type of changes to certain widgets to persist across user sessions. At design time it can be decided that changes to which behviourial property of which components should be allowed to persist across user session. In a sense the user preference is stored for good. The setting for the components and their properties can be overriden at individual instance of it. Which means that if a persistance change for a certain component's behaviour might not be allowed at the application level, but it can be allowed for the specific instance of that component on a particular page / UI. The component and their properties that are chosen for MDS persistance are recorded in adf-config.xml
Templates and Regions used across mutliple pages: Any changes made in properties of components on these behave as follows:
Session persistance: The changes made by the end user will only reflect on the page in whose context the change has been made.
MDS persistance: the changes made will appear on all pages that use the region or template.
This is because of a difference in the way the persistance is applied in either scenario.
To be covered: Implementing User Customisations (sections 35.5 and .6)
Application Customization:
Most end user of generic applications (typically application products) like to customise the application to suite their specific needs both in terms of validations applicable and the appearance of the application. For example customer software teams implementing a generic application at different sites can have a different customisation for each of their sites. In addition customisations can also be done for group of users such as different appearance for user with different roles and responsibilities.
Static Customisation: Static customisation is the one where the applicable customisation is visible to all users of that application. For example a site level customisation will be meant for all users at that site.
Dynamic Customisation: Dynamic Customisation is the one where the customisation applies differently to different users using the same application. This differentiation can be based on user roles.
Layered approach to Customisations:
Customisations are defined and applied in a layered way making the whole process of customisation more modular and easier to manage. The base application can have multiple layers of customisations.
For example a first layer can be 'industry' where different set of customisation can be configured for different industries in which the application might be used. Hence a different customisation set can be defined for say 'financial' industry and a different one for 'healthcase' or 'education' etc. These are called the layer values (i.e. 'financial','education','healthcare').
The next layer could be the 'site' layer. Where different sites can have different customisations.
The one after that could be a dynamic customisation layer for a user group such as a user role. Different roles have different customisations applicable to them.
As is evident here the customisation is defined at a customisation layer value. Which means that a set of customisation modifications would be defined for example education industry, another one for a site in New York.
The final behaviour of an application for the end user would depend upon the different layers of customisation applicable for that user. Hence at runtime the base layer is picked up then each customisation layer is applied (in the sequence in which is defined in the cust-config section of adf-config.xml) to it, depending upon the layer values derived from the context in which the application is running and the specific user using it.
diagram
This layered approach to customisations keeps the customisations as upgrade safe. The base layer can change without impacting the customisation layers.
Note: I dont think all customisations can be performed in the layer approach. This can be studied more to identify instance of customisations that cannot be applied through this approach. But this is definetely a good first step to try make customisations isolated from the base application and make the process of upgrading the base app less of a pain for the customers
Customisations on ADF model and business components are applicable all across the app since they are loaded only once. They cannot be controlled to behave differently for different users.
Customisations on controller or view level cane be configured based upon user role. Examples: different sets of users can be shown different sets of fields based upon their role.
This is a good video:
http://download.oracle.com/otn_hosted_doc/jdeveloper/111demos/mds/mds.html
http://download.oracle.com/otn_hosted_doc/jdeveloper/111demos/mds/mds.html
