clearsilver support JSON as input

This would give clearsilver a new life here in 2020 :)

May 18 '20 13:05 petri

I'm curious to know how you'd like to use a JSON+Clearsilver hybrid.

What language would you use it from? Do you anticipate Clearsilver would include a JSON parser? Or would you want to support some existing JSON parser's data-structures? Do you want to parse HDF to JSON also?

If this is from Javascript, have you considered using Liquid or doT?

https://shopify.github.io/liquid/basics/introduction/ https://github.com/olado/doT

One of the small wrinkles in applying Clearsilver to JSON, is that Clearsilver's HDF is an ordered hash/list hybrid, like Ruby's hash. However, JSON has two different constructs, a numeric indexed and ordered list and a random-ordered hash (object).

https://stackoverflow.com/questions/3948206/json-order-mixed-up https://stackoverflow.com/questions/31418673/is-order-of-a-ruby-hash-literal-guaranteed

JSON also lacks out-of-band attributes... which in Clearsilver HDF files are normally used for marking strings as translatable strings for the translation tools to pick up.

Images {
      top {
	height = 512
	width = 512
	url [url] = /img/loc/top.gif
	alt [lang, lang=en, desc="The end of \n the world?"] = ClearSilver Rocks!
      }
    }

Of course one could just give up attributes, or perhaps encode them using some wacky convention... The readability of this is quite aweful beacuse of JSONs need for all those quotations.

"Images" : { 
  "top" : {
     "height" : 512,
     "width" : 512,
     "url" : "/img/loc/top.gif",
     "alt" : "ClearSilver ROcks",
     "alt__ATTR" : { "lang" : 1, "lang" : "end", "desc" : "The end of \n the world?" }
   }
}

May 19 '20 05:05 jeske

I've used clearsilver with Python many, many years ago so that's where I'm coming from. I was thinking that since JSON is a lingua franca for many apps nowadays, various client libraries would find it easier to pass JSON to clearsilver rather than HDF, or, map their own language-specific data structures to JSON instead of HDF. But this may indeed have been a premature presupposition: I don't know if the challenges you pointed out can be overcome if JSON were to be used.

May 19 '20 15:05 petri

In most scripting languages, it's probably < 10 lines of code to recursively walk JSON and inject it into HDF -- or vice versa. If someone wants to experiment, this would be the place to start.

HDF was designed to be easier to work with than XML when values are mostly short (<1 line) strings... and I think it has similar advantages over JSON -- which is just littered with quotation marks. I'd much rather look at and edit HDF files. Analagously, Clearsilver templates are similar to XSLT, but much easier to read and work with in many cases.

The JSON syntax wasn't "designed", as much as evolved from the technique of reusing the browser Javascript parser to inject data into running browser page contexts. However, this eventually changed and now the JSON subset is parsed even in browsers (to prevent security vulnerabilities), which makes it's syntax lineage with Javascript merely accidental history.

I personally find it painful that there are no comments in JSON, especially for config files. Supposedly this is because people were starting to put parsable elements in JSON comments (which I can understand). However, if JSON had added something like HDF attributes, perhaps this would not have been necessary.

If was to take a stab at modernizing Clearsilver for 2020, I'd probably take the opposite route, and offer a way to decouple Clearsilver from it's native C library.... probably by writing an implementation in Haxe, which could be transpiled into many managed languages. Then we could more easily use the nicer HDF syntax in more places that JSON is cropping up today.

May 19 '20 16:05 jeske