The key issue is making inheritance work.
The _only_ way to have it work is to mimic the way default attributes
work in the tag compiler. They get compiled into an alist that gets
merged with subclass lists.
The old way, where default values came in one list and constraints
came in another, and styles in another, etc. Never really worked.
There were always bugs where a constraint overrode a style that was
closer when it should have taken the default, etc. Now, everything
comes in one list, and there are special objects in the alist that
become constraints or styles or databindings, but the inheritance is
one uniform computation -- subclass values shadow superclass values as
expected -- and you just run down the merged list and install the
values (or bindings) that surface.
So, whatever we do in the kernel has to work with that model. There's
no easy way. The tag compiler does a lot of work to build the
attribute list from a tag spec. We either have to do that all by hand
in the LFC, or we'd need to invent some new syntax and implement that
in the script compiler. Or, as Henry has suggested (and you just
reminded me), we could start allowing LZX into the LFC. This might be
the way to go in the long run, but will require some changes to our
build system, and obviously, we can't allow just _any_ LZX in the LFC,
it has to be carefully bootstrapped. But you could imagine that
LzView becomes something like LzViewInternal in the LFC, 99%
implemented in Javascript, and then we write the actual <view> tag in
LZX, with documentation and default values. This would probably make
our documentation system much simpler too, since it would not have to
parse Javascript for documentation. Seems like a nice long-term
project for remodularization.
In the short term, here is a sketch of something you could flesh out
that should give us most of what you want. There is the issue of how
we document this -- I think it means editing the documentation of each
attribute that you want to bind by default to a CSS attribute. This
is the brute force way. We might be able to come up with a better
solution where we create a new subclass of LzConstraintExpr that just
records the correspondence between an attribute name and the CSS
property name and builds a closure at runtime to install the correct
constraint. I'll have to think about that a little more...
/** @access private
* @modifiers override
*/
@@ -1073,6 +1117,9 @@
* The background color of the view. Setting <code>bgcolor</code> to
* <code>null</code> will make the view transparent.
*
+ * The background color of the view is controlled by the CSS property
+ * <code>background-color</code>
+ *
* May be set to any valid CSS color specification. When read, will
* be read as the equivalent numeric value. To retrieve a CSS color
* specification, use <code>this.presentAttribute('bgcolor',
@@ -1097,6 +1144,16 @@
this.bgcolor = bgc;
if (this.onbgcolor.ready) this.onbgcolor.sendEvent( bgc );
};
+ /**
+ * Default CSS style binder
+ * @access private
+ */
+ function $lzc$style_bgcolor(ignore) {
+ #pragma "userFunctionName=$style{'background-color'}"
+ this.__LZstyleBindAttribute('bgcolor', 'background-color',
'color');
+ }
+ // Install that as the default in the class attributes table
+ attributes.bgcolor = new LzConstraintExpr('$lzc$style_bgcolor');
/** The horizontal offset of this view's upper left corner from the
* upper left corner of its container.
On 2009-10-06, at 06:44, Max Carlson wrote:
Thoughts?
--
Regards,
Max Carlson
OpenLaszlo.org
From: Max Carlson <m...@openlaszlo.org>
Date: 3 October 2009 22:27:39.000 EDT
To: P T Withington <p...@laszlosystems.com>
Cc: OpenLaszlo development list <laszlo-dev@openlaszlo.org>
Subject: Adding default style attribute values (was Re: [Laszlo-
reviews] For Review: Change 20090924-maxcarlson-T Summary: Compile
style attribute for <attribute/>)
I definitely think we should try assigning standard CSS style
properties. That way, many $style declarations can go away.
A few options come to mind:
1. A LzInheritedHash of default stylename -> attribute mappings
2. Separate class properties similar to setter names, e.g.
style_visible = 'display';
3. Somehow hacking them into the existing attributes LzInheritedHash
Then LzNode would call __LZstyleBindAttribute() for matching
attribute names...
I hate to create a parallel mechanism to that used by the compiler,
but I don't see a way around it. All three of these should support
inheritance.
While we're on the subject, should compiler/AttributeSpec.java be
updated to know about styles?
