Dear daft developer who thought that creating the actual underlying representation of an XML Data Binding object when a property is queried, you are in my thoughts today.
Dear daft developer who thought that creating the actual underlying representation of an XML Data Binding object when a property is queried, you are in my thoughts today.
In case you wonder what this is about:
1. Read a properly formed and validated XML file, read it using Delphi XML Data bindings.
2. Assume this XML file has optional nodes according to its schema.
3. Query some of these optional nodes. Find one that needs to be changed, and do so.
4. Save the file and try to get on with your life.
5. Find later that your XML file is no longer valid according to the schema.
6. Find out that the XML Data Bindings classes actually create the XML node when accessed (nevermind you didn't assigned any value, and that this darn object actually threw an exception.)
So, if you need to query for optional nodes for an XML Data Binding object created from a schema, be damn sure to do it in the expected order specified in the schema.
Seriously, f**k Delphi Data Bindings.
In case you wonder what this is about:
1. Read a properly formed and validated XML file, read it using Delphi XML Data bindings.
2. Assume this XML file has optional nodes according to its schema.
3. Query some of these optional nodes. Find one that needs to be changed, and do so.
4. Save the file and try to get on with your life.
5. Find later that your XML file is no longer valid according to the schema.
6. Find out that the XML Data Bindings classes actually create the XML node when accessed (nevermind you didn't assigned any value, and that this darn object actually threw an exception.)
So, if you need to query for optional nodes for an XML Data Binding object created from a schema, be damn sure to do it in the expected order specified in the schema.
Seriously, f**k Delphi Data Bindings.
Been there done that a long while ago. The good thing: when after a lot of frustrating moments you have gotten it to work and documented how you got it to work, there is virtually no need to re-test it in newer Delphi versions. The code has not changed significantly (if at all) since these peculiarities were introduced. Seems the implementer wasn't eating much of his own dog food back then.
ReplyDeleteJeroen Wiert Pluimers Yeah, that kind of stability is welcomed. But this behaviour is just so bizarre that there is a big chance you'll discover it only when it bites you, in my case, quite some time after it went to production...
ReplyDeleteLeonardo Herrera indeed. Frustrating. I remember a client having similar case with parent/child elements. Had to debug deep in the RTL code. Took a day to find it and work around it. I think I even filed an issue. But doubting for it to ever (if at all) to be fixed made me glad I found a workaround.
ReplyDelete