Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.5
-
Fix Version/s: 1.6-rc-1, 1.7-beta-1
-
Component/s: XML Processing
-
Labels:None
-
Patch Submitted:Yes
-
Number of attachments :
Description
For uses of XML parsing that go beyond the basic capabilities provided by XmlParser and Node, it would be good to be able to reuse the functionality provided by these classes, by subclassing them.
Currently this is not possible. This "improvement" is to alter these classes in a compatible way to allow subclassing, and to describe how to do this in the Documentation beneath the http://groovy.codehaus.org/Processing+XML page.
For example, one extension that I've done allows the parse result to record the file path, line number, and column number of the elements - these can be quite useful if you have some processing that can generate messages about the XML back to the user.
See the thread in the user mailing list for some more discussion on this: http://archive.codehaus.org/groovy/user/4765F82F.9030601@schor.com
Attachments
Issue Links
| This issue relates to: | ||||
| GROOVY-2429 | Allow subclasses of XmlParser to customize creation of new Nodes |
|
|
|
| GROOVY-2415 | Add 1 argument constructor to groovy.util.Node, and corresponding groovy.util.XmlParser appendNode('someElementName') method |
|
|
|
Activity
Sure. The extensions I'm doing are 2:
1) incorporating the "location" information for each XML element in the Node This allows me to issue error messsages such as "element <xyz> has an invalid value for attiribute xxx, in file [substitute the file name here from the location], line {substitute the line number} near column {substitute the column number}.
2) The XML uses a name space, but only one name space. So the XML parser is set up to be name-space aware, and it generates QNames for the element names. But because there is only one namespace being used, it's more convenient to just replace those with non-name-space plain strings.
Perhaps there is an better way to do this, though. (I'm not an XML expert 
.
I'll see about attaching some code, as an example.
.
I'll see about attaching some code, as an example. I realise it has been a while but I would be keen to close this issue before its first birthday! If you have any comments on what changes are still required to allow you to meet your original objectives, that would be great, otherwise I will try to determine what I think is required over the next week. You will need to build the latest version from trunk or the 1.6 branch (or grab a jar out of the snapshot repo) to get the changes to date.
If you have any comments on what changes are still required to allow you to meet your original objectives, that would be great, otherwise I will try to determine what I think is required over the next week. You will need to build the latest version from trunk or the 1.6 branch (or grab a jar out of the snapshot repo) to get the changes to date.
A suggest approach to resolving this issue