On 12/20/2010 11:22 PM, P T Withington wrote:
On 2010-12-20, at 16:38, André Bargull wrote:
Some questions for this change set:
- Why<accept> and<present> instead of<method name="accept"> and<method
name="present">?
Because despite all our grand ideas, I can't just tack this onto the class compiler. The class
compiler is really a<node>subclass compiler, and has _way_ too much machinery than I was
willing to hack around to make this work. Possibly, I could have put<type>
above<class> and migrated just the stuff type needs up, but I had to get a fix out today...
So... for the time being, I just want to make it very obvious that<type> does not have
attributes and methods or any of that machinery, and I was afraid if I looked for just the two
method patterns that would confuse people into thinking they could write other methods. This
is still a private "in progress" feature. People who use it will need to be prepared
to fix their code if we change the API.
Could you create a JIRA ticket, so this info doesn't get lost. At a
later point, <type>s can have <method>s and <attribute>s because [1]:
you might need support methods or attributes.
;-)
- Why is it necessary to pass `node` and `attribute` to accept/present?
To be able to implement relative CSS dimensions. I.e., to generally be able to
say `75%` as a CSS binding. To calculate what 75% is, you need to know the
attribute and node (and look at that attribute in the parent).
This is not yet implemented, but I figured I might as well put the machinery
there.
That sounds wrong to me, a <type> shouldn't need to know to which
<attribute>s it will be applied. Take the x-/y-attributes from <view>
for example: You can use percentage values for both attributes, but the
percentage is relative to the immediate-parent's width/height. In that
case, the <type>'s accept() method needs to take different code paths
for different attributes. On top of that, relative dimensions are
dynamic, so you can't just return a static value, but you actually need
to use some sort of constraint. And I'm not sure how to make this work
with the current <type> proposals...
Max said `node` and `attribute` are required
[...] to support css attributes with inherit.
In that case, every <type> needs to implement its own mechanism to
support inherited css attributes?! I think this should be done in a
single place outside of <type>'s accept() method.
[1] http://www.openlaszlo.org/pipermail/laszlo-dev/2010-July/023115.html
On 12/20/2010 11:05 AM, P T Withington wrote:
Change ptw-20101220-82u by [email protected] on 2010-12-20 04:54:41 EST
in /Users/ptw/OpenLaszlo/trunk-3
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: Next step in user<type>s
Bugs Fixed: LPP-9589 Unexpected warning information of ''gradient"
Technical Reviewer: [email protected] (pending)
QA Reviewer: [email protected], [email protected] (pending)
Overview:
I've hacked in user-defined types. You can now write the gradient
type as:
<type name="gradient">
<accept args="value, node:LzNode, attribute:String">
return new lz.CSSGradient(value);
</accept>
<present args="value, node:LzNode, attribute:String">
return value.css;
</present>
</type>
I know this is not as general as we wanted, but it's the most I
can get working on short notice.
Details:
Basically the types get compiled as very custom classes at resolve time.
Tests:
Rewrite gradienttype.lzx as above and run house.lzx
Files:
M WEB-INF/lps/server/src/org/openlaszlo/sc/ScriptClass.java
M WEB-INF/lps/server/src/org/openlaszlo/compiler/TypeCompiler.java
M WEB-INF/lps/server/src/org/openlaszlo/compiler/ViewSchema.java
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/ptw-20101220-82u.tar
