There seems to be two proposals on how to add boxmodel attributes to view:
1) Mixin:
<view with="boxmodel" padding="..."/>
2) Child class adding features to it's parent:
<view>
<boxmodel padding="..."/>
</view>
It is very hard to say from a user's point of view which of these seem
more appealing.
At this moment #1 seems more appealing to me.
#2 seems more appealing to jamesr.
I really don't have any objections to either.
But I would say that boxmodel properties do belong very closely to the
concept of view.
On the other hand since we have had until now views without margins and
paddings
on can also argue that they are not really integral part of a view but
rather addons.
If we now use mixins and then later after a transition period move them
as proper attributes of view
then all you need is to remove the reference to mixin. The subclass
approach needs more copy/pasting.
> Another thing to consider is how IDE and tool support can be
implemented for mixins.
> There should be better tools for coding LZX in the future, and would
an Eclipse plug-in have
> an easy way to detect which attributes/methods are available for a
class based on the current mixin syntax?
Is there an Eclipse plugin for laszlo?
(Because if there is I am jealous. I won't give up jEdit.)
> In my head, you
> would begin by adding a "namespace" for the mixins that you wanted to
> use. Then, using an attribute from a mixin (i.e. the target attribute
> from the dragmatchable mixin) would look something like
> dragmatchable:target="$once{someobj}". This would solve, I think, the
> overall clarity issue mixins present.
From a user perspective I would much rather say:
<view padding="10"/> than
<view boxmodel:padding="10"/>
If you add to your view so many mixins that conflicts arise then first
of all there is already a well defined
order of precedence defined (the leftmost mixin wins). Note for
subclasses the prededence issue seems to me more undefined.
For those mixin attributes that get covered there could be a reference
mechanism to them.
But then again that seems to go against some established rules in the
object oriented community,
because super.super (that is referring directly to ancestors that are
not direct parent) is not allowed (as Tucker pointed me out).
But if you could point to them then maybe the syntax presented would be
a good one.
<view mixin="newBoxmodel, oldBoxmodel" oldBoxmodel:padding="..."/>
However because Max specifically asked for input from the community
here's my vote (and it could turn out I was wrong):
+1 for mixin
- rami
