Posts tagged mds
ADF: Cloning personalizations between users – read and write MDS Customization documents
0In a recent post I wrote how wonderful the ADF support for user level customizations or personalizations is, and then I went on to explain how the user can be enabled to remove her own personalizations (http://technology.amis.nl/2012/09/27/adf-undo-the-users-page-personalizations-query-and-manipulate-mds/). This article a sequel to that story. It will introduce the capability for one user to clone the personalizations from another user. This means at the background that the document that contains the customizations for a page for the ‘source user’ is read and a new document with the exact same contents is written for the ‘target user’ who will then have personalizations that are at that time exactly the same as those of the source user. There is no link between the two documents – they are both on their own. Any pre-existing personalizations for the target user are lost in this process.
Note: I do not talk about the privileges that you want to define in order to not have anyone copying from just anyone else. Also note that I discuss cloning the personalizations for a single page only. Copying all personalizations from one user to another however is a very simple extension of what More >
ADF: undo the user’s page personalizations – query and manipulate MDS
0One of the quite powerful features of ADF is the built in support user customizations also known as personalizations. A user can apply changes to an ADF web page – rearranging some of the layout, configuring advanced components such as tables and generally fine tuning the look and feel to the user’s individual needs. If the application is so configured, these changes are retained during the session (for each next visit to the page) or even across sessions (for each next visit to the page, also after an intermediate log out, in an entirely new session).
The framework provides declarative support for registering and reapplying the personalizations made by the user. These are held in the MDS Repository, in an XML file that contains the deltas that the user is (indirectly) requesting to have applied on top of the base sources of the application.
The framework does not have built in out of the box support for resetting the page – returning it to its factory level, the state in which the developers created it. The customization document needs to be removed from the MDS repository when the user wants to undo the personalizations made. To accomplish this, we need to write a little code More >
OOW 2009: Castle in the Clouds: SaaS-Enabling Oracle ADF Faces Applications
It will be my last presentation at Oracle Open World 2009 – how to turn any ADF application into a SaaS application – an application suitable for deployment ‘on the cloud – available to users from different organizations’. One of my statements is that most if not all applications benefit from applying those same SaaS concepts. It makes applications running within the walls of an enterprise more agile, more manageable, better suited to the specific needs of individual users and user groups and easier to integrate in the IT landscape of the enterprise, both at the services level (SOA, ESB) and at the user interface level (Portlet). The presentation will discuss a number of facilities and characteristics that are desirable in SaaS applications as well as other Web Applications.
If you are interested in attending and watching the live demos, please come to the session: S307483 Castle in the Clouds: SaaS-Enabling Oracle ADF Faces Applications (Wednesday 14th October, Time: 11:45 – 12:45, Marriott Hotel, Salon 3).
ADF 11g – persisted run time user UI personalization or: Impatient man's MDS
One of the rather cool pieces of functionality that did not make it into the JDeveloper 11g Boxer release of early October 2008 is the Meta Data Service or MDS and especially its capability to store and reapply user created personalizations of the User Interface across sessions. Some simple examples of what this means: ADF 11g Rich Client Components allow users to manipulate the state of components – such as the position of the separator in the PanelSplitter, the ordering and width of Table Columns, the initially visible tab or accordion child etc.. Through MDS, these changes are captured and stored for th duration of the session (if so desired), which means that when the user returns to a page thus ‘personalized’, the component will not assume their default state as specified in the JSF page at design time by the developer, but rather the state that user specified. Eventually MDS will persist these component personalizations across sessions – but not right now. That means that at the present when a user starts a new session, all components are presented in their default state.
In this article I will describe two things: Change Persistency for all attributes – not just the More >
Recent Comments