According to my treatise on how node initialization works (google for "Summary of current LzNode initialization) your parent should have all of its attributes initialized before you get created (but note that if your parent has a constrained attribute, that attribute could change).
On 2008-03-15, at 14:14 EDT, Henry Minsky wrote:
I have a question about this other 'once' constraint , the one on 'datapath':<text visible="${!parent.editing}" width="${parent.width}" resize="false" y="${ parent.height /2 - this.height/2}" fgcolor="${ parent.immediateparent.selected ? classroot._textselectedcolor:(parent.immediateparent.highlighted ? classroot._texthilitecolor:classroot._textcolor)}" datapath="$once{parent.parent.rowdp}"> Is there reason to believe that that 'once' constraint will work, because it is pointing to an object that shoudl already be instantiated? Is the 'datapath' slot of the parent (or parent.parent) guaranteed to hold an instance of datapath by the time the child 'datapath' setter is called?On Sat, Mar 15, 2008 at 11:31 AM, P T Withington <[EMAIL PROTECTED]> wrote:I think unless you want to do a dependency analysis by hand, you have to use constraints. That's the mechanism we provide for handling general dependencies. If you recall, we ran into a bunch of similar cases when we added DHTML because for-in loops traversed objects in a different order.On Mar 15, 2008, at 8:39, "Henry Minsky" <[EMAIL PROTECTED]> wrote:I will change this to be an "always" constraint.But I have a question, in general, if you wanted to set a view to havea y-offset be some function of another attribute value, and if the order of initialization of attribute values is undefined, then aside from an "always" constraint, what is the most efficient way to do that? Put an assignment of the value into the "oninit" method? On Sat, Mar 15, 2008 at 8:12 AM, P T Withington <[EMAIL PROTECTED]> wrote:Since the ordering of initialization is not specified (other than the special early/late setters in node/view) I could believe that the newmechanism could break some fragile constraints. I guess we have to askif a once constraint makes sense here? I don't think it does becauseonce constraints do not analyze dependencies. On Mar 14, 2008, at 22:48, "Henry Minsky" <[EMAIL PROTECTED]> wrote:The constraint that is being computed wrong appears to be here in lz/gridtext.lzx<text visible="${!parent.editing}" width="$ {parent.width}"resize="false" y="$once{ parent.height /2 - this.height/2}" ^^^^^^^^^^^^^^^^^^^^ fgcolor="${ parent.immediateparent.selected ? classroot._textselectedcolor: (parent.immediateparent.highlighted ? classroot._texthilitecolor: classroot._textcolor)}" datapath="$once{parent.parent.rowdp}"> </text>If I change the y constraint from a "once" to an "always", then thetext centers properly. So in that change, the order in which the once constraint gets computed must have moved to a different time relative to the computing of this.height and parent.height. Here's the simple test case I am using: <canvas width="800" bgcolor="0xeaeaea"> <dataset name="weatherdata"> <weather> <current> <tag1>Some text</tag1> <tag2>Some more text</tag2> </current> </weather> </dataset> <grid width="300" height="100" showvlines="true" sizetoheader="false" datapath="weatherdata:/weather/current" /> </canvas> On Fri, Mar 14, 2008 at 7:11 PM, Henry Minsky <[EMAIL PROTECTED]> wrote:Max's binary search tool pins this regression on this change. Maybethe positioning of the text in the grid cells is defined by some constraint. I'm trying to make a simple test case out of the grid_example.lzx app. --- --- ------------------------------------------------------------------ r8032 | ptw | 2008-02-14 17:57:01 -0500 (Thu, 14 Feb 2008) | 65 lines Change 20080208-ptw-T by [EMAIL PROTECTED] on 2008-02-08 08:18:39 EST in /Users/ptw/OpenLaszlo/ringding for http://svn.openlaszlo.org/openlaszlo/trunk Summary: Unify argument initialization Bugs Fixed: LPP-1587 'ECMA4: Compile LZX declarations as JS declarations' (partial) LPP-631 'can't override a constraint with a literal with state attributes' Technical Reviewer: [EMAIL PROTECTED] (Message-ID: <[EMAIL PROTECTED]>) QA Reviewer: [EMAIL PROTECTED] (pending) Details: Initial values, initial expressions ($once, $path, but not $style, yet), and constraints ($always), now are created as a unified list in the tag compiler solving several issues with overriding/inheritance of attribute values and constraints and enabling the solution to an issue with states and constraints. TextStprite: Update test for constraint on width or height. LzNode, UserClass: Simplify attribute inheritance/override computation,maintain backward-compatible magic-merge of attribute values (fornow). LzNode: Update documentation of `construct` to note that constraints are now unified in `args`. __LZapplyArgs uses new args organization to sort out initialization expressions and constraints. __LZresolveReferences uses the new information to run initialization expressions and install constraints. __LZresolveRefs no longer needed. applyConstraint deprecated, but backward-compatible. New interface: applyConstraintMethod. Private releaseConstraint did not work, removed. New interface: releaseConstraintMethod.LzDefs: Turn LzDeclaredEvent into a singleton class. Add privatesupport classes LzInitExpr and LzConstraintExpr. LaszloView: Update test for constraints. Fix setAlign and setValign to work with constraint methods, and to correctly work if alignment is changed (to release previous constraint). LaszloCanvas: Update __LZcallInit to parallel LzNode more closely. LzState: Update capturing of held args and constraints. Use this new organization to release constraints the state will override (and re-apply them when the state is removed). Remmove unused __LZstoreRefs. LzReplicationManager: Fix xpath constraint to work with constraint methods. Function.java: Make Function#name public. NodeModel.java: Coalesce $once, $path, $always into single arglist, distinguishing 'binders' by internal type, either LzInitExpr or LzConstraintExpr. Tests: smokecheck, amazon, most-components --- --- ------------------------------------------------------------------ badtzmaru:trunk2 hqm$ On Fri, Mar 14, 2008 at 4:07 PM, Henry Minsky <[EMAIL PROTECTED]> wrote:In trunk, the grid_example.lzx is showing the rows with the text aligned improperly (looks like it is offset too far in the y direction). This regression doesn't appear in the pagan-deities branch. -- Henry Minsky Software Architect [EMAIL PROTECTED]-- Henry Minsky Software Architect [EMAIL PROTECTED]-- Henry Minsky Software Architect [EMAIL PROTECTED]-- Henry Minsky Software Architect [EMAIL PROTECTED]-- Henry Minsky Software Architect [EMAIL PROTECTED]
