[Laszlo-dev] For Review: Change 20100409-ptw-7 Summary: Make constraints and dependencies more debuggable and compatible

[André Bargull]

Created http://openlaszlo.org/jira/browse/LPP-8897 "Invalid delegate 
context warning for grid"


On 4/11/2010 1:56 PM, P T Withington wrote:
> [Adding Laszlo-Dev because of the wider issues raised here.]
>
> On 2010-04-10, at 02:18, Max Carlson wrote:
>
>    
>> Approved for the tests listed.  I didn't run them all in debug mode, but I see constraint warnings for
>> examples/components/component_sampler.lzx?lzr=dhtml&debug=true
>>
>> WARNING: Not creating delegate: deleted context «<text>| …/tabpane[3]/@content/anonymous/@header/@hcontent/gr…».$lzc$set_cascadedfont
>> WARNING: Not creating delegate: deleted context «<text>| …/tabpane[3]/@content/anonymous/@header/@hcontent/gr…».$lzc$set_cascadedfontsize
>> WARNING: Not creating delegate: deleted context «<text>| …/tabpane[3]/@content/anonymous/@header/@hcontent/gr…».$lzc$set_cascadedfontstyle
>> WARNING: Not creating delegate: deleted context …/@content/anonymous/@header/@hcontent/gridcolumn[2]/text.$lzc$set_cascadedfont
>> WARNING: Not creating delegate: deleted context …/@content/anonymous/@header/@hcontent/gridcolumn[2]/text.$lzc$set_cascadedfontsize
>> WARNING: Not creating delegate: deleted context …/@content/anonymous/@header/@hcontent/gridcolumn[2]/text.$lzc$set_cascadedfontstyle
>> WARNING: Not creating delegate: deleted context …/@content/anonymous/@header/@hcontent/gridcolumn[3]/text.$lzc$set_cascadedfont
>> WARNING: Not creating delegate: deleted context …/@content/anonymous/@header/@hcontent/gridcolumn[3]/text.$lzc$set_cascadedfontsize
>> WARNING: Not creating delegate: deleted context …/@content/anonymous/@header/@hcontent/gridcolumn[3]/text.$lzc$set_cascadedfontstyle
>>      
> These warnings pre-date my change.  I suggest you file a separate bug for them so we can figure out whether they are innocuous or not.  I suspect they have to do with replication.
>
>    
>> WARNING: Unable to create dependency on parent["resizer"].width for constraint …/@content/anonymous/@header/@hcontent/gridcolumn[1]/@mybutton.width='${...}'
>> WARNING: Unable to create dependency on parent["resizer"].width for constraint …/@content/anonymous/@header/@hcontent/gridcolumn[2]/@mybutton.width='${...}'
>> WARNING: Unable to create dependency on parent["resizer"].width for constraint …/@content/anonymous/@header/@hcontent/gridcolumn[3]/@mybutton.width='${...}'
>>      
> This is another one of those conditional constraints that needs to be resolved at init time.  The component is either resizable or not and the constrain is different depending on that.  (If we want to make resizability dynamic, we would have to take a different approach.)
>
> Which makes me realize, there is a third approach to these conditional constraints, which might be preferable to either of the ones described so far.  If you really need a conditional constraint, based on the state of another property, the solution is to use a state.  For example, in the case of basecomponent._enabled you could say:
>
>    <attribute name="_enabled" value="${this._enabled}" />
>    <state applied="this._parentcomponent != null"><![CDATA[
>      <attribute name="_enabled" value="this.enabled&&  this._parentcomponent._enabled" />
>    </state>
>
> This is a heavier-weight mechanism and is wasted in the case where we know the condition is determined at init time.  It also has the flaw of not respecting class or instance overrides, so could only be used for private attributes (like `_enabled`, and not for `width`, unless the component itself is private).
>
>    
>> WARNING: Unable to create dependency on this.getBGColor for constraint …/@content/anonymous/@content/@rowparent/basegridrow[2].bgcolor='${...}'
>> WARNING: Unable to create dependency on this.getBGColor for constraint …/@content/anonymous/@content/@rowparent/basegridrow[1].bgcolor='${...}'
>>      
> That looks like a real bug in the grid code.  It sure looks to me like `getBGColor` has a dependency on `regularColor` that needs to be reported.
>
> I'm not sure I need to fix every one of these warnings in this change.  Since they are not regressions, we could incrementally address them.  (Or I could just turn the new warning off and we can continue in our ignorant bliss.)
>