Pharap / ABSpriteEditor

A basic sprite editor designed for exporting and editing Arduboy sprites.
Apache License 2.0
7 stars 0 forks source link

XML `<SpriteFile>` element cannot be edited #37

Open ace-dent opened 2 years ago

ace-dent commented 2 years ago

Re. <SpriteFile FileName="FOO"> ... What is the purpose for this top hierarchy element in the existing XML (and underlying model)? It cannot be renamed in the program directly. If edited externally, the edited version is honoured (good!)... but it doesn't correlate to any other data structure when exporting to cpp, etc. Is it necessary? If it remains, perhaps editing should be allowed?

Pharap commented 2 years ago

What is the purpose for this top hierarchy element in the existing XML

Firstly, because XML absolutely has to have a single root element, no more, no less:

"There is exactly one element, called the root, or document element, no part of which appears in the content of any other element." - Extensible Markup Language (XML) 1.0 (Fifth Edition), §2.1

I can't just dump a load of Sprite nodes in the middle of nowhere, they have to be inside a root element, and SpriteFile is that root element.

Even HTML documents have a <html> root element in which everything else is contained.

but it doesn't correlate to any other data structure when exporting to cpp

It correlates to the file itself.

You could also consider it the global namespace, which is why SpriteFile's Namespace property returns null, because in C++ to refer to the global namespace you leave the left side of the scope resolution operator (::) blank.

But that aside, it plays a role within the software: SpriteFile is what binds the Sprites together. It is the root of the tree.

Is it necessary?

SpriteFile - Yes, absolutely. Both internally and in the XML.

FileName - Internally, yes.

As for the XML file, possibly not, but it does make life a bit easier because it means the SpriteFileReader can pull the file name from the attribute instead of having the calling code retrofit that onto the data structure after loading. The SpriteFileReader uses an XMLReader, and the XMLReader has no file name stored because it might not even be reading a file - it could be reading a network stream or a memory stream. A block of XML-formatted text need not be kept in a file, after all. Such is the nature of abstraction.

I think at one point I had considered making it possible to pack multiple .h files worth of data into a single .xml, allowing the user to save and export an entire directory worth of files, but I probably either forgot or gave up on the idea.


At the moment I don't know whether it's better to allow the name to be edited or to attempt to remove it, but I won't be deciding that tonight at any rate.


If edited externally, the edited version is honoured

For the record: the point of using XML wasn't to encourage people to try to edit the files manually, it was a choice of convienence.

.NET (and thus C#) has supported XML natively since before I started learning C# (possibly as far back as 2003 from what I can tell), so I don't need to worry about importing libraries or learning new APIs, and XML is tree-structured anyway so it's a very good fit for what is already inherantly a tree structure - a file containing namespaces (potentially nested) and sprites, which themselves contain frames.