Thursday, 24 July 2014

few words about MDS in ADF - introduction


MDS or Metadata Services is very complex mechanism designed for customizations. For newbies I'm used to compare it to XSLT. Oracle ADF is more or less a set of XML files. Each XML has its own XSD scheme, each node has its own meaning and the XML nodes are in relation with another XML files. In example page fragments are in relation with their page definitions, but that part should be well known for ADF developers :) One quick look on ADF architecture:


 
image source: http://docs.oracle.com/middleware/1212/adf/ADFCG/intro.htm

The vertical bar with MDS label has been drawn across each layer! There must be something in it.

There are two types of MDS in ADF. First one is runtime. Users can implicitly to persist their "changes" to the application. An af:table wrapped in af:panelCollection contains 20 columns. User A needs for his work only five of them so he uses af:panelCollections feature to hide rest. User B has changed the size of the columns and so on. Such changes are saved in MDS runtime repository during the last phase of ADF-Faces lifecycle. I'll try to write a post about it in the future.

The second type is called seeded and i would like to spend a little bit more time about it. Seeded MDS is embedded with the application. You're able to find customization files in the deliverable package (EAR or WAR file) or in Metadata Archive (MAR) which could be delivered separately. While starting the JDeveloper, there is Customization Developer role. It is done similar to regular work of the ADF development team but with some constraints.



First thing that you must to be aware of is no Java development there. If you want to change method that handles ActionEvent, the bean and the method must be already developed. Customization role allows you to change only XML-based files excluding application descriptors like web.xml, weblogic.xml and so on. I haven't try to change them but i suppose that the customization won't applies to them. Second thing, JDeveloper supports changes only for ViewController projects. If you'll find a page to customize, probably you have found a taskflow that calls it. Also, you have got its page definition file. Mostly you'll do UI related changes like change a placeholder to customer's logo.

There is a picture in the documentation that put some more light to the description.

 image source: http://docs.oracle.com/cd/E16764_01/web.1111/b31974/img/layerdcust_ppt2.gif

In our deliverables we have got a JSF page (Base Document) and a collection of customizations divided to layers. Each layer could have more than one customizations. In the runtime framework checks if and which customizations should be applied to the page, applies them and produces an output. Site2 is the same as Base Document but Site1 differs. In the top right corner we have got an image.

But what if you want to change an entity? MDS is across all ADF layers... It is possible but you must to write customization file by your own. File must be put in the specific directory in the project. If you're adding an attribute or modify existing one it is not a big issue. The game begins when you must to remove an attribute. You must to find each view object that uses the entity, each application module that uses each of the view objects, each page definition that use the VOs and so on. Though? Sounds that it could be very though task to fulfill.

Now the most important question - what could be a business explanation for MDS? Maybe you have bought an application without source codes and the licence agreement disallows you to make changes in the deliverables. Or you have developed an application and sold it to thousands of customers. Each customer ask you about some changes like change the skin, hide some buttons, disclose a section by default and so on. It won't be nice to hardcode the client names and their business logic in the base source code. Also it won't be easy to maintain thousands of branches of the same application. It will be easier to have base application and customizations stored elsewhere but outside the base source code. If you have such problems, MDS is the answer. Fast to develope, without ifs or hardcodes in the base source code and easy to maintain.

No comments:

Post a Comment