[Promoting to laszlo-dev] We need to make a decision here, because this is also related to http://jira.openlaszlo.org/jira/browse/LPP-9493
Just to clarify terminology a bit, CSS uses the term 'inherit' to mean a property value is take from the parent DOM node if it is missing; they distinguish this from the 'cascade' of style rules, which has the pattern 'last/most-specific wins'. Seems we need to align our terminology and that the mechanism you are working on here is an 'inherit' mechanism. In CSS, each property defines whether or not it inherits its value from enclosing nodes, although you are also allowed to specify the keyword `inherit` as the value of any property and force that property to get its value from enclosing nodes. We currently have two mechanisms for nodes to inherit attribute values from their parent node. This mechanism that you are extending, where the attributes are specified as LZX attributes and are looked up (and constrained) at construct time; and a second mechanism in LzCSSStyle where (incorrectly right now) _all_ CSS property values are copied from the parent node. I think we should have only one or the other, but I expect there will be fallout (since CSS is inheriting all properties right now, probably someone will be disappointed when we make it work according to spec). The CSS mechanism is also broken in another way: inherited property values will not dynamically update. The mechanism you are working on handles dynamic updates, but is more inefficient than the CSS mechanism. The CSS mechanism copies down all the inherited property values at once, whereas this mechanism is looking each one up individually, hence having to chase up the parent chain for each inherited property. I _think_ this mechanism is the one that should prevail, and the CSS one should go away, because the LZX attribute is the basic principal that CSS is overlaid on. But I wonder if there is a way to make this mechanism more efficient and more general so we don't have to create multiple hand-coded setters, cascade setters, delegates, etc.? Opinions or ideas? On 2010-10-30, at 19:43, Henry Minsky wrote: > If anyone could take a look at this change ... > > Actually this is the fix for LPP-9266, but should help implement LPP-9478 > (CSS styling of the bidi property). > > > > On Wed, Oct 27, 2010 at 9:18 PM, Henry Minsky <[email protected]>wrote: > >> Change hqm-20101027-PGz by [email protected] on 2010-10-27 20:27:15 EDT >> in /Users/hqm/openlaszlo/trunk3 >> for http://svn.openlaszlo.org/openlaszlo/trunk >> >> Summary: implement cascade of bidi text property at construct time >> >> New Features: >> >> Bugs Fixed: LPP-9478 >> >> Technical Reviewer: ptw >> QA Reviewer: max >> Doc Reviewer: (pending) >> >> Documentation: >> >> Release Notes: >> >> Overview: >> >> >> Details: >> >> Use the font cascade machinery to inherit the hasdirectionallayout property >> for text, >> and look up the value early enough to allow the correct value to be set >> when >> __makeSprite is called. >> >> >> Tests: >> >> cascade-property.lzx: this demonstrates the cascade inheritance of the >> hasdirectionallayout property from >> the parent view. The top line of text should read >> "hasdirectionallayout=true", and the second line should >> show LzTLFTextField as the class name >> >> examples/components/bidi_component_sampler.lzx >> copy of component_sampler with hasdirectionallayout=true set at the top >> level view, so all text views >> should be using the new bidi LzTLFTextfield class in their sprite. >> >> The app should appear identical to component_sampler.lzx in SWF10, except >> that >> inspection of the text views of components shows that their >> tsprite.textfield is of type LzTLFTextField rather than TextField >> >> Files: >> A test/tlf/cascade-property.lzx >> M WEB-INF/lps/lfc/kernel/swf9/LzTLFTextField.as >> M WEB-INF/lps/lfc/views/LzText.lzs >> M WEB-INF/lps/lfc/views/LaszloView.lzs >> A examples/components/bidi_component_sampler.lzx >> >> Changeset: >> http://svn.openlaszlo.org/openlaszlo/patches/hqm-20101027-PGz.tar >> > > > > -- > Henry Minsky > Software Architect > [email protected]
