On 9/18/06, Adam Wolff <[EMAIL PROTECTED]> wrote:
Don't know if this was already discussed, but my preference would be to
put an empty hash on the LzNode prototype. Then setOption could test for
it and initialize the slot with a new hash before setting only if
this.options == LzNode.prototype.options. Most nodes don't have options,
so it's really a waste to give an empty hash to each one.
A
On Sep 18, Henry Minsky wrote:
> Did we ever put in a patch for this?
>
> The simplest one would be
>
> var options = {};
>
> in LzNode.lzs I guess.
>
> The other alternative would be to rewrite the callers to use getOption() ,
> which checks for null, instead of
> directly accessing the options slot, but that would cost a function call...
>
>
> On 9/15/06, P T Withington <[EMAIL PROTECTED]> wrote:
> >
> > One work-around is to initialize the options slot in the initialize
> > method of the class LzNode, that will ensure that each instance has
> > it's own hash. There is a possibility that could be an efficiency
> > issue if most nodes don't have options.
> >
> >
> > On 2006-09-15, at 10:51 EDT, Henry Minsky wrote:
> >
> > > I would just be careful about making sure that the object which is
> > > created
> > > is not shared among multiple instances; in other words
> > > the initializer for the instance needs to make a new object.
> > >
> > > We had an issue like this with the subnodes or subviews array early
> > > on, I
> > > forget how we solved it, I am remembering something
> > > about how the accessor
> > > method for adding child views checked if it was an empty array ,
> > > and if it
> > > was trying to add an entry to the empty array, it created a new
> > > array. So
> > > the default empty array was shared among all instances of view but
> > > a fresh
> > > object was consed up the first time it was needed.
> > >
> > >
> > >
> > > On 9/15/06, Philip Romanik < [EMAIL PROTECTED]> wrote:
> > >>
> > >> Hi Henry,
> > >>
> > >> I started looking at his a little bit at this issue. I bypassed the
> > >> initial
> > >> error and ran into something else. The component code expects that
> > >> the
> > >> options property to be non-null.
> > >>
> > >> For example, in basewindow.lzx:
> > >>
> > >> <method name="construct" args="parent,args">
> > >> var wlist = parent.options['windowlist'];
> > >> if (wlist == null || typeof wlist == "undefined") {
> > >> wlist = [];
> > >> parent.setOption('windowlist', wlist);
> > >> }
> > >> super.construct(parent,args);
> > >> </method>
> > >>
> > >>
> > >> this is failing because parent.options is null. In LzNode.lzs,
> > >> options is
> > >> null until someone calls setOption() for the first time. Is this an
> > >> efficiency, or can this line in LzNode,
> > >>
> > >> var options = null;
> > >>
> > >> be changed to,
> > >>
> > >> var options = {};
> > >>
> > >> Many variables in the lfc are initialized to null. I wonder if
> > >> this will
> > >> become a common theme as the components are brought up.
> > >>
> > >> I changed it on my machine and was able to get much further, until
> > >> the app
> > >> hit another issue.
> > >>
> > >> Phil
> > >>
> > >>
> > >> >They're all in! Try the window example - it seems to fail in a
> > >> similar
> > >> >way...
> > >> >
> > >> >-Max
> > >> >
> > >> >Henry Minsky wrote:
> > >> > > Did you check those resources in? I can try and see what bug is
> > >> > > halting
> > >> > > the interpereter.
> > >>
> > >>
> > >
> > >
> > > --
> > > Henry Minsky
> > > Software Architect
> > > [EMAIL PROTECTED]
> >
> >
>
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
