Construction of pure-XML classes can fail depending on the order in which custom component classes are loaded

[AbeGellis]

When module.xml is processed, pure-XML custom component classes included in the <components> are added to the built types. This occurs in the order they are discovered during processing. For <class> entries with a folder attribute, the contents of that directory are loaded in alphabetical order.

HaxeUI allows custom component XML definitions to include other embedded custom components. However, when building, if an embedded custom component has not yet been loaded, the embedding component will fail to build.

Because of this limitation, the use of the folder attribute is inconvenient in cases where multiple included custom components reference others in their construction. Moreover, the user must manually sort the <class> entries to ensure that dependencies are generated in a build-safe order.

Expected Behavior

Custom component classes should be able to reference other custom components automatically without extra attention paid to build order, compiling as straightforwardly as "normal" classes in the project.

Current Behavior

Custom component classes may induce build errors on custom components that embed other custom components due to build order, unless the user explicitly orders them.

Possible Solution

My thinking was that the module processing + XML class-building could be refactored such that:

• any unrecognized component name in custom component building would be assigned a placeholder base component
• when a custom component type is loaded during module processing, it replaces the placeholder
• an error is thrown for each unrecognized component that still had a placeholder when all module entries were processed but there might be more suitable approaches - I am not terribly skilled with macros and type-building, or their ramifications within the haxeui framework more broadly.

It may also be worth detecting and preventing recursive references, which otherwise might become buildable with this issue resolved.

Test app / minimal test case

A reproduction project can be cloned from here

Context

I am currently building somewhat complex graphical asset production tools and would like to define custom components with logic-free XML to serve as the views in a hierarchical model-view-adaptor relationship.

[ianharrigan]

This should be fixed now. Its probably a little brittle so there is scope for improvement, but at least there is the concept of a load order when it comes to dynamic classes. Current what happens is that it walks each of the xml file nodes looking for any other dynamic classes, if it finds them, it makes sure they are loaded before the file referencing them - as i mentioned, its probably a little brittle, but at least its something and the dependency detection can be improved as and when and the order should be honoured.

[AbeGellis]

On Windows 11 / haxeui-kha it seems that all usage of the folder attribute now tries to use the absolute path of each file into the part of the fully-qualified type name, which also always fails because it includes the colon from the C:\ drive.

In the reproduction case, for example, I get

C:\Users\aagel\Projects\Reproduction-Cases\Module-XML\Libraries\haxeui-core/haxe/ui/macros/ModuleMacros.hx:687: lines 687-696 : "c:.users.aagel.projects.reproductioncases.modulexml.sources.view" is not a valid package name:
C:\Users\aagel\Projects\Reproduction-Cases\Module-XML\Libraries\haxeui-core/haxe/ui/macros/ModuleMacros.hx:687: lines 687-696 : Invalid character: :
C:\Users\aagel\Projects\Reproduction-Cases\Module-XML\Libraries\haxeui-core/haxe/ui/macros/ModuleMacros.hx:687: lines 687-696 : "c:.users.aagel.projects.reproductioncases.modulexml.sources.view" is not a valid package name:
C:\Users\aagel\Projects\Reproduction-Cases\Module-XML\Libraries\haxeui-core/haxe/ui/macros/ModuleMacros.hx:687: lines 687-696 : Invalid character: :
C:\Users\aagel\Projects\Reproduction-Cases\Module-XML\Sources/Main.hx:15: characters 21-28 : Type not found : BarView

Haxe compiler error.

[ianharrigan]

... ... this is very odd... im sure there is a sensible reason