I will do this.
On 2006-09-18, at 11:24 EDT, Henry Minsky wrote:
> That sounds like a good approach.
>
>
> 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
