Sounds like a plan.
On Sep 3, P T Withington wrote:
> I think the simplest solution would be for me to redefine the $styles method
> as follows:
>
> function $styles () {
> var map = super.$styles();
> var styles = { ... };
> for (var k in styles) { map[k] = styles[k]; };
> return map;
> }
>
> That means you need a default $styles method on LzNode that returns a _new_
> empty hash;
>
> And you call __LZapplyStyleMap on this.$styles().
>
> ---
>
> We can make this more efficient by caching the style map on classes in user
> class.
>
> How does that sound?
>
> On 2006-09-03, at 00:17 EDT, Adam Wolff wrote:
>
> > If we did use LzInheritedHash, when would we retrieve the unmasked version
> > for each class? We'd need the new class initializer too, right?
> >
> > On Sep 2, P T Withington wrote:
> >
> > > On 2006-09-02, at 18:37 EDT, Adam Wolff wrote:
> > >
> > > > I think we're saying the same thing. FWIW $path expressions are passed
> > > > as
> > > > written -- with or without quotes -- and the runtime parses them.
> > >
> > > We should consider doing them the way $style is done. Then you can have a
> > > general expression, and they would all be done at once.
> > >
> > > > I'd rather just implement proto smashing for now and fix it in legals
> > > > later, rather than port LzInheritedHash to coal.
> > >
> > > If you're pressed, fine. It will just make it harder to port CSS to
> > > Legal's.
> > > LzInheritedHash is trivial, BTW:
> > >
> > > //---
> > > // @keywords private
> > > // Used to efficiently clone hashtables using Object's
> > > // N.B. these tables incorrectly will appear to have entries for all
> > > // the properties of Object.prototype. To avoid this (but pay the
> > > // of a slower implementation, use LzDictionary).
> > > //---
> > > LzInheritedHash = {
> > > make: function make (parent) {
> > > if (parent) {
> > > function xtor() {};
> > > xtor.prototype = parent;
> > > return new xtor();
> > > }
> > > return new Object;
> > > }
> > > }
> > >
> > > > On Sep 2, P T Withington wrote:
> > > >
> > > > > On 2006-09-01, at 20:12 EDT, Adam Wolff wrote:
> > > > >
> > > > > > Hi Tucker,
> > > > > > Ben found a bug with using $style in a class definition. Given:
> > > > > > <class name="super" bgcolor="${ 'stylea1' }"/>
> > > > > > <class name="sub" extends="super" x="${ 'stylea2' }"/>
> > > > > >
> > > > > > An instance of sub doesn't get the styled value. In general, this
> > > > > > kind
> > > > > > of
> > > > > > thing is handled by passing the collected style attributes as an
> > > > > > Object,
> > > > > > which are then attached to the superclass version of the same in the
> > > > > > ugly
> > > > > > loop at the top of the LzNode constructor. Since right now, the
> > > > > > $style
> > > > > > attribute is a function, this object composition isn't happening.
> > > > > >
> > > > > > Thoughts? Feelings? Seems like the easiest thing to do would be to
> > > > > > pass
> > > > > > $styles as a hash.
> > > > >
> > > > > Yes that magic object-merging loop is truly ugly, and I wouldn't be
> > > > > surprised
> > > > > if it bites us some day...
> > > > >
> > > > > $styles is a function so that $style constraints can be an expression.
> > > > >
> > > > > (Someday, it would be nice if the other constraints could be handled
> > > > > this
> > > > > way
> > > > > too, rather than the way path expressions are evaluated (only can be
> > > > > variables
> > > > > or member references), or the way once constraints have to be passed
> > > > > as
> > > > > individual functions.)
> > > > >
> > > > > I think the right way to handle this is the same way that setters are
> > > > > handled.
> > > > > In 3.x that means smashing the __proto__ of the hash to inherit from
> > > > > the
> > > > > superclass. In 4.x, where we can't do __proto__ smashing, we either
> > > > > have
> > > > > to
> > > > > copy the hash or pass in an empy LzInheritedHash to $styles to fill
> > > > > in.
> > > > > If we
> > > > > want to be forward-looking, perhaps we should do the latter in both
> > > > > cases?
> > > > >
> > > > >
> > >
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
