OmniPortlet was originally built for Oracle Portal, allowing page designers to visualize various types of data sources in a declarative manner in the browser, without using an IDE. The two simple steps of defining an OmniPortlet in-place are: selecting and specifying your data source (XML, SQL, CSV, Web service, etc.), and applying the visualization/view on top (table, bullet, scrolling news, or even custom HTML).
While OmniPortlet doesn’t support ADF eventing, if all you need is driving a detail OmniPortlet from a master one, here is how you can achieve it. In this example I’m using WebCenter Spaces, but the same applies to any custom WebCenter portal application that leverages Oracle Composer.
Edit your page, and drop two instances of OmniPortlet onto the page. At this point they will be undefined.
From the View Actions Menu of the first one, select the Customize menu.
For our simple demo, select CSV as the data source, and leave the default settings for the CSV URL. The only thing we’ll change in this portlet is the Layout Style: HTML.
For the non-repeating heading section, specify the hyperlink for your master portlet. What you need to know for this step, is the URL of your page, containing your portlet. If you’re using WebCenter Spaces, an easy way to find this out is through the About menu of your page. In my case, the page is called OmniPage, and it’s in the group space, called MyGroupSpace. Notice the URL parameter appended to the linked page, PageParam1 (you can choose your own name, of course), and the values assigned to it: Hello in the first line, and World in the second.
<a href="http://mywebcenter.com/webcenter/spaces/GS/page/OmniPage?PageParam1=Hello">Hello</a> <br> <a href="http://mywebcenter.com/webcenter/spaces/GS/page/OmniPage?PageParam1=World">World</a>
Note: The above code snippet appears to be incomplete, but if you select it and paste it into a text editor, you will have it all.
Customize the second OmniPortlet, choose HTML for the Layout Style. All you need to do, is reference the parameter passed to this OmniPortlet, by using the OmniPortlet syntax: ##Param1##.
The last step is specifying that the request parameter specified in the first OmniPortlet, PageParam1, should e passed to the first parameter of OmniPortlet, Param1. To do this, make sure the page is in edit mode. Click the Edit (pencil) link of the Detail (consumer) OmniPortlet, and specify the following value for Param1: #{param.PageParam1}. This is the EL syntax for “request parameter, called PageParam1”.
Save your changes, and close the edit mode of your page. What you should see is similar to this when clicking on Hello:
And here is what you get when clicking on World:
One important caveat: this is more of a trick or workaround for OmniPortlet’s (and PDK-Java as a portlet technology’s) shortcoming, the lack of support for ADF model events. This solution will perform a full page refresh, and it also resets/looses your JSF session. If you’re designing components/portlets that should support inter-component communication, your first choice should always be ADF task flows or WSRP 2.0 portlets.
Filed under: WebCenter General | Tagged: inter-portlet communication, ipc, omniportlet, Oracle Portal | Leave a comment »
Peter Moskovits' Oracle WebCenter Blog: 2008-2011 