If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

JS XSLT interface does not allow returning of result tree from method

RESOLVED INVALID

Status

()

Core
XSLT
--
major
RESOLVED INVALID
14 years ago
14 years ago

People

(Reporter: Manos Batsis, Assigned: peterv)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

The current nsIXSLTProcessor implementation cripples some usability of XSLT
functionality in JS when compared to the nsIXMLProcessorObsolete. JavaScript
only allows function parameters to be passed by value, not by refference. Using
nsIXMLProcessorObsolete one could isolate transformation logic by enclosing it
in a function signature as follows:

function transformDocument(sourceDoc, xsltDoc, resultDoc)
{
   // assume nsIXMLProcessorObsolete is available
   var xsltProcessor = new XSLTProcessor();
   xsltProcessor.transformDocument(sourceDoc, xsltDoc, resultDoc, null);
   // return the *modified* result. 
   return resultDoc;
}

This works fine. However, the only way to do this using the new nsIXMLProcessor
would be something like:


function transformDocument(sourceDoc, xsltDoc, resultDoc)
{
   // assume nsIXMLProcessor is available
   var xsltProcessor = new XSLTProcessor();
   xsltProcessor.importStylesheet(xsltDoc);
   resultDoc = xsltProcessor.transformToDocument(sourceDoc);
   // return the *modified* result. 
   return resultDoc;
}

But the modifications to resultDoc are not visible outside the method now due to
the nature of the JavaScript language. So, what I'm asking for is for
nsIXMLProcessor to change, restoring the JavaScript centric usability that was
available in the obsolete interface.


Reproducible: Always

Steps to Reproduce:

Comment 1

14 years ago
One of the essential features of XSLT is that the type of the output document is
not known. Thus modifications of an existing document can not be conformant to
both the XSLT spec and the HTML spec.

Transforming into an existing document is really brittle and the expected result
is vague. Whether you want to replace parts of an existing document or add content
by XSLT is unknown to the implementation, though both are valid use cases. Thus
we introduced the transformToFragment, which gives you the level of control you
deserve while still supporting both XML and HTML output methods as good as 
possible.

It's not a bug, it's a feature. Really.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.