Thanks for the commentary, Tucker. I do appreciate the symmetry with
the other kinds of constraint expressions, and that does somewhat
blunt my worries about adding more init-time complexity for component
and application developers. But I still think the init-time
complexity is bad -- and this opinion comes from studying the
components: there are many cases in there where code is moved
artificially earlier in the construct/init sequence to come before
other code, creating a sort of compression of code at the earliest
phases of the process. This is particularly troubling since
replication pooling relies on a separation between construction and
initialization -- the need to cleanly re-initialize can be in
conflict with the requirement that code be executed early enough to
resolve dependency problems.
I also think there's the potential for newbie confusion -- folks may
well assume that the $style constraint is an $always constraint, and
lose time to learning that this is not so.
I guess my preference is to choose simplicity over symmetry, and
declare that $style constraints are always interpreted as strings. In
order to leave the door open and maintain syntactic consistency, we
should (at some cost to writability and readability) require quotes.
So the `height` case in your example would remain the same, and the
styleWidth case would be unsupported.
jim
On Aug 23, 2006, at 3:23 PM, P T Withington wrote:
> I believe there are two different issues being conflated:
>
> 1) What is the representation of a CSS style value in Javascript.
>
> 2) Whether $style constraints should be expressions.
>
> From our earlier conversation, I conclude the answer to 1) is that
> a style value must be simply represented as a string, since each
> site interprets the style value in a (potentially) special way.
> There is no uniform type across all style values. Concrete example:
>
> [CSS]
> font-family: "New Times Roman", serif;
>
> [Javascript]
> { 'font-family': '"New Times Roman", serif' }
>
> ---
>
> As for 2), in this change, I implemented $style constraints as
> expressions simply because all other constraints (including $path)
> are expressions. A $style constraint does not contain a CSS style
> _value_, it is a CSS style _attribute_ -- it says that the LZX
> attribute's value will be constrained to the CSS style attribute's
> value. In my example, the view `height` attribute is constrained
> to have the value of the CSS `height` attribute (that is applicable
> at that point according to the cascading rules). The view `width`
> attribute is constrained to have the value of the CSS attribute
> that is named by the view attribute `widthStyle`. Whether this
> flexibility is useful or not, I don't say. I just implemented it
> that way for uniformity.
>
> NOTE! The $style constraint as implemented is _not_ an $always
> constraint. It is _not_ the case that if I change the value of
> `widthStyle` at run time the CSS constraint will be updated or
> anything. (This is what I don't like about the mixture of
> constraint specifiers, there are really several dimensions rolled
> up here...)
>
> On 2006-08-23, at 17:50 EDT, Jim Grandy wrote:
>
>> I guess I don't understand the need for the style name indirection.
>> Doing this sort of evaluation adds complexity to the construct/init
>> sequence and forces certain kinds of code earlier into that sequence.
>> Can someone explain the use case?
>>
>> (And by the way, this checkin resolves my confusion, expressed in
>> private correspondence over why the need to evaluate at all. I still
>> think it's potentially a bad idea, but I no longer think you want to
>> create CSS property values by looking up JavaScript variable bindings
>> at runtime.)
>>
>> jim
>>
>> On Aug 22, 2006, at 12:11 PM, P T Withington wrote:
>>
>>> Change change.7sdt5h8wX.txt by [EMAIL PROTECTED] /Users/ptw/
>>> pending-changes/ on 2006-08-22 14:50:20 EDT
>>>
>>> Summary: Parse $style constraints
>>>
>>> New Features:
>>>
>>> <view height="$style{'height'}" width="$style{widthStyle}">
>>> <attribute name="widthStyle" value="'width'" />
>>> </view>
>>>
>>> will be parsed and generate an internal method `$style` with the
>>> following definition:
>>>
>>> function () { with (this) return {height: 'height', width:
>>> widthStyle}}
>>>
>>> which can be invoked by CSSApplyStyle to build the style map. Note
>>> that style constraints are expressions that will be evaluated in the
>>> instance's context, cf., the definition of width above.
>>>
>>> Bugs Fixed:
>>> [Ben: is there a bug number for this work?]
>>>
>>> Technical Reviewer: hminsky (pending)
>>> QA Reviewer: ben (pending)
>>> Doc Reviewer: adam (pending)
>>>
>>> Details:
>>> Add a new 'when' case `style`. Accumulate them in a map.
>>> Convert that map to a function that will return a Javascript
>>> hash
>>> representation of the map.
>>>
>>> Tests:
>>> Visually inspected the output of lzx --script
>>>
>>> Files:
>>> M src/org/openlaszlo/compiler/NodeModel.java
>>>
>>> <patch.ptw.M0Wo.tgz>
>>> _______________________________________________
>>> Laszlo-dev mailing list
>>> [email protected]
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> [email protected]
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
