On 2010-12-21, at 11:50, André Bargull wrote: > > 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. > > ;-)
Those comments are already recorded at http://jira.openlaszlo.org/jira/browse/LPP-7354 which is the omnibus bug for figuring out how presentation types should really work. >>> - 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... This is not about node percent constraints -- it is about relative CSS units, like `em`. You are still probably right, that the type should not be responsible for the relative computation. But as I said, this is not implemented at all yet. Let's just say I put that in speculatively. Surely there is no harm in the accept/present knowing the attribute? > Max said `node` and `attribute` are required >> [...] to support css attributes with inherit. Max is wrong there. `inherit` is handled by the CSS binding lookup mechanism, not by the type. `inherit` in CSS simply means to take the CSS binding that I am looking for from the nearest enclosing node that has an applicable binding that is not `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. See: LZCSSStyle#297 > [1] http://www.openlaszlo.org/pipermail/laszlo-dev/2010-July/023115.html
