Future of XSLT and Velocity
Can you tell me what the future is regarding XSLT and Velocity. Hannon Hill seems to be moving towards and focusing more on Velocity, than XSLT.
Will they both still be supported in the future. Is it recommended to move towards velocity?
Discussions are closed to public comments.
If you need help with Cascade CMS please
start a new discussion.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
1 Posted by Wing Ming Chan on 12 May, 2015 09:33 PM
Hi Nic,
When talking about XSLT vs. Velocity, I don't have an answer, for one or the other. But I do have a few things to add to the discussion:
Velocity is more powerful. Besides transforming block data, a Velocity script can be used alone, locating data source somewhere. XSLT cannot do this. In fact, I figured out a way to enhance the power of Velocity, so that it can access the Cascade database directly. It can also invoke XSLT.
There is no namespace support in Velocity, and macros are not exactly named templates. It is a bit easier to organize XSLT code into libraries. Reusability is very well-supported there. Velocity is catching up by introducing #import. But it still has a long way to go.
Until Hannon Hill introduces Velocity into the realm of tempate formats, there is no substitute for XSLT. I use template formats extensively and I am 'stuck'.
I am not sure if Hannon Hill has any plan to allow for custom widgets. They are written in Velocity. If they are made available, I want to become an expert in widgets, with the enhanced power of Velocity in mind.
I would say that Hannon Hill has to support XSLT for the next few years, though everybody can see that Velocity is getting a lot of support.
Wing
2 Posted by nicban on 13 May, 2015 02:12 PM
Thanks for you input Wing! I was just curious on the status of XSLT with Hannon Hill. I definitely see that Velocity getting more support and attention.
I personally choose Velocity over XSLT, I like the whole less is more. With XSLT I have to write so many lines of code, with Velocity it is less lines of code and and easier to read.
3 Posted by Wing Ming Chan on 13 May, 2015 02:23 PM
I absolutely agree that XSLT generally requires more lines of code. One major advantage of XSLT is that you can build reusable library code, using namespaces, named templates, and Xalan components. When I first started with Cascade, I could not use Velocity at all, due to a bug in Cascade prior 7.10.1. So the only choice for me was XSLT. In the past three years, I built a substantial XSLT library. This library is so helpful that I do not need to write much code when we switched to RWD. Everything written is still usable. I have also started writing Velocity formats just for fun. My main interest now is enhancing Velocity by going through the back door, using Java. This I can never do with XSLT.
Wing
4 Posted by Ryan Griffith on 13 May, 2015 03:40 PM
Hi Nic,
To echo your point, we have been continuing to focus more on Velocity since it is much more flexible in terms of adding functionality (eg Locator Tool and Query API) than XSLT is; however, there is no plan to drop XSLT. In fact, we do have some internal improvements logged to eventually attempt to upgrade XSLT and Xalan.
Wing's point about supporting namespaces in Velocity is definitely valid and is something we can certainly add to the XPath Tool if there is enough interest.
Believe it or not, you can in fact use native Java within XSLT. Scope out my comment on this discussion where I provide a sample XSLT Format that does some date manipulation using
Java.Calendar
.Please let me know if you have any additional questions.
Thanks!
5 Posted by Wing Ming Chan on 13 May, 2015 03:59 PM
Ryan,
I never knew that Java can be used in xslt. I will definitely look into this. By the way, the namespace declaration
xmlns:java="http://xml.apache.org/xalan/java"
is missing from the attached file hours.xsl.Wing
6 Posted by Bryce Roberts on 14 May, 2015 01:42 AM
Couple of point to add:
1) Namespaces are fairly easy to create and register into the xpath tool:
$_.getClass().forName('org.jdom.Namespace').getNamespace('prefixAsString', 'uriAsString')
This can be stored in a variable and added to an xpathtool by
$_XPathTool.addNamespace($NSVar)
2) Full Java (through rhino/narwhal) scripting is possible in both XSLT and Velocity, with Velocity having the direct advantage of reflection to be able to control the context and values included within the evaluation
3) With the locator tool and some dynamic evaluation, 'templating' with name and xpath matching is fully possible in Velocity, and script based extensions are also possible
4) Template level velocity formats are possible through xslt > extension > java > velocity, but there are some performance issues
Hope these points are helpful,
Bryce
7 Posted by Wing Ming Chan on 14 May, 2015 11:37 AM
Hi Bryce,
I have been waiting for some veterans like you to join the discussions. I hope you don't mind my attempt to pick your brain.
Can you provide an example? Let's say, I want to register a namespace for a library file with macros. What do I do in the library file, and what do I do in the script using the library?
Wing
8 Posted by Wing Ming Chan on 14 May, 2015 12:00 PM
Hi Ryan,
I have been trying the java: extension in xslt. So far, I have got two named templates working:
But when I triedcontains
(which involves a boolean) andreplace
, they don't work:I must have done something wrong. But what did I do wrong?
Wing
9 Posted by Bryce Roberts on 14 May, 2015 02:11 PM
Hello Wing,
The namespaces I am talking about have to do with XPath traversing.
Format
Expected Output;If you want to create macro sets (like namespaced templates), you would need to create a some other kind of machines. Couple of ways i have done this is through a hash map (macro name and signature) call through #evaluate or building the 'template' with strings and then #evaluate.
In the macros, you can use this for filtering the nodes sets before applying.
For java in xslt the signature is important for mapping, which can cause failures :
XSLT Type Java Types
Node-Set org.w3c.dom.traversal.NodeIterator, org.w3c.dom.NodeList, org.w3c.dom.Node or its subclasses, java.lang.String, java.lang.Object, char, [double, float, long, int, short, byte,] boolean
String java.lang.String, java.lang.Object, char, [double, float, long, int, short, byte,] boolean
Boolean boolean, java.lang.Boolean, java.lang.Object, java.lang.String
Number double, java.lang.Double, float, long, int, short,char, byte, boolean, java.lang.String, java.lang.Object
Result Tree Fragment org.w3c.dom.traversal.NodeIterator, org.w3c.dom.NodeList, org.w3c.dom.Node or its subclasses, java.lang.String, java.lang.Object, char, [double, float, long, int, short, byte,] boolean
Non-XSLT Type the native type or any of its superclasses, double, float, long, int, short, char, byte, java.lang.String
For return:
Java Types XSLT Type
org.w3c.dom.traversal.NodeIterator
org.apache.xml.dtm.DTM
org.apache.xml.dtm.DTMAxisIterator
org.apache.xml.dtm.DTMIterator
org.w3c.dom.Node Node-Set
java.lang.String String
java.lang.Boolean Boolean
java.lang.Number Number
org.w3c.dom.DocumentFragment Result Tree Fragment
org.apache.xpath.objects.XObject Specified XSLT Type
All other classes Non-XSLT Type
It may be easier to create a rhino script that maps functions out of the String Class you need. Plus you can be sure to do the type coercion as you expect.
For boolean values are you trying to match? You may need to stringify the boolean and match as string.
Sincerely,
Bryce
10 Posted by Wing Ming Chan on 14 May, 2015 02:17 PM
Bryce,
Thank you very much for the info. This will take me some time to digest.
Wing
11 Posted by Wing Ming Chan on 14 May, 2015 03:51 PM
I could not get
Wingreplace
to work, maybe due to the fact the method is overloaded. But I have a workingreplaceAll
:12 Posted by nicban on 14 May, 2015 07:23 PM
Thanks everyone. This is a lot of really good info!
13 Posted by Wing Ming Chan on 18 May, 2015 07:09 PM
An update. This stylesheet is kind of a partial equivalence of the
And here is a format using it:FieldTool
of Velocity:Wing
14 Posted by Wing Ming Chan on 22 May, 2015 06:20 PM
For those who are interested in string functions, here is a format I created, using Java extension:
And here is the test xsl:Wing
15 Posted by Ryan Griffith on 27 May, 2015 12:59 PM
Thank you for providing these Formats, Wing. I can see these being a nice alternative/replace for eXSLT extensions.
Please feel free to continue contributing these helper stylesheets and I'll talk to Charlie about adding them to our XSLT Workbook and Cascade Exchange.
Thanks!
Ryan Griffith closed this discussion on 30 Jun, 2015 06:42 PM.