On 2009-10-07, at 11:26, Henry Minsky wrote:
A question about this approach, there is some set of 'styleable'
attributes
on view, maybe a dozen or more? (width, height, fontsize, font,
bgcolor,
align, resource, etc)
Are all these defaults going to come from a default LFC stylesheet now
instead of being hardcoded into LzView?
If we use a constraint for each place we want to bind
an attribute default value to a style value, does this mean that
when you
instantiate an LzView,
say, you will have to instantiate one delegate per attribute that is
bound
this way? Seems like
that could the memory footprint and instantiation time noticably
larger for
vanilla views, if we have
more than a handful of these stylable attributes?
See my reply to myself about a better approach, where you will see
that despite the $style bindings being classified as 'constraints'
they do not actually install any delegates (unless the CSS itself
specifies a constraint, as in, the `attr()` value, which ties one CSS
value to another), they are just evaluated at initialization time.
Also, in the revised implementation, we have a 'fallback' or 'default-
default', where if there is no CSS property found, you install that
default instead. I guess you could consider that fallback to specify
the default LFC stylesheet, but I don't think we have to actually
implement any such thing.
Also, the idea is that these are defaults that will be overridden by
subclasses and instances. Only if the subclasses and instances do not
specify values will these defaults be consulted. But, yes, if we go
crazy and make every possible attribute CSS styleable, there will be
an increase in the instantiation time of a view, so we should be
judicious about what we make styleable in this way.
The goal here is that we think users expect to be able to use CSS to
style their applications, but because we don't have any default
bindings for <view> attributes, the user has to do this all by hand.
This way, there will be default bindings all set up and they can just
add a stylesheet.
We should obviously evaluate the overhead of this change. There are
already some pretty good caches that optimize the CSS lookup, but
perhaps we can make a further optimization that creates a cache on the
class to avoid re-looking up (non-existen) default CSS bindings for
each instance of the class.
Finally, someday we _will_ have to have at least one more delegate for
each instance that has CSS style bindings so that we can implement
dynamic CSS styles. I.e., when the user wants to change a stylesheet
dynamically and see the change propagate to all the views with
attributes bound to the changed style. We'd need at least one
delegate to re-evaluate the style bindings when the style sheets change.
