[Laszlo-dev] Constraints, dependencies, and LzEventable

[André Bargull]

On 4/8/2010 12:27 AM, Max Carlson wrote:
> On 4/7/10 1:52 PM, P T Withington wrote:
>> On 2010-04-07, at 16:23, Max Carlson wrote:
>>
>>> On 4/7/10 12:58 PM, P T Withington wrote:
[...]
>
>> Finally, we can't do it only for debug mode unless you want the
>> situation that started me down this path -- the user who complained
>> that his app works in debug mode (which catches and neuters all
>> errors) but fails when he turns off debugging. I think we want to
>> always catch and ignore these errors (because that is the LZX way,
>> inherited from swf8). We just need to decide if we _always_ want to
>> warn about these, or if we want a special 'debug constraints' mode
>> that turns on these warnings.
>
> Right, got it.

I disagree with Tucker. I think we want to propagate this development style:
First write the application and run it in debug mode, then resolve all 
errors reported in the debugger and finally test and deploy your 
application in non-debug mode.
Therefore non-debug code should be made as fast as possible, only debug 
code should catch errors and provide users with appropriate (!) messages 
to find the errors and give hints how to handle them.
For example the following application works perfectly in swf8 (debug and 
non-debug mode), but it fails for swf9+/dhtml in non-debug mode. So 
Tucker's statement about "always catch and ignore .. errors" isn't even 
our current development strategy.

<canvas>
   <script>(new Object).bla();</script>
   <text>This text is only created if the script error is handled</text>
</canvas>


>>>> The question is: when you constrain to function that does not have a
>>>> dependencies method, should you get a warning (because you might
>>>> wonder why your constraint does not update) or should it silently
>>>> succeed (because that is what happens in swf8 and DHTML right now)?
>>>
>>> It seems like you might want to be able to constraint to arbitrary
>>> functions and have the event system default to lz.Idle.onidle as a
>>> dependency. There should still be a warning in debug mode, so folks
>>> know to update this for efficiency.
>>
>> I would rather make there be a way for people to write the dependency
>> method for an arbitrary function.
>
> Sounds fair. I'll file an improvement for this.

1+ for the improvement request.

Concerning Tucker's initial question whether constraints to function 
without a dependencies method should generate a warning:
I've attached a lzx-application which demonstrates the usage of 
<mediastream> and <videoview>. The application uses a simple class 
(<ftext>) to show formatted text. In that <ftext> class, a constraint on 
a "_format()" method is created, "_format()" works as a trampoline for 
the inherited "formatToString()" method. In this use case I don't want 
to see any warnings. (And neither a dependency to onidle.) This seems to 
be the expected behaviour, too. If you search for 
/\${[^}]*[a-zA-Z]+\([^}]*}/ in the components directory, you'll get over 
60 hits. Inspecting these constraints reveals that many of them use 
functions of the Math object. And the Math object clearly doesn't have 
any dependencies methods.
(If you wonder why I needed to add the "_format()" method, well, guess 
what happened in swf9+ when I used this constraint 
"${this.formatToString.apply(...)}" ;-) )


>>>> Also, while trying to make the error message that you get more
>>>> useful (by telling you which constraint it is that is not getting
>>>> its dependencies right), I notice that we get a pile of "failed"
>>>> dependencies already, that are just silently ignored. These seem to
>>>> come from dependencies that perhaps are evaluated too soon and hence
>>>> the context of the event they want to listen to does not yet exist.
>>>> It seems we might want to get a warning on those too?
>>>
>>> That would be great!
>>
>> Again, the question is whether we want to do this always, or have a
>> mode for it.
>
> It sounds like there should be a mode for this to keep from being
> flooded by warnings - but that could be added as an improvement later,
> perhaps with the special 'debug constraints' mode you mentioned above.

Without further information about the failed constraints, I'd say that 
any constraint with an invalid reference should be reported as an error 
to the user. But sometimes sloppy dependencies methods are expected by 
the users, see LPP-6594...
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: LPP-8850.lzx
Url: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20100408/45266115/LPP-8850.pl