X

The Integration blog covers the latest in product updates, best practices, customer stories, and more.

  • December 11, 2015

12c XSLT Editor Overview

Guest Author

The SOA and Service Bus tools plugins for JDeveloper provide a new XSLT Editor for the 12c release.  This blog post provides an overview of the new editor.

If you have used the 11g XSLT editor, the new editor will look very familiar to you.  The overall look and feel of the display remains the same with some code reused from the 11g editor for specific dialogs, etc.  However, the core of the editor was rewritten specifically to support more complex XSLT with larger schemas and still provide the user with a graphical display.  

In order to achieve this, the editor provides two graphical views in Design View:

  • Map View - shows all target tree nodes, both mapped and unmapped
  • XSLT View - shows the XSLT statements as they currently exist including any mapped target tree nodes 

The view is selectable by selecting Map or XSLT on the upper right of the editor toolbar. 

Map View is very similar to the functionality provided by the 11g XSLT editor.  This view allows simple drag and drop and use of simple XSLT statements such as xsl:for-each, xsl:if, xsl:choose/when, etc.  The user can also drag and drop from the source tree to the target tree to create mappings and add XPath statements in the center panel similar to the 11g editor. 

Map View

XSLT View is new in 12c.  It is essentially a graphically enhanced view
of the XSLT source code and is intended for users who know XSLT but want the
editor to provide schema information with the flexibility to do whatever they
need to do in XSLT.

This view shows the XSLT statements
as they appear in source view, but adds the ability to create and view all
XPath expressions graphically. It can
support more advanced XSLT constructs such as matched templates (template
rules), named templates and all XSLT 1.0 statements.

There are distinct advantages to
editing advanced XSLT in this view as opposed to editing the XSLT source
directly:

    • XSLT View is context-node
      aware.  (If you are unfamiliar with the
      term ‘context node’, I will explain this in future posts.  I’ll just say for now, that knowing the context
      node is central to knowing how you will write your XPath statements.)

Context-node
aware, in terms of the editor, means:

- If you are editing an XSLT file with
multiple matched templates (template rules), the editor can determine the
context node for each template and automatically create the correct relative
XPath expressions when the user drags and drops from the source into a specific
template.

- Conversely, the editor can then
display the resulting line for mappings that require knowledge of the context
node for a template.

- The context node for any template can
be found in the source tree by selecting the template in the XSLT.  This causes the context node to be
highlighted in the source tree. 

- While editing any XPath expression,
the user has access to a mini-tree that provides the context node and its
children for reference while editing XPath.

In
the picture below we are making use of an identity template.
The bubble highlighting in the source tree
shows the context nodes for the templates selected.

  • XSLT View shows only the XSLT
    statements and nodes in the current mapping.  This is an advantage when working with large
    schemas where many nodes on the target side are never mapped.  While unmapped target nodes are not
    explicitly shown, there are several ways to easily insert additional target
    nodes from the target schema or generate nodes from the schema.  This will be discussed in future blog posts.
  • XSLT View supports free-form XSLT
    editing with or without schemas.  XSLT
    View allows:
    • insertion of all XSLT 1.0
      statements.  These can be inserted in any
      manner desired:  as a child of the
      selected node, as a parent of the selected node, as a sibling either above or
      below the selected node.  The user is prompted
      for any attribute values for the XSLT element added.
    • creation of elements and attributes
      that are not part of the target schema.    
    • editing of named templates (these
      may be contained in XSLT files that are intended for import into other XSLT
      files, consequently they may not need source and target schemas defined).
    • rearrangement of statements by simply dragging and dropping them in the tree.

In future posts I hope to go through the features of each of
these graphical views in detail.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.