ActiveState Debuts XSLT Tool for Visual Studio .NET 2003
At last week's Microsoft Professional Developers Conference in LA, even third party partners got in on the push to bring more web services development power Microsoft's Visual Studio .NET 2003. Case in point: ActiveState released an upgrade of its Visual XSLT IDE plug-in for Visual Studio .NET 2003 IDN looks at the upgrade, which sports a just-in-time debugging, a visual schema mapper and improved project management.
Open Source tool provider ActiveState released an upgrade of its Visual XSLT IDE plug-in for Visual Studio .NET 2003 at this week's Microsoft Professional Developers Conference in LA.
The Visual XSLT 2.0 upgrade for the Visual Studio .NET IDE leverages some of .NET Framework's deepest code technologies, ActiveState technologists told OET to push the envelop for ease of use and debugging for XML/XSLT programming The result is an upgrade from Visual XSLT 1.0 that sports a just-in-time debugging, a programming-free visual schema mapper and improved project management.
Beyond Visual XSLT 1.0's Basic Support
In Visual XSLT 1.0 Promislow said ActiveState "provided the basics to get rid of much of the pain of [XML/XSLT] programming," including features for editing, debugging and file management. For instance. When typing a "less than" command in XSLT the Visual XSLT toolkit would automatically provide devs a drop down list of all the tags that the program could sense at that point, he said.
The same went for debugging. Because XSLT always involves an XML input file, debugging programs meant that developers also needed control over their input -- not just they code. So, Visual XSLT 1.0 provided the ability to set breakpoints in the input buffer as well. Since XSLT is a rules-based language, this makes sense: set a breakpoint where the input isn't being processed as expected, and examine the variables at that point. Once bugs were fixed, XSLT transformations could be run outside the debugger, with the results brought up automatically in a browser
But, as devs began to tackle XML/XSLT challenges in the enterprise, the demand for a more powerful, automated set of tools, for both assembling XML schema relationships and debugging the resulting code has emerged from users, Promislow told OET.
"From our Visual XSLT 1.0 users were heard two main themes," Eric Promislow, ActiveState's Technical Lead for Visual Studio .NET plug-ins told OET. They wanted: (1) easier ways to map their XML schemas to new document schemas, and (2) easier ways to perform and debug their XML/XSLT transformations.
Visual XSLT 2.0 delivers both features, while tapping into underlying XML support that lies within the .NET Framework, Promislow said.
Automated, Visual Schema Mapping
The need to make differing schema easily readable by one another, or to outright convert them, is growing in important for devs, Promislow said.
"A lot of people told us they want a visual mapping tool where they could bring up their documents in their current format and then bring up a target template and do a drag and drop type of conversion. So, instead of having to write a program that manually looks for, say, invoice tags and does a renaming, they can now view two trees, representing the structure of their documents before and after conversion," Promislow said. As a result, developers can then simply draw lines between the two sets of nodes to carry out renaming or reordering.
The result is that Visual XSLT 2.0 includes a Visual Schema Mapper. The VSM feature lets a dev forge compatibilities between two different XML schema by simply dragging and dropping a dotted line between the compatible elements of the schema (name, invoice #, date, whatever) and pressing a button. "That simple visual operation generates an XSLT program right in the IDE, and the developer can view the results in a window to check the results again his input."
Is it as simple as that? " Promislow said it can be. "If you are renaming and reordering and dropping parts in the old section you may not need any more. When you draw your connecting line [between elements of the old schema and the new/target schema] Visual XSLT is working at the element tag level, not the text level, to make the transformation."
It will even work with complex documents, he added. "We tried this with some sample EDI documents," Promislow added. "They have a large number of different tags, but tend not to be too deep or complex. As long as you can scroll the two trees so the source and target nodes are in view, you can draw a connection between the two"
Just-in-Time Debugging for Transformations
Visual XSLT 2.0 also comes with a Just-in-Time (JIT) Debugger which performs 'on the fly" code checking and debugging of transformations.
Promislow explains: "A lot of XSLT transformations are not standalone. In fact, transformations are a very involved, behind-the-scenes technology project." A common scenario for developers is that they use a database and transform their XML using XSLT into HTML or into other code with backend types of programming. After they're done, many devs are looking for assistance in debugging it. That kind of help used to be a bit of a kluge, P admitted.
"In the past [in Visual XSLT 1.0], our solution was that you need to get XML out of the database and save it to file A and then get that XSLT out of your program and save it to file B and then we'll let you pass parameters to your XSLT program and debug to their heart's content. People weren't overjoyed," Promislow told OET. What they really wanted was to have the debugger load at the point where the transformation takes place."
Now, Visual XSLT 2.0 provides such on-the-fly support for transformation debugging. "Instead of pointing Visual XSLT at the files, we're pointing it at the application. That means that with Visuals XSLT 2.0 the developer doesn't need to supply us the source code, we can get it out of the app because it is just XML, and we display it and then the developer can debug it as if it were a stand-alone transformation.
In fact, during testing of the software, ActiveState engineers discovered that devs don't even need the source code of the target application. The only requirement is that it be a .NET Framework app, which makes us able to detect when that transformation takes place at the backend.
So, despite the power of these tools, Promislow warned OET that devs shouldn't expect similar features to be available anytime soon for it's Open Source Komodo IDE.
The reason? Komodo just doesn't have the backend XML support necessary to make all the magic happen. "This is deep .NET Framework stuff we're leveraging," Promislow told OET. "We're working at the assembler level of the .NET Framework. Even though the developer sees simply XSLT, you'd see C# compiled into IL code, which is like Java byte code. We're working at that level, but because we can we don't require any customers to work anywhere near that level at all. That's how much power Microsoft has put into the .NET Framework."
Visual XSLT licenses are $295. The program is also offered as part of the ActiveState Open Source Language Suite for Microsoft Visual Studio .NET 2003-a value-priced bundle of Visual Perl, Visual Python, and Visual XSLT-for $495. Upgrades are $99.95 for current users. Free 21-day trial licenses, educational licenses, and more information are at available to developers.