Sounds good. I'd love to nuke/standardize the half-assed inheritance
for font styling also... As it stands, setting a view's font style in a
view between the one that's inheriting and the one that's inherited from
doesn't work...
On 11/1/10 5:23 AM, P T Withington wrote:
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]
