This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
asgeir@dimon.is wrote: > > Hi. > > The XSLT execution actions are not directly related to my ideas of XSLT > editor. The actions are used to get results of transforming XML with XSL, > but an XSLT editor is used to create the XSLT files. You are right but both should be in same NetBeans module. And question is if I should create xsl module now (with this one feature only) or wait for 4.0 development time. This means that xsl module should contain "XSL Data Object", XSL specific actions, XSL text/tree editor support, etc. And it also requires better support from xml-core/xml-api modules which is currently in progress, not finished. > > Following items should be available in a good XSLT editor: > > 1. Syntax highlighting and code completion of XSLT tags. > This can maybe be done through SPI but I think this should always be > available for files with extension *.xsl and *.xslt. We have thought we would like to make namespace-driven syntax highlighting -- xsl tags and output tags are in different namespaces and this could be displayed with different background color for example. > > ------ > > 2. XPath expression builder should be available. > XPath expressions are used in XSLT attributes to locate elements in source > documents. This thus requires one or more XML source documents to be > attaced to the XSLT file object. When the expression builder is started, > the user should be allowed to select between the attached source documents. > The selected source document is then displayed in a tree view. The user > should be able to click the nodes in the source tree which causes the > expression builder to build an XPath. If the user clicks more then one > node, the expression builder should extrapolate to an XPath which matches > all the picked elements (and possibly more). This is better described by > an example: > > Lets suppose we have the following XML source: > <root> > <person name="Asgeir"/> > <person name="Libor"/> > <person name="Petr"/> > </root> > > We are creating a stylesheet where we want to create a html with the names > of all the persons in seperate paragraphs. The stylesheet which does that > is: > > <?xml version="1.0" encoding="UTF-8"?> > <xsl:stylesheet version="1.0" xmlns:xsl=" > http://www.w3.org/1999/XSL/Transform"> > <wdt:info version="3.0"/> > <xsl:template match="/"> > <html> > <head/> > <body> > <p> > <xsl:for-each select="/root[1]/person/@name"> > <xsl:value-of select="."/> > </xsl:for-each> > </p> > </body> > </html> > </xsl:template> > </xsl:stylesheet> > > The XPath in the xsl:for-each can be created by the XPath builder as > described. > 1. Click "Asgeir" in the XML source tree. This makes the expression > builder create the following XPath: "/root[1]/person[1]/@name" > 2. Click "Libor" in the XML source tree. The XPath of this node is > "/root[1]/person[2]/@name" and the expression builder extrapolates those > two XPaths to "/root[1]/person/@name". > Absolutely agree, this should XSLT editor include. This is very useful and maybe mandatory feature. We already had simple xpointer support but it was removed while XML module was open-sourced, improvement was necessary. > ------ > > 3. Result documents DTD should be attachable to the XSLT file object. > This will allow another view of the XSLT which displays only the part of > the XSLT code which is inside "<xsl:template match="/">". As you see in > the example above, the code inside <xsl:template match="/"> is almost valid > to the XHTML DTD. If the XHTML DTD would be assigned to this XSLT, the > code in this view would be > <html> > <head/> > <body> > <p> > <xsl:for-each select="/root[1]/person/@name"> > <xsl:value-of select="."/> > </xsl:for-each> > </p> > </body> > </html> > and the user should have code completion functionality for the XHTML tags, > as well as the XSLT tags. > This should also be driven by context namespace. To 4.0 we have planned "Namespace Domain Classifier" to customize appropriate XML domain (XSLT, XML Schema, Ant, etc.) document behavior/look -- text, tree, actions, etc. But now I am not sure if we are able to ensure it will be in that time. You can help as specify requirements. > ------- > > This is my view of an XSLT editor. The XSLT execution actions should of > course be available for the XSLT file types too, but they do not > neccesserly belong to the same module. I am sure it is.
*** Issue 21881 has been marked as a duplicate of this issue. ***
Report #22598 describes XSLT code completion.
Let these are considered while planning next release.
New XSL module request -- issue 25657.
Target milestone was changed from not determined to TBD
Libor created it.