XSLT to .NETHTML5 custom control migration using the Xstl2jQuery Utility
Learn the basics of how to migrate your custom-control to the new .NETHTML5 version of Visual WebGui
Categories: jQuery, Extensions
Tags: Developers, Theme, XML, XSLT, 2. Intermediate, 3. Advanced, Customization, v6.4 and Later
Visual WebGui as a web development and deployment framework is made up of two logical parts: server-side which runs over IIS (or a Mono enabled web-server) and client-side which runs on the browser.
The Visual WebGui server-side updates the client UI by sending data in XML form.
The XML generated by server-side requires a transformation engine to render it to HTML that the browser can use to create a viewable result.
In Pro Studio WinWeb we use an XSLT engine to transform the XML to HTML.
For Pro Studio .NETHTML5, we created a brand new transformation engine based on jQuery and called “JQT” (jQuery templates). This new engine is now used to transform the server generated XML to HTML.
For more information about the benefits of the new Pro Studio .NETHTML5, please view this article here.The Xstl2jQuery Utility
The Xstl2jQuery Utility is meant to allow you automatic migration of the XSLT code in your custom controls to the new JQT and also to allow you to use this new generated code with the JQT based medias.
Please note that this tool is only meant to be run on code compatible with Visual WebGui v6.4 Release or later.
This utility adds file-system integration for the migration steps to MS Windows based machines.
You can download this utility from here.
Once you install it on a machine, you will notice four new context-menu items.
As you can see from the above screen-shot, there are two types of commands to choose from: “Convert” and “Switch”. These two types represent the two distinct steps of the migration process.Convert
This action is actually called “Convert To JQT”.
This action can be run on several files types: *.sln, *.vbproj, *.csproj, *.resx and *.xslt.
What it does is to simply create a JQT file of the translation of the XSLT for each XSLT file it finds.
For example: when running this command on an *.sln file, the utility will look in the solution file for projects, then will look in the project files for resources files (*.resx) and *.xslt files then will look in the resource files for *.xslt files.
All *.xslt files found, are translated into JQT and saved as additional *.jqt files next to their original *.xslt files.
Please notice that this step does not cause your application to use the newly created *.JQT files.
After this step, the *.xslt files are kept where they were. Please remember that at this point, they are referenced by both the *.resx files of the custom-control skin classes and the project files of the projects containing them.Switch
This action type is actually made up of three different types of actions: “Switch to JQT”, “Switch to JQT (keep XSLT)” and Switch to XSLT”.
This step is meant to change your application to switch the transformation engine being used by your application.
These are currently possible switch directions:
“XSLT” => “JQT”
“XSLT” => “JQT (keep XSLT)”
“JQT” / “JQT (keep XSLT)” => “XSLT”
* Currently there is no way to move directly from “JQT (keep XSLT)” to “JQT” and from “JQT” to “JQT (keep XSLT)”
The “JQT (keep XSLT)” mode is meant for testing purposes only and is in fact a mode in which both the XSLT and the JQT client cores are loaded onto the client and using the integrated testing tool, you are allowed to either use both engines at the same time for comparison, or to switch between them at run-time.
You can run this command on your *.sln file only – it is meaningless to run it on smaller scope files, as the change must take place for the entire application.
The switch action in the direction of either “JQT” or “JQT (keep XSLT)” creates backups of your project files and control-skin resource-files. For example, if your project file’s extension is “*.vbproj”, a copy of the pre-switch file will be created with the same name, but with the “*.bk.vbproj” extension.
The backups are used in the switch back to XSLT. During switch back to XSLT the current project files and control-skin resource-files are replaced with the backup files.
After this step, the *.xslt files are still as they were, so you will be able to switch back to XSLT mode and be able to use them.Maintenance
Notice that there is no conversion from JQT to XSLT, so you need to keep the XSLT files.
If you intend to use both JQT and XSLT and continue to develop your custom controls, you should develop them only on XSLT mode.
The reason is that once you convert your XSLT code to JQT and change the JQT code, you cannot convert it back to XSLT.
The best way to go, if you are using JQT is to:
- Switch back to XSLT.
- Change the *.xslt files of your custom-controls as you like.
- Convert your solution to JQT.
- Switch to JQT.
About the author
The JQT template engine is a robust jQuery template engine extension. It was created to provide powerful templating capabilities which are compatible (migratable) from XSLT. The JQT project includes runtime APIs which provide powerful capabilities and a XSLT migrator. The XSLT migrator can take XS...
The plugin provides functionality to compare two DOM nodes and build a well looking HTML page to visualize the difference.
The article describes how to use the debugging panel, migration hints and resource splitting in order to reach full functional equivalency between the original XSLT (WINWEB) version and targeted JQT (.NETHTML5) version.