Custom Query (18300 matches)


Show under each result:

Results (4 - 6 of 18300)

1 2 3 4 5 6 7 8 9 10 11 12
Ticket Resolution Summary Owner Reporter
#2204 add async property to src/xml/XslTransform.js Tom Trenka guest

I should have provided this in the original version, so after some posts to the mail list I would like to get this into the src. Basically you can set the async property of a transformer. I have defaulted this to false so an XSL will be loaded before applying a transformation (I believe this to be the most common need). But, if you need an async load, then set the property to true. OK?

#2379 resetting stylesheet parameters for IE in dojo.xm.XslTransform Tom Trenka guest

The current implementation of dojo.xml.XslTransform?'s removeIeParams is not working properly, since previously set stylesheet parameters for a processor object are simply set to an empty string if cleared/reset afterwards, e.g. :

processor.addParameter("myparam", "");

This would not take into account any default values set in a stylesheet for this parameter, e.g. :

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0"

xmlns:xsl=""> <xsl:output method="html" indent="yes"/>

<xsl:param name="myparam">myvalue</xsl:param> .... </xsl:stylesheet>

The only way to clear/reset any previously set parameters for a stylesheet/processor, is (unluckily) to create a new processor via the ownerTemplate, e.g. :

processor = processor.ownerTemplate.createProcessor();

This will create a new processor with no parameters set so far from the owner template (cached stylesheet). This has been tested by me and it works (means: previously set parameters are cleared in a way that any stylesheet default values are taken again).

I'm aware that this might be an expensive operation that would probably decrease the benefits from caching a processor object, but up till now I found no other solution to reliably reset/clear stylesheet parameters. Using "transformNode" isn't an option as per my opinion, since no support for parameters :-(


#2380 firefox dom/xml serialization/deserialization bug Tom Trenka guest

I recently detected a bug in mozilla's/firefox dom/xml serialization/deserialization, that could effect the dojo framework - I actually found 5 occurances in the dojo package where mozilla's / firefox 's XMLSerializer.serializeToString method is used that could result in unexpected behaviour, if the serialized string is used to set the "innerHTML" attribute of a dom node. I did not follow up each and every piece of the dojo code to see if this bug actually is causing a problem, but I felt that possibly many users should be aware of this bug to avoid/work around it in their own script implementations.

I detected that this bug comes into play with the dojo.xml.XlsTransform? package.

I already posted this bug along with a test case and a possible resolution under

Here is what goes wrong :

  • a common coding approach is to render the result of a xslt-transformation by serializing it using the firefox built-in XMLSerializer and then apply it to the "innerHTML" attribute of a dom node
  • unfortunately, in case of empty elements, the built-in XMLSerializer of firefox uses the none-w3c-compliant short syntax ( e.g. <tag .../> ) instead of explicitly closing each tag (e.g. <tag ...></tag>)
  • if applying the output of XMLSerializer to the "innerHTML" attribute this results in empty elements being nested instead of being on the same tree-level (see my test case following the link mentioned above), due to the fact that the short syntax to close a <tag> is not correctly handled by the firefox xml parser
  • a possible resolution to this would be not to serialize the transformation result and apply it via "innerHTML", but to simply append/replace it via a simple dom operation (see my test case following the link mentioned above)

Hope that some of you find this interesting and helpful - at least I did not expect such a major bug in mozilla/firefox and I think everyone agrees that a string serialization of a xml/dome node being deserialized again should create the same object as before.


1 2 3 4 5 6 7 8 9 10 11 12
Note: See TracQuery for help on using queries.