but as Ian said before, there's no obligation in haxe for using xml/css, it's just flexible enough for suiting the developers taste.

either way, I can't prototype a entire styled UI for a new app by code in a couple of hours, but I bet I can do that with haxeui xml/css... (perhaps I suck at coding 😅 )

I recall that someone started a vscode plugin for this and visual rendering, was that you?

write an XML schema for it?

or better: write something to generate a schema from sources

Wish I were familiar enough with haxeui xml to do it...

can't think of a better way to learn everything about it than writing a schema generator

agreed 😄 but @best-agent-85158, you started the documentation of the code, but who started a visual xml haxeui plugin?

idk

.... as you might have noticed im not gonna be around much for the next few days / weeks... wedding is in 2 days 😮

you defo can generate schemas for the xml, and it should be fairly simple... i think the haxeui macros can do it... only problem i forsee is that you'd want haxeui to include all components, but NOT actually include the code for all components, so that will need some thought

for what I'm seeing, to have intellisense in the xml, you need the schema for all components and they don't even need to be included in the project, the XSD can even be linked by url, like so:

xml
<?xml-model href="http://haxeui.org/schema.xsd" ?>

or be included in the new sample/fresh project and we only have to put the previous with the path to the xsd. I believe the fact that we want haxeui to include or not code for all components, as nothing to do with the xsd, because the xsd is only for validation and intellisense (and possibly some doc) of the xml, the rest remains the same (correct me if I'm wrong). I think that the "challenge" is to automatically generate the a new xsd, every time a update is made to haxeui...

well, the reason why i think it would be important for it to be generated locally is because you would want custom components to also be included

also, if its generated, it wouldnt have to be maintained

yeah, I was about to write that... 😅

the main thing to avoid, is now, haxeui loads components "on demand", i mean, it looks for tags in the xml, and then tries to match them to a component class - this was important as previously haxeui was creating a reference to every haxeui component 😮

your right, generating a xsd for all components could be tricky but doable, I suppose, but regarding the custom part, that could be generated by macros locally and then, for what I've read, it can be linked to the general components xsd, or it's the other way around, the link is already in the general xsd for a custom xsd, and if it's generated then it's used also for validation and intellisense of those custom components, but someone more experienced with xsd, please come forward and correct my statement...

i was thinking the simplest solution would just to add

<?xml-model href="haxeui.xsd" ?>

at the top of any xml file

that .xsd would be generated by the project itself (somehow)

right, what I'm adding is that inside

haxeui.xsd

will be something like:

xml
<xs:include schemaLocation="custom-haxeui.xsd"/>

and the

custom-haxeui.xsd

will have the schema for the macro generated custom components (the ones that are registered in

module.xml

), and as xsd can use inheritance, the custom component only needs to reference the element that is extending (for extended component properties validation) and it's own custom properties (I say only, but that is still, probably, not a easy task)

yeah, i think we are talking about the same thing, im thinking that the haxeui macros (or some process anyway) will generate a schema for everything custom components, in build haxeui components, the whole lot in one go

basically that, but generated each time

and haxeui has no concept of a "custom component" is anyway really, its just a class that extends Component (so in built ones are also "custom" in that regard)

yeah, I was only separating the custom components in one independent xsd (

custom-haxeui.xsd

) because once the

haxeui.xsd

was generated, the macro didn't need to keep generating that, only the user custom components (for macro compilation performance purposes), but you have now "defeated" my line of thinking, with the built ones are also "custom"... 😅

🙂 Also, less to maintain... lets be honest, im not great a regening the documentation 😮

the hardest part (i think) about this is to somehow NOT make the haxeui macros include a reference to every component... that could be a pain

i wonder if there could be some seperate process that could do it... like a flag, or a different .hxml or something

then you dont care if it includes all components in the final output

but for validation we don't need the reference to all components? or there is some "hidden" support/sub components that are not suppose to be used... (I'm certainly not grasping the concept there...)

well, in order to get all the props for a component the macros need to "know" about these classes