Patch: Using kpart's KJS::Interpreter (was Re: XML, XSL, XSLT, XPath support?)

Nikolas Zimmermann wildfox at kde.org
Tue Apr 12 00:00:34 BST 2005


On Monday 11 April 2005 23:27, Koos Vriezen wrote:
> On Sun, Apr 10, 2005 at 11:33:29PM +0200, Koos Vriezen wrote:
> > There are two issues I want to point at, and one is the
> > interp->globalObject is returned in ecma's tryGet. This means one extra
> > redirection, myembed.window.document vs. myembed.document, not sure what
> > would be preferable. Obviously, how it is now, needs hardly any code and
> > w/o it would mean to return a 'get' call on this object and likewise for
> > 'put' and 'call'.
>
> Ok, thought about it a bit more and it really makes sense to call 'get'
> on the interpreter's global object and so for 'put'. This means it would
> become (so w/o the 'window' redirection):
>   document.applets[0].document.firstChild.lastChild.innerHTML
> This means that this is exactly how it is with frames. Maybe one
> might be able to merge some of it, but no intension atm.
> For 'call' it doesn't make really sense, only if a part has one function
> as global object. Likewise for 'toString', one want still see the
> '[object HTMLObjectElement]' and not the attached object I think.
>
> So this is a more powerful liveconnect than we have now, like member
> iterations, cross document possibilities etc.
> Shall I just commit this (see attachment)?
>
> > Koos
Hi Koos,

I'm also impressed :) Great work ...
I'll look at a kdom backport in the next days.

Though a tiny nitpick: (Line 159 and 173)
KHTMLView *view = static_cast<DOM::DocumentImpl*>(doc.handle())->view();

doc.handle() could be null, a simple if doc.isNull() check
should prevent any possible weird circumstances :-)

Bye
 Bye
  Niko




More information about the kfm-devel mailing list