So maybe we should have a sentinel parentNode object? Or set parent to the element itself at construct time (probably
not a good idea)
===================================================================
--- LzDataText.lzs (revision 1514)
+++ LzDataText.lzs (working copy)
LzDatapointer.prototype.selectNext = function ( amnt ) {
amnt = amnt ? amnt : 1;
var np = this.p;
while ( amnt-- ){
+ if (!np) return false;
np = np.getNextSibling();
}
if ( np == null ){
return false;
} else {
this.setPointer( np );
return true;
}
}
===================================================================
--- LzDataText.lzs (revision 1514)
+++ LzDataText.lzs (working copy)
@@ -24,6 +24,13 @@
);
+DeclareEvent(LzDataText.prototype, 'onDocumentChange' );
+DeclareEvent(LzDataText.prototype, 'onparentNode' );
+DeclareEvent(LzDataText.prototype , 'onchildNode' );
+DeclareEvent(LzDataText.prototype, 'onchildNodes' );
+DeclareEvent(LzDataText.prototype, 'onattributes' );
+DeclareEvent(LzDataText.prototype, 'onnodeName' );
+
Index: LzDataNode.lzs
===================================================================
--- LzDataNode.lzs (revision 1514)
+++ LzDataNode.lzs (working copy)
@@ -41,6 +41,7 @@
// @return LzDataNode: The node preceeding this one in this node's childNodes
//------------------------------------------------------------------------------
LzDataNode.prototype.getPreviousSibling = function (){
+ if (!this.parentNode) return null;
if ( this.parentNode.__LZcoDirty ) this.parentNode.__LZupdateCO();
return this.parentNode.childNodes[ this.__LZo - 1 ];
}
@@ -57,6 +58,7 @@
// @return LzDataNode: The node succeeding this one in this node's childNodes
//------------------------------------------------------------------------------
LzDataNode.prototype.getNextSibling = function (){
+ if (!this.parentNode) return null;
if ( this.parentNode.__LZcoDirty ) this.parentNode.__LZupdateCO();
return this.parentNode.childNodes[ this.__LZo + 1 ];
}
Index: LzDataElement.lzs
===================================================================
--- LzDataElement.lzs (revision 1514)
+++ LzDataElement.lzs (working copy)
@@ -291,6 +292,7 @@
// @return number
//------------------------------------------------------------------------------
LzDataElementTrait.prototype.getOffset = function (){
+ if (!this.parentNode) return 0;
if (this.parentNode.__LZcoDirty ) this.parentNode.__LZupdateCO();
return this.__LZo;
@@ -349,7 +351,9 @@
this.nodeName = name;
//since this can affect xpaths, send onchildNodes event
this.onnodeName.sendEvent( name );
- this.parentNode.onchildNodes.sendEvent( this );
+ if (this.parentNode) {
+ this.parentNode.onchildNodes.sendEvent( this );
+ }
this.ownerDocument.handleDocumentChange( "childNodeName" ,
this.parentNode , 0 );
this.ownerDocument.handleDocumentChange( "nodeName" , this, 1 );
On 8/9/06,
P T Withington <[EMAIL PROTECTED]> wrote:
I thought DHTML would only give a fatal error for referencing a non-
existent property. Maybe you just need to spiff up the class to
actually declare all its properties (and initialize them to `null`)?
On 2006-08-08, at 21:23 EDT, Henry Minsky wrote:
> I am in the process of merging some swf and DHTML code in the LFC,
> and have
> a question about the following
>
>
> The lztest package is actually starting to work in DHTML, but some
> of the
> tests on data elements are failing. The usual
> failure mode is an error in a data API method with an unbound slot
> such as
> "parentNode", which is an artifact of the test case which constructs
> orphan nodes for test purposes, so they generally don't have all
> their slots
> bound. This silently fails in swf, but causes hard errors
> in DHTML interpreters.
>
> The question is whether I should modify the tests to create more fully
> instantiated nodes, or whether I should put more error
> checking into all the API method to check for null values on slots
> before
> referencing properties on them or sending events. The
> error checking could have 'if ($debug)' clauses to warn about
> uninitialized
> slots, or it could silently proceed in the way that
> swf code does now. Anyone have an opinion on this? The only reason
> not to
> put checks in would be that it could cause
> some performance penalty, and will also bloat the code some more.
>
>
> --
> Henry Minsky
> Software Architect
> [EMAIL PROTECTED]
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
