Incorrect documentation around templating #84
Description
Hey! Really great tool. We depend on this heavily here at Citi for our mobile apps.
Just wanted to call out an issue we had that unfortunately was caused by incorrect documentation here in your 'readme.md' file. Specifically, it's around templating.
In your example, you stated that for this configuration...
"template/:Name/:Number" :{
"mockFile": "templateSample.json",
"verbs":["get"],
"enableTemplate": true
"contentType":"application/json"
}
With this template...
{
"Name": "@Name",
"Number": "@Number"
}
When you call /John/12345 you claim it will return this:
{
"Name": "John"
"Number": 12345
}
But we're actually getting this...
{
"Name": "John"
"Number": "12345" <-- Note the quotes
}
For one of our service calls, we needed the non-quote-wrapped number.
The confusion came in when we opened up our template in a JSON editor and tried removing the quotes around '@Number' but it started barking at us that we now had invalid JSON, so thinking that wasn't the correct approach, we abandoned it.
The problem is that actually is the correct way to format the template to have it return the placeholder without quotes. It just means that your template pre-filled-in is not valid JSON, and thus has to be edited with a text file. That's what tripped us up.
If you put a note/caveat/warning/whatever stating that if you need the non-quoted version, your template will no longer be valid JSON, but is still valid for Mocker (since it will become valid once merged) it would've gone a long way to helping people like us avoiding going down a rabbit hole trying to debug something we didn't actually have to debug.
That said, have you considered doing something like this for the tokens you don't want to have to wrap?
"#Number" or
"@@Number" or
"@Number@"
etc...
By implementing something like that (I'm personally partial to the '@@' myself) we can still keep our templates editable with a JSON editor without sacrificing output which is essential considering we run validation scripts against our JSON response files and now we have to explicitly exclude one.
It shouldn't be too difficult to implement with RegEx either. Just search for that version first, consuming the quotes as part of the search, then run the parsing again with the second flavor just as you do now. (You may even be able to format a single RegEx that handles both!)
Anyway, hope this helps. Again, keep up the really, really great work!
Mark