4 Replies Latest reply on Jun 25, 2012 8:17 PM by Yannick Ongena

    EL to parametrize customization logic


      I have a rather uncommon(but reasonable, I guess) requirement. I'm using Webcenter Spaces, PS4 and we extensively use the document management taskflows (connected to UCM, also PS4).
      We have several group spaces creted for specific groups of people, some more tech savvy than others. In some (most) spaces, we need only very basic functionality , like the ability to list and view documents.
      Since the doc taskflows contain a lot more features, we decided to customize the taskflows and hide a lot of the unnecessary controls. This works well, but (as you would have guessed :) ) now we also need a few spaces where the full features of the doc taskflows like the document manager are required. But since we used MDS to customize the taskflows, they are global (within out WCS instance across all spaces). To address this problem, one suggestion is to set the "rendered" property on the controls to be be hidden as an EL though MDS customization. What this EL will do is look at the "features Off" property of the taskflow (which can be set when we place the taskflow on the page in a group space ). When placing the taskflow , we can include a string like "hideAll" in the featuesOff and the EL might be able to pick that up and set the rendered property of the various controls appropriately.

      1. What do you guys think of the approach ?
      2. Is there a better way to do this ? (Is this an unreasonable requirement ?) I need the same taskflow to expose different features on different group spaces.
      3. How can I create an EL that looks at the featuresOff propery from the rendered property. Is there an equivalent of java's"this" in EL ? eg :
      <af:commandButton id="uploadButton" rendered="#{this.featuresOff eq 'hideAll'? false : true }"

      I'll be interested to hear everyone's thoughts.


      Edited by: Jeevan Joseph on Jun 1, 2012 2:54 PM
        • 1. Re: EL to parametrize customization logic
          Yannick Ongena
          Interesting approach at least. It will definitly work but I'm not sure if it is the best solution.
          You basically hijack the featuresOff parameter for your own usage. A better approach would be to customize the taskflow by adding your own custom parameter.

          The features off parameter should be accessible trhough #{pageFlowScope.featuresOff}
          The way the doc manager currently works is by parsing these values in some managed bean and providing additional attributes in its managed bean because the featuresOff is never directly used in the document manager.
          Because it is an out of the box parameter I would recommend adding your own parameter to the taskflow so you have more control.

          This can easily be done by opening documentManager.xml in the /doclib-service-view.jar/oracle/webcenter/doclib/view/jsf/taskflows/docManager/ folder
          In the parameter section add your own parameter.

          Then you will be able to reference your own parameter in the fragments as well by using #{pageFlowScope.yourParam}
          When you drop the doc manager on a page, it will automatically pick up the additional parameter and display it in the parameter tab so you are able to provide a value.

          I just tried it out and it doesn't work...
          Strange because I thought it would. I thought that all XML based files could be customized in the MDS but apperently it doesn't work like that.
          I created a topic on the Webcenter EMG discussing this: https://groups.google.com/forum/?fromgroups#!topic/webcenter-emg/iv4yBmmtGTE

          Edited by: Yannick Ongena on Jun 2, 2012 12:10 PM
          1 person found this helpful
          • 2. Re: EL to parametrize customization logic
            Thanks for the reply Yannick !
            I agree that the approach is rather unsound, as your correctly put it, it is in-fact hijacking the featuresOff parameter.

            I did not think about customizing the taskflow itself as you suggested. I agree,its a much more cleaner approach, thanks again for the pointer. I clicked through to the WC EMG discussion and was reading though it.
            I know you and the guys at EMG already tried, but yours sounds like too good an approach not to give a shot myself (considering the alternative :) ).
            Customizing the task-flow itself should be possible, I think I myself have done it in the past, where I set, ironically, the featuresOff parameter inside wiki task-flow
            (which internally makes a taskflow-call to the folderViewer taskflow )

            I'll update my findings too here.


            Edited by: Jeevan Joseph on Jun 5, 2012 1:46 PM
            • 3. Re: EL to parametrize customization logic
              Hi Yannick ,

              Your suggestion solved my issue ! I'm really puzzled why it did'nt work for you though...

              For anyone looking do something similar, I created a small write up about what I did here :

              Thanks a bunch Yannick !
              • 4. Re: EL to parametrize customization logic
                Yannick Ongena
                I tried it again and I found out why it didn't work.
                I did a really quick test to see if my idea worked but because I did it so fast, I forgot to select the correct layer which means that I did my customization with layer value site1 instead of site. This way the changes weren't picked up by the portal :)

                I am also writing a few blog posts about customizing taskflows where this would be one of the scenario's.
                When I write the blog i will link to your post as well :)