That would definitely be a lot harder to do. The problem is that the HTML is actually rather complex considering what the data is, and the parsing would most likely break if there are changes to the HTML for presentation changes.
You talked earlier about having the tool generate an RMDU file directly.
Vicky didn't like that idea, for some very valid reasons.
I think generating an XML file would be easy for Vicky, and easy to parse. Another option would be
JSON, which is also very easy to generate and parse and is less verbose than XML, and some would say easier for humans to read. The only catch for us is that numbers must be in decimal, hex is not allowed, although we could work around that by using strings for hex values (e.g. "$0022" for PID 0022)
The JSON file format would look something like:
Code: Select all
{
setupCode: 0000,
deviceType: "Cable",
protocol: {
name: "Zenith",
pid: 34
}
deviceParms: [ 5, 0 ],
fixedData: [ 06 ],
functions: [
{ name: "num 0", efc: 012 },
{ name: "num 1", efc: 236 },
{ name: "num 2", efc: 076 },
...
{ name: "Settings", efc: 109 },
{ name: "Surround", efc: 014 }
]
}
An equivalent XML format would be:
Code: Select all
<?xml version="1.0" encoding="UTF-8" ?>
<deviceUpgrade>
<setupCode>0000</setupCode>
<deviceType>Cable</deviceType>
<protocol>
<name>Zenith</name>
<pid>0022</pid>
</protocol>
<deviceParms>
<parm>5</parm>
<parm>0</parm>
</deviceParms>
<fixedData>
<byte>06</byte>
</fixedData>
<function><name>num 0</name><efc>012</efc></function>
<function><name>num 1</name><efc>236</efc></function>
<function><name>num 2</name><efc>076</efc></function>
...
<function><name>Settings</name><efc>109</efc></function>
<function><name>Surround</name><efc>014</efc></function>
</deviceUpgrade>
