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
