I'll give you the same provisional approval I gave Max:
Please file a bug to track why/how layout's class can be the string
'null'. This needs to be fixed. The convention for when you have
'papered over' a bug in this manner is to put:
// FIXME: [2006-09-25 ben] (LPP-NNNN) This bogus check can be removed
when the underlying bug is fixed
or something like that. The main point is to put the bug number in
parens after the date/signature, also, in the bug, note that the bug
has been papered over in LaszloView and that needs to be cleaned up
when the bug is fixed.
---
I see that you have been very careful to preserve the type signatures
of the .p functions when p is null. That seems like a reasonable
idea, but if you want to be compatible with the existing Flash
runtime semantics, I think you should be returning undefined in each
of these cases. (which should be achieved by either saying `return;`
or `return void null;`).
I wonder whether calendar will run if you return undefined in these
cases? If not, it seems there is a larger issue: why is the
application calling these interfaces when .p is not defined? Should
it be? What is the real contract of the Data API? Perhaps you could
ask Adam (the designer) for some advice here, on whether these API's
should be returning a type-safe 'null' value (i.e., null, "", and 0)
or whether they should be returning a sentinel 'null' value (i.e.,
undefined).
If you don't have time to tackle this larger issue now, I'll just ask
that you file a bug about it and annotate your changes with the bug
number as described above.
Sorry to be such a pain, but if we have any hope of supporting
runtimes with stricter typing, we need to address these issues.
On 2006-09-25, at 16:16 EDT, Benjamin Shine wrote:
> Change change.XXXXXXXXX.pQ28Rdzs.txt by [EMAIL PROTECTED] /Users/ben/
> src/svnchanges/ on 2006-09-25 13:09:09 PDT
>
> Summary: Check for null property before using property
>
> New Features:
>
> Bugs Fixed:
> calendar demo is closer to working
>
> Technical Reviewer: ptw
> QA Reviewer: (pending)
> Doc Reviewer: (pending)
>
> Documentation:
>
> Release Notes:
>
> Details:
> swf is lenient about calls to foo.bar.lum when foo.bar does not
> exist. DHTML does not handle calls like that. LzDatapointer.lzs has
> many places where it assumes this.p is non-null. This is not a safe
> assumption, so I have put guards in LzDatapointer methods to check
> for null this.p, and do a no-op if a call to this.p.something would
> fail.
> LzNode.lzs has the same sort of change, except that it checks for
> non-null on this.immediateparent before getting a property of
> this.immediateparent.
> LaszloView.lzs has the mysterious hack submitted in earlier
> changeset by Max, for the odd case when classname is the string "null"
> - if ( classname == null ) {
> + // why would this be 'null' instead of null?
> + if ( classname == null || classname == 'null' ) {
>
> This patch includes some of the work in proposed change
> change.SV2sD4VYi.txt by max, which has not been checked in. This
> patch is necessary to run calendar.
>
>
> Tests:
>
> Files:
> M WEB-INF/lps/lfc/core/LzNode.lzs
> M WEB-INF/lps/lfc/views/LaszloView.lzs
> M WEB-INF/lps/lfc/data/LzDatapointer.lzs
>
> <patch.ben.u4BN.tgz>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
