|
I am working, super slowly, on a office like desktop / productivity application for table top, pen and paper, RPG game master app.
It supports multiple document type.
I am currently working on a "resource bag" type of document.
On the one hand I could serialize it with one method call with my custom made serializer (and data format).
On the other hand it seems to be a good fit for an "open standard format", like a zip file with a "properties.json" descriptor file.
And I am wondering,
Q: should I do it?
This is a rhetorical question anyway since, with my snail development speed I am not gonna bother...
But I still wonder about it abstractly.
1. it would be cool
2. it would be brittle (what if people create an incorrect "properties.json file?)
3. it would be work (I have to write entirely custom Save() / Load() method
4. not many people are gonna use my app anyway
5. the API to save such file already come fully functional with current code (i.e. my code), with strongly typed data model, why bother?
As a side note my serializer is open source and it can generate the data model it needs from a serialized data stream, in case people are curious and if I do not share the code (using upcoming .NET Native compile, for example), so people can always very easily reverse engineer data produced by my app...
|
|
|
|
|
|
That would have been too easy.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
F-ES Sitecore wrote: What's wrong with XML?
He can't spell it.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
spot on!
|
|
|
|
|
since this (unexistent) format would be made for manual human editing friendliness... .json is more human friendly that XML, I think (and since this is my data format...)
|
|
|
|
|
Perhaps, but XML has the advantage of being typed. Anyway, the point I was getting at is that what you're doing is pretty much what XML is for which is already a standard so I don't see the need to re-invent the wheel.
|
|
|
|
|
Typed, shmyped!
Who needs that anyway?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
"schmyped"?! what is the meaning of this?!
|
|
|
|
|
answer this question honestly, which one is more manual human editing friendly of the 2 formats below?
at any rate I much prefer to manually edit json (which is the whole point of a human friendly format), much less boiler plate code. no useless header, no useless "closing" tag.
as to do it by code.. it also much less troublesome to use than XML as far as I experienced it...
(as illustrated below by the difference between JSON and XML serialization code below)
C#
public enum ItemType
{
Image,
Icon,
}
public class Item
{
public ItemType Type { get; set; }
public string Name { get; set; }
}
public class Document
{
public List<Item> Items = new List<Item>();
}
class Program
{
static void Main(string[] args)
{
var doc = new Document
{
Items =
{
new Item { Name = "foo", Type = ItemType.Icon, },
new Item { Name = "bar", Type = ItemType.Icon, },
new Item { Name = "snafu", Type = ItemType.Image, },
},
};
var json = JsonConvert.SerializeObject(doc, Formatting.Indented);
Console.WriteLine(json);
var xmlS = new XmlSerializer(typeof(Document));
var sb = new StringBuilder();
xmlS.Serialize(new StringWriter(sb), doc);
var xml = sb.ToString();
Console.WriteLine(xml);
}
JSON
{
"Items": [
{
"Type": 1,
"Name": "foo"
},
{
"Type": 1,
"Name": "bar"
},
{
"Type": 0,
"Name": "snafu"
}
]
}
XML
="1.0"="utf-16"
<Document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Items>
<Item>
<Type>Icon</Type>
<Name>foo</Name>
</Item>
<Item>
<Type>Icon</Type>
<Name>bar</Name>
</Item>
<Item>
<Type>Image</Type>
<Name>snafu</Name>
</Item>
</Items>
</Document>
modified 5-Nov-18 7:24am.
|
|
|
|
|
You do know that you are asking people who have not been afraid to XAML together entire scenes and animations in a 3D engine or to design the views of their own UI in the same 3D engine?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I know what you mean!
We have a saying in French, if I remember correctly (I left France so many years ago now): "there is no more blind than the one who don't want to see"...
|
|
|
|
|
That's only because I had to put so many namespaces into the useless header.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I'd have to say "JSON".
It's also a lot easier to get XML wrong if you are human editing it. You can get JSON wrong of course, but there is so little "padding" that it tends to stand out a bit more.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I'd say that too!
|
|
|
|
|
Being "human friendly" comes with some drawbacks though. As I said type is an issue, as is validation - what happens when I enter "123" as the type? It's easier to make mistakes when nesting json, using arrays etc, and harder to track down what you've done wrong. If you think people are fine with json then look at any json related question in QA and it's almost always because someone doesn't understand the data structure their json is representing.
|
|
|
|
|
You get exactly the same problems - and QA questions - with XML, CSV, and SQL though ...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I don't recall there being many questions on XML or CSV that revolve around not understanding the format. How many times have people got json like
[{prop:"value"}]
and they're trying to deserialise it to a single object? Or they are working with json like
{"1":"this", "2":"that"}
XML questions tend to be "here's my XML and google is broken, how do I read the XYZ node", or people that don't know how to use XML namespaces. Again CSV questions are generally "how do I read a CSV file" or issues regarding commas in their data. JSON seems special in that people often just don't understand the data it is describing.
|
|
|
|
|
Support both! With bidirectional converters!
Sounds like this is a personal project, which is too bad, because I probably just quadrupled your work load and billable hours!
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
haha.. yes it's a personal project...
come to think of it read / write to zip archive won't be too much work.. and would let people take the image out if they want. Which is the most interesting part...
and if they introduce bug.. too bad for them...
|
|
|
|
|
Super Lloyd wrote: it would be brittle (what if people create an incorrect "properties.json file?)
Any process that uses human-created data files is subject to this risk. Go with a known data format and don't look back. If you're really concerned with people creating invalid json files, provide a GUI utility that guides them through the process, where you have ultimate control of the format. Finally, encrypt the data file in its entirety to prevent users from changing it in the wild.
Human readability is NOT what you should be thinking, because the application is what's loading/interpreting the data.
Another consideration - if you use an industry standard format (json, ml, or whatever), other applications can more easily load your data without having to have your custom serializer.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 5-Nov-18 8:51am.
|
|
|
|
|
Mm.. true that.
I would like this file to be human readable, because it is basically a file containing various image type (all common raster, + .svg, .xaml, + image map: image ID + list of rect) and it would be very handy to rip it out! ^_^
The properties.json is brittle (need unique Guid, amongst other things) but I guess it doesn't matter.
1. I have an an editor!
2. reading the file is the interesting part...
|
|
|
|
|
I'd vote zipped JSON to make it easier on yourself...in case you ever have to debug a serialization issue. You can employ obfuscation to make file type a little less obvious to the user. Simply choose one (.mydoc) that isn't clearly a zipped file. A bunch of office-style apps I've seen use this trick.
As to the more general "should I?" question, you'll need to answer that for yourself. It really depends on your exact goal in writing the app.
|
|
|
|
|
my serializer is working quite well, thank you...
the idea is to let people open the archive and rip the image out. or maybe edit the image-map's rect coordinate manually.
I will try to make the resource editor as useful as possible... but it's not my main focus...
come to think of it, it won't be too much work and it's very (power-)user friendly to make it happen, might just do it!
|
|
|
|
|