The class <mynode> from my example extends directly from <node> (aka
LzNode), so without the additional determinePlacement() definition it'd
throw the same error in __LZinstantiationDone(). Basically I'm just
saying that the declarative order in the lzx-file may not be present in
the exact same way at runtime. Therefore compile-time checks aren't
feasible and must be deferred to runtime.
On 1/28/2011 6:02 PM, Raju Bitter wrote:
André, by "node" I mean an object of LzNode, which cannot have any
view children, since the functionality to add subviews is missing. So
I'm talking strictly about a structure like this:
<canvas debug="false">
<node>
<view />
</node>
</canvas>
For the DHTML runtime, you'll get a JavaScript error in
LaszloView#__LZinstantiationDone ():
/**
* Called when the view itself and all its children have finished
* instantiating.
* @access private
*/
override function __LZinstantiationDone () : void {
var vip:LzView = (this.immediateparent cast LzView);
if (vip) {
(vip).addSubview( this );
}
super.__LZinstantiationDone();
}
In that case, in DHTML runtime a call is made to addSubview(), which
of course fails since LzNode doesn't own that function.
On Fri, Jan 28, 2011 at 5:35 PM, André Bargull<[email protected]> wrote:
We cannot emit a compile-time warning due to possible dynamic placement
changes at runtime. For example a<node> may contain several<view>s, but in
its determinePlacement() method, the<node> will change the immediate-parent
for the<view>s, so they're properly attached to another<view>.
Simple example to underline my concern:
<canvas>
<class name="mynode" extends="node" defaultplacement="whatever">
<method name="determinePlacement" args="aSub, placement, args">
return canvas;
</method>
</class>
<mynode>
<!-- the view will be attached to the canvas -->
<view width="50" height="50" bgcolor="blue"/>
</mynode>
</canvas>
Guess the compiler would have to throw an error when a subclass of
node uses a mixin which contains views. But then, I just realize that
the compiler doesn't warn if you add a view to a subclass of node when
not using a mixin. What should the compiler do in such a case?
Yeah there ought to be a warning either at compile time if possible or at
runtime
if a view is a child of a non-view parent. Perhaps in debug mode we could
have a runtime check. File an improvement request in Jira?
--
Henry Minsky
Software Architect
hminsky at laszlosystems.com
