Incorrect documentation around templating about apimocker HOT 10 OPEN

Quick solution is to implement the fix and issue a PR against the project with tests to show it works. I like your idea and so I will be issuing a PR with your proposal as well as some README fixes. Stay tuned.

from apimocker.

from apimocker.

Thanks for pointing this out. And I’m glad to hear someone is using this thing! 😄 Is it a new problem? Was this ever working? Thanks.

from apimocker.

Greg, Mark points out two main issues which I'll try to summarize:

• README example is incorrect with regard to the JSON returned from templated "@Number". Quotes do appear in returned JSON.
• Using @Number without quotes in a JSON file means the template mock file is invalid JSON

Yes the template and templateSwitch features are working, but in order for a templated JSON file returned to contain a number value (not quoted), the template JSON file would also be unquoted and thus, not be a valid JSON file. The template mock file being invalid JSON is not an error per se, since the template mock could be another type of file such as HTML.

from apimocker.

Hi guys! Shared the update with the team here at Citi. Lots of happy people including management!

Quick thought... originally I was thinking @@tag was the best solution, but I've sort of had a change of heart and now think @#tag is clearer. That keeps the single '@' representing a normal replacement, wherever it's found, and then allows the edge case of a number where that's the only thing between the quotes. It also has the side-benefit of making the replacements no longer depending on searching for the numeric-only version first.

What do you guys think?

I've also added a comment to the PR about the text on the help page.

Finally, sorry again about not being able to create PR's here to GitHub. I'm trying to get an exception for things like this, but even though our team is agile, Citi's security is like trying to turn three oil tankers welded together.

from apimocker.

Crap! Damn iPhone! Didn’t mean to close that. Sorry. Disregard.

from apimocker.

Hey David, saw you updated the PR. I like the changes! Question though... did you see my comment above about using "@#tag" instead of "@@tag"? I think it reads more clear and separates intent. Now '@' simply means 'a replacement tag' whereas '#' means '...with the number format rules'

from apimocker.

I could go either way. My only concern with using @#Number instead of @@numbe is just another syntax to remember. @gstroup, what are your thoughts?

from apimocker.

Probably either syntax is OK. @# or @@. The only question I have is - what about a boolean value? If we use something like "@@isActive", then it would return an actual boolean value, right? Not the string "true"? For this reason, I think the @@ syntax might be better. @@ could apply to numbers, booleans, etc. What do you guys think?

from apimocker.

@gstroup, good point about the boolean. I hadn't considered that, but you are right, booleans aren't numbers but don't appear in quotes either.

Even more to the point, that's technically a json rule, not a 'response' rule. What about xml responses? HTML? CSV? I keep forgetting this tool is for mocking any APIs from a server, not just microservices returning json as we're using it.

To that effect, I think the rule should simply be this: '@' means 'replace with value' and '@@' means 'replace with value while also consuming any surrounding quotes'. Makes no mention about formats, etc. In other words, how that's used is completely up to the developer. (i.e. it can help with things like JSON, but technically isn't required if you don't care if your source template is still valid.)

Consider my mind changed. Let's stick with @@ as it is now.

from apimocker.