yeah, there's a js-react component to my day job and I got spoiled by the tooling around HTML output. naturally this isn't going to be that but seeing all the XML carets and such gets you thinking along similar lines

since you bring it up, is there documentation on the "composite" metadata somewhere? not sure where it's defined or exactly what it's doing at a concrete level

> I got spoiled by the tooling around HTML output same... and its certainly not at that level, its just a "bog 'ol tree" that highlights components, but ive personally found it really useful. And i think it gives pretty great insight to the "parts" of a composite component

looking forward to it, then

so, for the meta data, there isnt any documentation... i think there is a pin here explaining the diff between composite and native components

suffice to say, the meta data, as with pretty much all haxeui meta data, is just a shortcut

yeah, I'm new to the ecosystem but I gathered that much. I sort of understood what it was for by the name I just didn't understand what it was actually specifically doing when it showed up, which hampers my ability to figure out where my OWN bugs are coming from

none if it started off as meta / macro, it was just all pieced together with code... and then patterns became obvious, well, repetitions really. And they (generally) turned into meta / macros

so the @:composite meta is one of the more simple ones, it creates a "Builder" (which builds the control), an "EventHandler" which handles events and a "Layout" which... ... well, lays things out... without the meta you just end up with something like: this.builder = SomeBuilder this.events = SomeEvents this.layout = SomeLayout

that all, basically, the meta does

oh cool

I'm not so deep in yet that I've started messing with the macros/metadata system but VS Code won't help me find any of the existing definitions easily. That'll help the next time I'm scratching my head about something happening below the surface

yeah, the macro system isnt great with vscode, or in general really since there is some obfuscation (by mistake), but its all semi essential to have core have the ability to have "different types" of backends

or more importantly i guess, "backends that dont share X" (ie, a drawing surface)

you can change the builder, the event manager, the layout and all the individual behaviours...

its all possible without macros... all my PoC's were macro'less... but its easier with, for sure

otherwise the boilerplate is... ... ... annoying to say the least

lmao I bet

Is changing those common in subclasses? My understanding, out of the docs, was that you're often doing stuff like

extends TableView

with a

ComponentMacros.build

macro to wire XML layout to classes, but I don't think I saw anything, uh, "override" the Events or Builder or such

not that I have need for that, at this point, and maybe I won't, just wondering

thats the thing, if you are using composites (which most people are) you really dont care about any of this, and its just complication

but haxeui can also build native components, technically, you can map any component to any other type of component

thats when all this "complication" makes sense

but for the most part... well, its just not "important" (or useful)

> so, at a very simple level its a mechanism that allows you to replace component properties at compile time, the example i always use is the difference between a composite button (lets say haxeui-html5) and a native button (haxeui-hxwdigets). So: > > You create a button (new Button()), lets saying in haxeui-html5 (but any "composite backend" is the same). All good, now you call .text = "bob". In a composite backend (which is the default), this will go away, create a haxeui label, add it to the button component. This will then invalidate the layout, the ButtonLayout will get refreshed, this will grab that haxeui label, position it where it needs to be, etc. Same concept with .icon. All pretty standard stuff so far. > > However, now consider a "native" backend (like hxwidgets). If the same code were to run, it would mean that haxeui would try to create a native button, it would then try to create a native label and add it to the native button... Now, best case scenario, this would be ugly an weird, worst case (as is the case in wx) it would crash, since you cant add children to a native button > > The solution to this is "behaviours", so ".text" can be "replaced" at compile time with a totally different "behaviour", and in the case of wx widgets, this behaviour can just set the "native button text", and completely bypasses all of the composite stuff (including the layout). It defo adds some complexity, but its what allows haxeui-core to support native and composite backends... you can essentially replace any part of the outward facing api (assuming its using behaviours) with anything you like

(from the pins)

got it, thanks

almost certainly not going to worry about that for my purposes, I've fussed enough getting the haxeui-heaps configuration in place and I'm not interested in native UI for anything yet

seems fair... even for me, i tend to "behaviourize" things after i have a solid composite impl