Closed Bug 90157 Opened 23 years ago Closed 22 years ago

Improve upon IE transformNode() extension

Categories

(Core :: XSLT, enhancement, P5)

Product:
Core
Component:
XSLT
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2alpha

People

(Reporter: xyzzy, Assigned: peterv)

References

(
URL
)

Details

Attachments

(2 files)

interfaces
7.21 KB, patch
Details | Diff | Splinter Review
transforms an xml document to an html form
3.86 KB, text/plain
Details 
I am developing an application that needs to read a subset of a large XML file 
and transform it on-the-fly to generate a dynamic page.  This is all dependent 
on a user selection.

As far as I can tell, the best way to support this functionality is 
with transformNode().  Please let me know if there are alternatives or 
workarounds.
Sorry, this is probably more appropriate for the DOM folks...
If transformNode() is not part of the W3C specs, it's unlikely to be supported...
This is a valid RFE, confirming. We should and will support this somehow, but 
I'm not really sure if I like IEs syntax. The advantage would be compability 
with IE though...
Status: UNCONFIRMED → NEW
Ever confirmed: true
My concerns are:

1) The functionality is there
2) All specs are followed

Since this is not yet part of any DOM spec, by all means, innovate!  I'd rather 
have the Mozilla idiom set the standard.
I'm not sure the functionality is there yet, but I don't know all the specifics
of the IE method. You are aware that we have transformDocument?
Assignee: kvisco → peterv
Priority: -- → P4
Target Milestone: --- → mozilla1.0
Let's get this straight. The functionality isn't there. Generating the page on 
the fly looks like you want to use js to display the result.
Nogo, this is bug 56087.

Axel
My understanding of transformDocument is that it transforms from a document to a 
document.  But does this allow one to transform from a document fragment to a 
document fragment?

If transformDocument handles fragments, I agree, this is bug 56087.  Otherwise, 
I'm happy to call it an RFE.
Could you set the URL to a documentation of transformNode()?
That way poor folks like me who can't run ms products can evaluate this

Thanx

Axel
Quoting from the doc:
strValue = oXMLDOMNode.transformNode(objStylesheet);
Yes, STRING. And then they use innerHTML to display this. hihihi. oh sorry.

Peter, you're module owner, I leave the wontfix up to you.

Axel
URL: http://msdn.microsoft.com/library/def...
Priority: P4 → --
Target Milestone: mozilla1.0 → ---
Beat me to the URL by a minute or two...  I didn't realize there was a field or 
I'd have done it from the start.

Clearly, String and innerHTML are a bad idea.  I agree that the syntax 
stinks.  If it returns a fragment of the resultant DOM tree, it will be closer 
to what I need anyway.
Priority: -- → P5
Updating summary.  Don't copy IE, improve upon it.
Summary: [RFE] Support for IE transformNode() extension → [RFE] Improve upon IE transformNode() extension
Target Milestone: --- → Future
Not sure if this should be dupped of or just depend on bug 46633
Depends on: 46633
No longer depends on: 46633
stripping bugs apart. This is the bug about a [script] interface to XSLT.
We're not intending to kill nsIDocumentTransformer, but we never encouraged
the use of it in scripting either. This bug is supposed to give us something
we wanna encourage people to use.
This bug is including a fix to bug 70369, argh, deps don't cut it.
Keywords: mozilla1.0
Target Milestone: Future → mozilla1.0
*************************************************************************
*** Note for drivers:
***
*** If someone comes up with a fix for this soon, please do not 
*** wave it off to post-1.0 if at all possible. This is _the_ bug
*** people are demanding on the newsgroups, check e.g. n.p.m.xml
*** and n.p.m.layout.xslt . And IE has this.
*************************************************************************
Note that the ability to output a string containing HTML allows them to use this
server side where the HTML is written to the output document.

In addition it possibly allwos their downlevel browsers to call their ActiveX
impl and have it return a string of HTML and then allow the downlevel browser to
simply set the innerHTML.

Both approches are useful to them and you can expect to seem them in the wild.

Note that they have another method which does result in a Node output:

oXMLDOMNode.transformNodeToObject(stylesheet, outputObject);

http://msdn.microsoft.com/library/en-us/xmlsdk30/htm/xmmthtransformnodetoobject.asp

Without this functionality, however it is exposed, consider how an author would
implement it on their own.


Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Attached patch interfaces — — Splinter Review 
Here are the two interfaces.
I don't think the interfaces should go to extensions/transformiix, and they're
not DOM so they ended up in content/xsl/public.

Note: I won't have time to implement this.
setParameter should throw an exception if
 - init hasn't been called sucessfully
 - or the given expanded name is not a parameter of the given stylesheet.
We must not pass in data that is not tunneled by a global paramater (top level
xsl:parameter instruction)
Keywords: mozilla1.0
This bug seems to be dead. I just wanted to say that I really care about this
feature - it's something crucial if I want to use XSLT in my applications, and
run them in Mozilla.
the design for bug 90157 and bug 130161 need to worship each other.
Esp. one needs the creation of the document during the transform, the other
needs to work on an existing document.
Depends on: txbranch
<sicking> i really think we should return a node instead of a DocFragment
<sicking> so that if you specify a null outputdoc we create the doc and 
          return that

I don't like the idea of having a return value of separate meanings.
If we want a method to return a new document, equivalent to what (will) 
happen(s) on PI in content, then we should add another method.

IMHO.
I have developed many web applications that create content dynamically from XML
documents stored in memory through Javascript on IE. I would love to do the same
with Mozilla. But with Mozilla, I could create much better applications thanks
to XUL.

I have also written a simple Java applet that has a transfromNode method that I
can call from Javascript in Mozilla.

I will attach an example xsl file to demonstrate its usefulness.

This file is used to take an xml document which represents a "timeslip"
(obtained through XMLHttpRequest from a SOAP server) and transform it into a
html form. The output is equivalent for msxml (IE browser) and Java + Mozilla.

Here is an example timeslip:

<timeslip xmlns:netpos="http://www.netpos.com" timeslip_id="1" store_id="2001"
start_time="1032209986" end_time="" modified="1032209986" terminal_number="1"
in_manager_id="" money_in="" out_manager_id="" money_out="" employee_id=""
job_id="" cash_tips="" />
<worker xmlns:netpos="http://www.netpos.com" type="terminal" timeslip_id="1"
><terminal enable_pht="false" mode="crmode" name="front" number="1"
store_number="1"/></worker>
Summary: [RFE] Improve upon IE transformNode() extension → Improve upon IE transformNode() extension
fixed with the branch-landing. We should make an announcement in the newsgroups
what the new interfaces look like. And fix the project page
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
mass verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: