Open epheterson opened 9 years ago
Yeah the colour being in two places is an optimization I've been meaning to take care of for a while now.
But as to the main point, no, it does not make sense to separate them in the XML. If anything, this is the most XML way to do it. Tiles are logical children of Categories.
If I separated them, then Categories would have to have an additional property: a list of pointers describing which Tiles belong to that Category. That makes the parsing much slower, bulkier, and take up more RAM in the client's app. What would those IDs be? Why would I make fake IDs just for the XML file, when I can just embed them where they logically belong?
This structure produces smaller .XML files, and is faster to inject to DB.
If anything, the two optimizations here should be:
I'm okay with the above changes instead. I suppose they are children of categories, so the structure is logical. The color should be outside of a tile is all, then.
In my logic there would've been no ID's, just string matching, but you're right that it would be more difficult to parse, and now that I think about it, more difficult to read the XML as well. Then it should just have the goods at the top, something like:
<profile>
<categories>
<category>
<title>Title...</title>
<position>1</position>
<color>hsl(180, 65%, 50%)</color>
<tiles>
<tile>....
Yeah exactly
The XML logic seems a bit odd, not a big deal but IMHO it should be : user categories tiles
right now, it's user categories -- tiles
The benefit of the former is storing the details of the categories all together, in one place, instead of spread about the document, like :
<categories> <category> <title>Music</title> <pos>1</pos> <color>hsl(180,65%,50%)</color> <-- Currently stored within a tile! </category> <category>...</category> </categories> <tiles> <tile> <title>My tile name</title> <category>Music</category> <content>...