It's not so much that we want to change it at runtime, just to have it inherit.
But even if we are not supporting changing it at runtime, to have it inherit, especially to be able to style it with CSS, we have to defer the creation of the sprite. CSS bindings don't happen until just before init() time, whereas normally we are creating the sprite at construct() time. <inputtext> very often creates the wrong kind of sprite at construct(), only to have to re-create it, once the value of `multiline` is finally known. The solution Henry and I are favoring, since <text> nodes cannot have children (LPP-1218), is just not allocating the sprit for text until init(). That way, any inherited or CSS-bound setting for `direction` (the CSS property for text direction) will be known. As a bonus, it may fall out that you can change the setting of `direction` at runtime and just create a new sprite, the same way we do in <inputtext> for `multiline`. On 2010-11-01, at 00:19, Max Carlson wrote: > We've had font styling attribute inheritance from parent nodes for a long > time. The canvas always has a default value that's inherited. One thing > that was really annoying was not being able to set the canvas font styling > attributes and have the values update... > > I'm torn on this one - it seems like we really need the same behavior for the > common case of inheriting from the canvas. Not sure about being able to > change the TLF attribute at runtime... > > On 10/31/10 6:15 AM, P T Withington wrote: >> [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] >>
