XSLT? Yes, that technology does still exists for portals. JEE developers think of servlets, portal developers of portlets and web developers in general think about AJAX, when they mean HTML5. Every technology comes with its own pros and cons.
As HTML5 makes use of AJAX for loading data to be displayed, you need some kind of service to load the data from. No service, no way of loading the data. Somehow you have to create the service and the more data you have to expose, the more complicated it gets to manage all these services.
For portlets / JSP applications, you do not need services as you have direct access to the Java objects that give you the data needed and come with MVC. However, every change to the UI means a new compile and deploy. Even with CI/CD this is some work considering that you may only change the welcome clause.
There is the combination of both, but the basic problems do not go away: your HTML5 page with AJAX for data loading needs a service to get the data from and your portlet will be reduced to a service. What about a solution that is between HTML5 and JSP? What about XSL? With XSL, you can create pages that can use Java objects. The XSL file for the transformation is a simple text file; therefore, normal web content rules apply. The output is HTML(5) and is content is dynamic: input can be a XML file for creating “static” text, while dynamic data can come from a back end (Java object).
Table listing all flights
How does this actually work?
You need Java objects that return the data you need. That can be portal, user, system information, date, anything. An optional XML file for the static content, like messages. Moreover, the XSL file that will do the actual transformation to HTML.
Let’s take an XML file that contains some “static” information to be displayed. Transforming that XML into HTML with XSL is no problem at all. Now you have to add data from a backend to fill the static content with life. For this, you can write a Java object that uses JCo to get the data out from an SAP ABAP backend (or using JCA, btw: here the SAP Portal can show its strength with system object, aliases and SSO). Instead of transforming the Java object into a service* or write a portlet and JSP. Using the above-explained architecture, XSL can solve the problem.
Take the XML file
<?xml version="1.0"?> <news> <item> <name>Portal news</name> <content>Authored portal news for all users</content> </item> <item> <name>Test news</name> <content>test news item 1</content> </item> <item> <name>Real notifications</name> <content>More information to be communicated</content> </item> </news>
Take the XSL file
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:Date="xalan://java.util.Date" xmlns:JCO="xalan://com.tobias.jco.test.ServerConn" xmlns:jcoException="xalan://com.sap.conn.jco.JCoException" xmlns:java="http://xml.apache.org/xslt/java"> <xsl:output encoding="UTF-8" method="xhtml" indent="no"/> <xsl:template name="test" match="/"> <div> <xsl:for-each select="news/item"> <h2> <xsl:value-of select="name" /> </h2> <p> <xsl:value-of select="content" /> <br/> <xsl:variable name="date" select="Date:new()"/> <i> <xsl:value-of select="Date:toString()"/> </i> </p> <hr/> </xsl:for-each> <div id="demo"> <xsl:variable name="jcoTest" select="JCO:new()"/> <xsl:value-of select="JCO:getHtml($jcoTest)" disable-output-escaping="yes"/> </div> </div> </xsl:template> </xsl:stylesheet>
The trick here is that the Java object returns a HTML table**.
Using XSL to create dynamic HTML pages using Java objects and at the same time treat it as simple CMS content offers many benefits. However, if this works on all devise depends on how the XSL transformation is done:
- Server side or
- Client side
Server side transformation will work; as the resulting HTML page is send to the device. Client side will not work on all devices, as the client browser needs to support XSL. For instance, the browser used in Android devices most likely will not work. Using client side XSL transformation In Android 4 emulator gives:
Why? Vanilla Android browser does not support client side XSL.
Using XSL for creating web content does not make sense for complex applications or when a service is available. For creating a web page that uses backend, portal, user data for the content and only the Java object is available or creating a service does not offer much value it makes sense. Instead of having x portlets, y JSP and z html pages for creating a page, XSL can simplify the effort. Changes to static content are made in the XML and not in the JSP, HTML, property file or even in the source code. Especially that “standard” Java objects can be reused without transforming them into a service is a strong point for XSLT. As the content is web content (xml and xsl) the usual CMS rules can be applied. Java objects used do not need to be exposed as a service, makes it is easier to implement and change them. Besides this, you gain portability: XSL files are portable to other (Java) portals, as long as they support XSL.
As you can see, the above screenshots are not based on a SAP Portal. So, what about SAP Portal? Can you create web pages using XSL and integrate Java objects using the SAP Portal? Of course you can. Web Page Composer uses XSL for transforming XML content into HTML. You’ll only have to make your Java objects available in WPC and create your own XSL files. Afterwards you can start creating HTML sites that incorporate Portal information using Java.
*note: not a real time consuming task with annotations and helpers like Jersey.
**that is given by the fact that I was too lazy to come up with a XSL transformation that handles Java arrays / objects. Instead, I created a wrapper object that transforms the BAPI return into HTML.