hjson

[mathiasrw]

I recommend that Jasonette supports config files in the hjson format ( http://hjson.org/ )

This would demand a parsing of the config file after downloading it before using it as its used today.

Pure JSON would still work, but errors like an extra , after last element in an array would not spoil it all.

Another plus is that the developer can have comments in the config file and comment whole sections out (not possible with JSON)

Update: Inspired by http://nshipster.com/javascriptcore/ I have a feeling it could be implemented without much fuzz with JavaScriptCore

let configfileContent = sameWayToFetchFileAsToday();

do {  
	let hjsonSrc = try String(contentsOfFile: 'path/to/hjson.js', encoding: NSUTF8StringEncoding)  
} catch let error as NSError { print("Error: \(error)")  }

let context = JSContext()

context.evaluateScript("var hjson2json = function(hjson){ return JSON.stringify(Hjson.parse(hjson), null, 4); };")

let hjson2json = context.objectForKeyedSubscript("hjson2json")

let configJson = hjson2json.callWithArguments([configfileContent])

You might want to use the hjson.js file from http://hjson.org/js/hjson.js where its already "browserified".

[gliechtenstein]

Thanks for the suggestion! Let me look into HJSON. Will keep you posted.

[gliechtenstein]

OK I've looked into HJSON and it won't be much of a problem to implement, especially since Jasonette already makes use of JavascriptCore in some cases.

I actually even started writing code and was almost half done when I started having some questions, so decided to throw them out here first before going forward with this:

1. Is there any popular server API that returns anything in HJSON format? If not, wouldn't one need to write an HJSON template engine to fill out the data when returning?
2. Also, do we really need Jasonette to be the one that translates HJSON? How about writing the markup in HJSON, but run it through a HJSON-to-JSON template engine on the server side before returning? (Example)

I guess I'm having these questions because there definitely are overheads for parsing on the client side. I think this on its own is worth it if I didn't have above questions. But if there aren't many HJSON-returning servers out there, I think it may be a better idea to build the HJSON-to-JSON adapter on the server side and let Jasonette deal with pure JSON.

But I'm just a HJSON newbie so please share your thoughts!

[marcelgleis]

my 2cts: we don't need hjson

[mathiasrw]

Is there any popular server API that returns anything in HJSON format? If not, wouldn't one need to write an HJSON template engine to fill out the data when returning?

If you have a templatingengine you can just as well produce JSON

Also, do we really need Jasonette to be the one that translates HJSON? How about writing the markup in HJSON, but run it through a HJSON-to-JSON template engine on the server side before returning? (Example)

Its for the convinience of people who edits things manually. When was the last time you had to edit a multiline field in JSON - it sucks... and tiny aspects about the JSON format as trailing comma makes it harder for new people to get on going.

This is for the onboarding of Jasonette. The overhead is minimal, and people generating JSON will not feel any difference.

[booc0mtaco]

Maybe HJSON support should come in the form of "you can use it if you want, but the app only supports JSON" In other words, tooling for using HJSON lives outside JSONETTE, and there's something like a plugin, which can convert those files into regular JSON. keeps the server and app clean, and let's people use what they want.

I assume this must already be possible. Let JSON be the assembly language of JASONETTE :)

[gliechtenstein]

@mathiasrw I was going to keep this open for a bit before deciding, but I think we have enough opinions on this and I also came to agree that it's better to do this on the server side.

Its for the convinience of people who edits things manually. When was the last time you had to edit a multiline field in JSON - it sucks... and tiny aspects about the JSON format as trailing comma makes it harder for new people to get on going.

I totally agree with your point, but I think my point was that we may be able to do this server-side, just like @booc0mtaco said. For example a user could write everything in HJSON, and host it on a pastebin service which internally stores it as HJSON but serves it as JSON using the server-side adapter. I already have a json hosting site for Jasonette apps running, and I can imagine supporting HJSON on the jasonbase site in the future.

Actually I have thought about this for the last couple of days and realized some of the actions I already have implemented are relevant to this discussion: https://jasonette.github.io/documentation/actions/#conversion

I wrote them during the early development stages of Jason. And if I think about it now, the $convert.html action is super useful and I think it deserves its place as an api. But I'm rethinking whether $convert.rss and $convert.csv should be in the main API set. Because there are a lot of useful data formats we can convert to JSON, but if we start adding them one by one this will become as bloated as regular web browsers.

Bottom line: Since all web servers can return JSON, I think it's better to write adapters on the server-side that turns whatever data format into JSON. That way it's much more scalable since we don't have to keep adding conversion features to the Jasonette binary every time we need to.

Hope this makes sense!