How can I tell which attributes a widget/tag supports?

1

How can I tell which attributes a given xml tag supports? For example, when I see a checkbox in assets/main.xml:

<checkbox id="checkbox_b1" native="true" text="Native B1" />

where can I find that list of id, native, text, and the others?

Is there a 1-to-1 correspondence between those xml tag attributes and the particular component’s fields? For the checkbox example, I’m looking at its API docs — which items in there can be used with the <checkbox> tag?

2

So yeah, there is a 1->1 correspondence to public component properties and xml. In fact, when you have:

<checkbox id="checkbox_b1" native="true" text="Native B1" />

The macro goes away and turns that into:

var c0 = new haxe.ui.components.CheckBox() // class is the result of a class map lookup
c0.id = "checkbox_b1";
c0.native = true;
c0.text = "Native B1";

So if you used a property that didnt exist you should get a compiled time error.

Ian

3

Thanks, Ian. So, in that API docs page for CheckBox, I see that it’s broken up into eight sections:

  • Properties
  • Methods
  • Display tree related properties and methods
  • Event related properties and methods
  • Layout related properties and methods
  • Script related properties and methods
  • Style properties
  • Style related properties and methods

I can only use properties (not methods) as attributes in the xml checkbox tag, correct?

Looking at the source for CheckBox, it’s shorter than I expected. Are the docs showing me all the inherited properties & methods? For example, under “Style properties” I’m seeing backgroundColor, borderColor, borderRadius,… but those aren’t present in the CheckBox.hx file.

Also, I’m not seeing id or text listed in the API docs, but those are the first attributes I set. Why aren’t they listed, and where do I find them?

Thanks!

4

So:

image
image1227×516 24.4 KB

You see at the side there are checkboxes showing you which properties or which classe(s) you are looking at, if there are no checkboxes it means there isnt any multiple classes that have that doc group, so yeah, you are looking at inherited properties, though you are right in that its a little confusing, it should probably have a checkbox there regardless (even just a single one) saying where it got its field from (Component in this case)

The docs there are pretty woefully out of date, however, id and text have been there forever, so that is more likely a bug in the docgen i created, ill have to take a look at it, i guess i need to gen new docs anyway…

Ian

PS: yeah, functions wont work in xml attributes… basically if you have this:

<button text="bob" />

The macro will turn that into:

var c0 = new Button();
c0.text = "bob";

So if you had:

<button someFunction="bob" />

The macro would turn that into:

var c0 = new Button();
c0.someFunction = "bob";

Which would almost certainly fail to compile.

Note that:

<button text="Button" onclick="this.text='Bob'" />

will work and its a special case (the macro will look for attributes with “on” and wire up the event “click” to a script "this.text = ‘bob’ " (this being set in the script vars to the event target), scripting is very useful in some cases, especially for tiny apps / ui changes / tests, consider:

<vbox>
   <script>
      function someFunction(p) {
         tf.text = "set2 - " + p;
      }
   </script>
   <textfield id='tf' />
   <button text="set 1" onclick="tf.text = 'set1' "/>
   <button text="set 2" onclick="someFunction('someParam')"/>
</vbox>
1 Like
5

Ah, yes, I see that the checkboxes show/hide that info. Nice.

Ok, so the sections on that page are “doc groups”. If there are no checkboxes above a doc group, that means that all the properties and methods therein are inherited? I would think that would be the other way around (if no checkboxes, then they must all be right from the class we’re looking at).

It looks like you took great care to generate lots of useful info in these API docs (eg., the inheritance diagram, the breadcrumbs showing where we are, those active checkboxes, the separate doc groups rather than dumping them all together.)

Regarding the little colored boxes/labels in the right side of each doc group, what do these mean? :

“behaviour”

“bindable”

“clonable”

“override”

?

6

Here’s what I’ve got written up on this so far:

http://www.unexpected-vortices.com/haxe/haxeui-tut/xml-layout-and-objects.html

7

So yeah, i totally agree now i look at it that having no checkbox, or any other indicator makes you think that all those properties from from the checkbox class, which is incorrect. I guess ive never noticed it before because i know they arent from that class - but you are 100% right that if you didnt know that it would look like it - im going to see about generating some new docs this weekend to see if i can clear some of that up (as well as seeing why certain things like id, etc arent there).

Write up is cool! (and very appreciated!), being able to point someone to that is a really useful resource!

Cheers,
Ian

8

In the main.xml file, inside the <script> tags, is that plain Haxe code? (Or maybe hscript?)

9

Thats currently hscript - the hscript interpreter is slightly modified to allow for slightly more intuative scripts:

new Button()

rather that

new haxe.ui.components.Button()

little things like that - i want to look at the possibility of using haxe code if that xml is processed at compile time (rather than loaded at runtime) - but havent had much time yet, and its low priority i think

1 Like