Topics

Why is jmri.jmrit.XmlFile abstract?

danielb987
 

Out of curiosity:

Why is jmri.jmrit.XmlFile abstract? I have a class that needs to load an XML file so I need an instance of XmlFile. But I don't see any reason for my class to extend XmlFile. It's no problem, since I can do:

private final XmlFile xmlFile = new XmlFile() {};

But is there a reason for XmlFile to be abstract? Am I missing something?

Daniel

ps.
My idea is to create a xml file with the list of developers found in "LocoNet Hackers DIY SV & IPL DeveloperId List" that the class will read. This file is a static file that should not be changed by JMRI but edited by developers.

https://groups.io/g/LocoNet-Hackers/files/LocoNet%20Hackers%20DeveloperId%20List_v20.html
To access the file, subscription to the LocoNet hackers mailing list is required: https://groups.io/g/LocoNet-Hackers
ds.

Bob Jacobsen
 

On Jan 15, 2020, at 1:23 AM, danielb987 <db123@...> wrote:

Out of curiosity:

Why is jmri.jmrit.XmlFile abstract? I have a class that needs to load an XML file so I need an instance of XmlFile. But I don't see any reason for my class to extend XmlFile. It's no problem, since I can do:

private final XmlFile xmlFile = new XmlFile() {};

But is there a reason for XmlFile to be abstract? Am I missing something?

I think that’s a historical oddity. XmlFile used to have processing methods that needed to be overridden, but that was a long time ago. Now the processing is done via separate code using JDOM2.

I can’t think of a reason to keep it abstract, but perhaps somebody else can.

My idea is to create a xml file with the list of developers found in "LocoNet Hackers DIY SV & IPL DeveloperId List" that the class will read. This file is a static file that should not be changed by JMRI but edited by developers.

https://groups.io/g/LocoNet-Hackers/files/LocoNet%20Hackers%20DeveloperId%20List_v20.html
To access the file, subscription to the LocoNet hackers mailing list is required: https://groups.io/g/LocoNet-Hackers
Ideally, they’d maintain an XML file (and Schema) there and we could just copy those over periodically.

That’s how the NMRA distributed manufacturer numbers at one point; all JMRI had to do was copy the file when a change was detected. It was really convenient until NMRA politics crushed it. Now there has to be a periodic comparison with a PDF file that doesn’t have a fixed layout (Or even self-consistent content: I recommend _not_ carrying around redundant data, i.e. both decimal and hexadecimal values) That’s effort, the update can take time, and transcript mistakes are possible.

Bob

--
Bob Jacobsen
@BobJacobsen