|
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!
|
|
|
|
|
|
haha.. no thanks you! but cool link nonetheless!
there are valid reason not to used a database.
- I already have a serializer where whole document can be saved / loaded in one method call (very much like JsonConvert) except it's much more compact than JSON... (i.e. smaller files), while still being versioning tolerant and strongly typed...
even if I do the work to make it work with a database engine, it's gonna be a big file... (i.e. bigger than a single json equivalent which is bigger than my file format)
(to be fair my file format is more compact than JSON only because I got a lot of object of the same type... the type information takes lot more space than json if every instance has a different type...)
- save to zip archive is here to provide easy editing abilities so that (power-)user can, for example, rip image out or edit rectangle lists manually (although I am building an editor right now..), otherwise I could as well use my serializer!
|
|
|
|
|
Perhaps I misunderstand you but here's the first image that pops up in my little head:
Why allow people near the master archive (.json) file. Your serializer should be able to identify the format and update the json archive.
And no I cannot spell MXL, nor can I pronounce it. And a ten-foot-pole is not long enough.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
the point of using a .zip archive (which will require a properties.json to add missing information) is to let (power-)users open the file and rip the images out. And also perhaps even edit the image maps (rectangle list) with a text file.
In which case the properties.json will here for all to mess around and maybe break beyond repair...
Otherwise my Serializer already successfully read and write that data structure in a strongly typed, version tolerant and compact binary format.... 
In fact, come to think of it, I should do this editor first (still working on data model) and whether it is comprehensive enough or not I shall add .zip archive, so that additional tweaking can be manually made...
|
|
|
|
|
Super Lloyd wrote: the point of using a .zip archive (which will require a properties.json to add missing information) is to let (power-)users open the file and rip the images out. And also perhaps even edit the image maps (rectangle list) with a text file.
I'd need to understand the reason you want that functionality in order to understand your choices.
cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
resource bag is a bunch of image and image map (i.e. image reference + rect).
- people might think "this image is cool I would like to use it"
I want to make that easy. if resource bag is zip archive user can just open it and get the images. on the other hand they could drag and drop from the editor (since I plan to support drag and drop to and from explorer) - people might think this rect is not quite right, or want to add a bunch of rect and might be somehow unsatisfied with the editor
come to think of it, it should not be a big deal to make editing of rect list satisfactory in the editor
the only thing that I might think of would benefit manual editing is about vector image.. I haven't done the editor yet.. but I imagine I will have to give them a default size, and when I change the default size, I imagine the rect list might end up full of rectangle with rounding issues...
and also drag and drop to another target than explorer might not work too well...
|
|
|
|
|
Super Lloyd wrote: 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...
am confused by this: is it a warning, or is it reassurance ?
thanks, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
it's a reason a well known format is "less mandatory" (in the unlikely case my app become super famous)
anyway I came to a final conclusion. I must finish data model first (almost done), then finish the resource editor... then whether the editor let me easily rip files or not and manipulate image maps would be my cue whether I need the JSON file format or not...
|
|
|
|
|
|
I'm waiting for when I can 3D print a starship. Hasta la vista, baby!
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
|
|
|
|
|
You already can. All you need to do is to load the flux capacitors in your 3D printer with antimatter, and you're ready to go.
(You'll probably end up in the Undiscovered Country, but don't blame me...)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Certainly beats 2D printed houses 
|
|
|
|
|
Shimmering, I smell after journey (10)
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!
|
|
|
|
|
Nice One, Liked it..
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
So did I! 
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!
|
|
|
|
|
iridescent
iridescent
Iridescent
smell afer ride 
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
pkfox wrote: smell afer ride
Close enough! "I RIDE SCENT" was what I was looking for, but that'll do!
You are up tomorrow!
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!
|
|
|
|
|
That is what I meant
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
