Monday, June 25, 2012

Parametrizing WebCenter spaces customization

I'm using webcenter spaces, and I'm on PS5.

I need to customize some Webcenter task-flows, but I don't want the customization to take effect globally. I am using spaces, so I would like to localize customization to a space, or to an individual instance of a task-flow. For example, I have some MDS customization in the document task-flows, like in the wiki, I want to hide a bunch of features and controls/command buttons for all users except moderators.

I'll use the wiki as an example for this post. The wiki uses the folderViewer BTF (taskflow call) and the folderViewer BTF uses the DocumentViewer BTF (in the case of wiki). So a lot of these customizations are on the DocumentViewer taskflow's JSF fragments.
If I customize the right JSF fragments, everything can be shown/hidden based on the requirement. So far so good. Now the real problem is that these customizations are global, meaning for this webcenter spaces instance  or any WCS instance that uses this MDS DB, these customizations apply.

However, it would be nice to be able to parametrize (to an extent, and mostly at a very coarse grained level) some of the customizations so that I can customize these taskflows on a per Space level or per instance level. With Yannick's suggestion to add taskflow paramerets by customizing the taskflows themselves, I can do this at a per taskflow instance level , which is excellent !

Here is what I did :

Taking the example of the Wiki taskflow, here is the structure of the taskflow (you can see this by looking at the wiki taskflow from your library, in customization developer role)

Wiki Taskflow --calls--> FolderViewer Taskflow --calls--> DocumentViewer Taskflow

I want the customizations to be applied by default (just because that is the most common scenario for me), but want to give the page/space owners the ability to disable the customizations and expose the vanilla/out-of-the-box features of the taskflow too(a not-so-common thing in my implementation). To do this, when the person placing a wiki page on thier space, they should be able to set a parameter to disable all our internal customizations. This parameter obviously needs to be defined on the wiki tasklfow.

  • Step 1
    • Define new parmeter on the wiki taskflow.
    • Name the parameter something sensible, say 'disableCustomizations', make the type Boolean and set the value to #{pageFlowScope.disableCustomizations}. Setting the value is not mandatory if you dont mind the value being in pageFlowScope, which is the default scope it will be put in to at runtime, but I just prefer to be explicit.
    • Though the user sets the parameter on the wiki, the actual customizations are done on the DocumentViewer Taskflow's JSF fragments. So we need a way to propagate this parameter to the actual place/taskflow where it will be used.
    • Now one thing to note is that this  parameter value #{pageFlowScope.disableCustomizations} will not be available to the taskflow being called, DocumentViewer in our case. This is simple beacause taskflow calls and regions containing taskflows, when executed get thier own pageFlowScope that is different from the caller's pageFlowScope. I really dont want to keep a paremeter in the session scope, so I decided to add a parameter to  FolderViewer taskflow and from there propagate the value again to the actual DocumentViewer by adding a parameter to that as well.
  • Step 2
    • Add a paremeter to the FolderViewer Taskflow. Pass the user's input parameter to the FolderViewer, by customizing the taskflow call.
  • Step 3
    • Repeat step 2, but for propagating the value from FolderViewer to DocumentViewer.
    • Add a paramater to the DocumentViewer taskflow. Pass the parameter value recieved by FolderViewer to the DocumentViewer by customizing the taskflow call.
  • Step 4
    • Customize the DocumentViewer jsffs by incorporating the parameter value. Set the rendered attribute on the controls and components that I want to be able to toggle based on the parameter value.

Now deploy the customization and you should see a new parameter on the task-flow, and setting the parameter can toggle the components we have customized. The best thing is the new parameter can be set on per-instance of a taskflow, so I can have two Wiki taskflows on the same page, both looking different !

To recap, the idea here is to create your customization to be dependent on a parameter, which itself can be created through customization. Since customizations are global, the parameter is globally available across the webcenter instance, but since the actual, end user customization is dependent on the parameter, the customizations are applied only when the parameter is set. This enables us to finely control when the customizations are applied and when they are not.

A bunch of thanks to Yannick, for pointing me in the right direction from the OTN forums!


  1. This comment has been removed by a blog administrator.

  2. Wow! Cool post! I really like the choice of your posts especially that I am fund of reading books. I know for a fat that you can learn a lot of things when you read books. That is why it is important that you learn to teach and encourage kids to read. Parents also are encouraged to read aloud to their children.

  3. Hi , very good article, thanks for providing in-depth information on Oracle ADF Technology. Please continue sharing.

  4. nice post and site, good work! This article is well written and quite informative. More articles should be written and you have just found a follower.and more visit
    sas online training

  5. Simply excellent article on oracle ADF..... for those who want the best
    Websphere Training In Hyderabad with job support

  6. Good post. It is really help to us. Its give us lots of interest and pleasure. Its opportunity are so fantastic and working style so speedy. Its really a good article. It gives me lots of pleasure and interest.