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 have
a 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 new
mechanism could break some fragile constraints. I guess we have to ask
if a once constraint makes sense here?  I don't think it does because
once 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 the
text 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. Maybe
the 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 (for
  now).

  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 private
  support 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]

Reply via email to