Also see the XMLC 2.2 Release Note, XMLC 2.2.1 Release Note, XMLC 2.2.2 Release Note, XMLC 2.2.3 Release Note, and XMLC 2.2.4 Release Note.
Fixed problem where XHTMLFormElement.getChildNodes() was returning zero children even though they existed. This is similar to a problem previously reported for this in the lazydom which was fixed with a similar, though slightly different solution. The problem was that the XHTML DOM wasn't quite up-to-date with the HTML DOM. All the details about this issue are in the Javadoc for org.enhydra.apache.xerces.dom.ParentNode where it says that HTMLFormElement and HTMLSelectElement are special cases that need to override getChildNodes(). I simply copied the methods from those classes and added them to the XHTML versions of the classes. Tested Petr's testcase and it works now with all the HTML/XHTML-based doms.
This really causes problems if you are using the DOMWriter repeatedly, to write chunks of the document at a time, rather than the whole thing at once. By putting a writeln() here, it ends up splitting lines wherever the chunk finishes, and if that's in between spans surrounding text nodes, it can adversely effect the output that gets displayed. Consequently, we really need to remove this writeln. What this means is that there will no longer be a final CR/LF at the end of reports, but I don't think that will actually cause any problems.
org.enhydra.xml.xmlc.compiler.ElementInfo now generates setText*() methods for elements with Id's, but without existing child text nodes. This means one can create <span id="foo"></span> and expect the setTextFoo(String) to be generated. This also required a change to org.enhydra.xml.xmlc.XMLObjectImpl#doSetText() to create a child text node if it doesn't exist before setting data on it. This removes a major source of confusion and template fragility from XMLC development!
Checked in generated sources for lazydom to ease the burden of having to run the generation script every time the code is newly checked out. It is especially burdensome for users on Windows systems since Cygwin must be installed in order to run the script. Commented out references to generated files in .cvsignore and updated the README to note that running the script before doing anything else is entirely optional and, actually, unnecessary unless the script is updated at some point (which should be quite rare, if ever).
See: http://article.gmane.org/gmane.comp.jakarta.gump/4990. And just in case that link goes away...
suggested fix: change the javadoc comments for Xerces1, to be compliant: Manually edit the source, replacing "\\u005cu" with "\\u005c u".
Specifically, I applied the suggested fix to org.enhydra.apache.xerces.utils.regex.RegularExpression.java
Most testcase errors were due to false negatives when otherwise identical files failed to match upon a diff when the only differences were hidden characters or white space issues. I simply updated the expected template to be what was being generated. There are plenty of other cases where the differences are not so simple which will require more thought to fix.