qoncept wrote:Ok, after getting about 90% done with implementing includes, I've just gone back and undone all the work. I decided in the end it'd be better to not support them. I was kind of hesitant since I'd put so much work in to it, but I think it'd actually be a bit more confusing for the end user.
Here's what I'm doing instead. In one file (say ecu_defs.xml) I'll have the ECU definitions with all of the relevant data in each rom tag. Just like in Colby's example, but each ECU version will basically be combined with the base it included in Colby's version. Then, to help ease with adding new ECU versions, I'll have another file (maybe ecu_base.xml) that will be imported in to the ECU definition editor, basically just as defaults for the user to work with.
I think this will make adding new ECU versions easier. Instead of choosing between being bound to the base and overwriting certain fields or creating the definition from scratch, the user will be able to open wrxbase and make the appropriate changes. It'll also make writing applications that use them easier and, as I found out, reduce complexity by a whole lot.
Ultimately, this is very similar. All my includes do is overlay the same object several times, each time adding more detail, and then in the end only presenti the complete, valid objects to the user. My heirarchical approach can always be flattened out when it goes to save a file, and can also load any other file as a template, so I think it will be pretty easy to maintain compatibility between the two programs.
In some ways things would be easier using a database in terms of having each type of object only described once (descriptions, scaling, table types, addresses) and then just build the ROM metadata by reference to these various things. I think the XML is a lot easier for most people to play around with and understand though.