Besides the “cool” factor, one of the main use-cases for Groovy with WebCenter Sites is to invoke it from an XML wrapper or small utility pages like SystemEvents. The wrapper can just be a caller to a java class without the need to wrap it in a Seed and use CALLJAVA. For instance the open-source GSF solution for WC Sites used a Groovy wrapper to call the GSF Action framework. One could use such a class to set the HTTP status code (302) sent back to the browser. Or authenticate to a 3rd party application (e.g. Portal, Commerce, or LDAP). Or to check/set cookies or visitor’s state. (see Dolf Dijkstra’s blog post here: http://www.ateam-oracle.com/using-groovy-elements-to-redirect-set-content-type-at-runtime-and-set-http-status-codes/)
The other obvious use-cases involve separation of business logic from presentation logic. In particular, the main problem with typical JSP elements (and the way developers typically code for them) is the inevitable mix of business logic with rendering logic. Leveraging a Groovy element gives the developer all the advantages of cleanly packaging business logic in a JAVA syntax scripting language while maintaining the ability to publish and reload code changes dynamically. This makes coding business logic more efficient, especially for those developers that aren’t seasoned WC Sites developers familiar with WC Sites’ schema and APIs.
Another benefit (and why WC Sites uses Groovy for CSDT) is you can serve binaries over HTTP without using XML. Note that given WC Sites’ servlet architecture, JSP has the habit of introducing unwanted spaces which corrupts binaries, so don’t even think about using JSP for streaming binaries.
Using Groovy with WC Sites
As of WebCenter Sites 11g, Groovy is supported when used as an element type. It is suitable for when what you want to implement some business logic/computation in a familiar JAVA syntax scripting environment (In fact, any scripting language that is compliant with JSR 233 can be used). Conveniently, WC Sites installs the Groovy binaries with the webapp OOTB. Unfortunately, dev tooling and documentation is lagging behind in the current release (true as of 11.1.1.8). Groovy support will further evolve in upcoming versions.
More frustratingly, the only mention of Groovy in the 11.1.1.8 Develeloper’s Guide is for the CrawlerConfigurator.Groovy file which ironically is not a CSElement! (i.e. the current doc is not much help at all, just to set expectations).
Note that a WC Sites Groovy element has just one variable bound at start: the familiar and ubiquitous ICS object.
Currently, there are only two sample Groovy CSElements that ship with WC Sites installations:
- …\Shared\elements\OpenMarket\Xcelerate\Util\GetUrlExpressions.Groovy
- …\Shared\elements\OpenMarket\Xcelerate\PrologActions\Publish\csdt\Stream.Groovy
And worse, neither is a good example of MVC coding! Or put another way: we don’t necessarily recommend coding most visitor-facing webpages using the above two patterns as there is no huge benefit due to lack of separation of presentation from business logic.
A better pattern leveraging Groovy CSElements would look like the following:
A Typical JSP Rendering Template (renders an asset):
- Calls a Groovy element as the “controller” for this asset’s Template (which should be considered the “view”)
- The Groovy element calls into a Groovy actions framework and returns Expression Language variables (not JAVA objects). Note that the Groovy element has access to the ICS object, thus providing full access to the Sites JAVA API. For “controlling” an asset, the basic algorithm would be to
- load the asset
- fetch its attributes
- convert any attribute values stored as reference ids into presentation values
- example: A related Image asset will be stored as an assetid (not a blob) in the asset’s attributes – the Groovy framework must convert this related asset id into a URL string such that the presentation developer only needs to render the returned value as a <IMG> tag value.
- Upon return, the Template developer only needs to work with HTML, JSTL variables, and JavaScript. Ideally there would be few (if any) use of Sites tags exposed in the view*.
Put another way: using the above idealized pattern Template (presentation) developers need not know anything about Sites or its API. As such, project resources can be better utilized with presentation developers working on pure presentation and business logic developers working on pure business logic, with clean separation between the two. Projects that proceed using this pattern are by nature more agile.
* one exception might be the use of insite tags to enable in-context editing.
And finally, let’s examine how the WC Sites product uses a Groovy CSElement in a real-world example:
<% // OpenMarket/Xcelerate/WebRefPattern/PatternHelper (JSP) %>
...
<% // one of the first things this template does is call the GetUrlExpressions element which just happens to be a Groovy element %>
<ics:callelement element="OpenMarket/Xcelerate/Util/GetUrlExpressions"/>
<% // the above Groovy element creates a Java object whose handle is "f", used in the following rendering code: %>
...
<%
Map functions = (Map)ics.GetObj("f");
Method[] methods = functions.get("f").getClass().getDeclaredMethods();
for (int im = 0; im < methods.length ; im++)
{
if (!methods[im].isSynthetic())
{
out.println("<div ondblclick='onFunctionDblClick(\"" + methods[im].getName() + "\")'><strong>" + methods[im].getName() + "</strong></div>");
Class[] parameterTypes = methods[im].getParameterTypes();
%>
<xlat:stream key="dvin/AT/Template/Parameters"/><br>
<%
for (int paramindex = 0; paramindex < parameterTypes.length ; paramindex++)
{
out.println(" " +parameterTypes[paramindex].getName() + "<br>");
}
out.println("<br>");
}
}
ics.SetObj("f", null);
%>
...
If this example were for a real-world project following best practices, we would expect to see the implementer use this (presumably skinnable) “helper” JSP for pure presentation. Thus, there would be no JAVA objects available in the view, just JSTL variables. As another example, the XLAT tags would have been hidden from this view and only the translated values also available as JSTL variables. As such, the Groovy element should ideally represent a call into a Groovy framework that can package up all this low-level business logic behind the scenes.
It appears that the usage of Groovy in this example is to script-enable an ostensibly “customizable” part of the business logic for rendering a key component of the contributor GUI. And while this usage is legitimate, for visitor-facing pages one might expect to see Groovy used to address other use cases listed above instead.
So there you have it. WebCenter Sites actually uses a couple of Groovy elements in the product itself. And enabling it via the standard callelement mechanism is simple and easy to understand.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission