For my project I need to store some settings during the session. For this I build up a JSON Object like this:
var oSettingsJSON = new sap.ui.model.json.JSONModel();
oSettingsJSON.setData({
"partially_search": "true",
"case_sensitive": "true",
"aSearchResults" : [],
"indexOfSearchResults": "0",
"searchedText": "",
"showId": "true"
});
So, now I got the idea to store this data in an object, becaus then I needn't to write every time model.getProperty(property) or model.setProperty(property, value).I understand JSON and objects, it's only about a best practiceor something to handle settings. What is more often used in the real world,or doesn't it matter what to use?
JSON stands for Javascript Object Notation. See here. Basically, if you want to store data inside a Javascript Object, then you should use JSON, since it is very simple to comprehend/use and there is virtually no server application technology without a parser for it. Since you are already using Javascript, JSON is recommended.
For instance this is a JSON object:
{
"partially_search": "true",
"case_sensitive": "true",
"aSearchResults" : [],
"indexOfSearchResults": "0",
"searchedText": "",
"showId": "true"
}
Related
I'm new to using postman to create tests for a simple api. As part of this I want to create a post request, then use the generated id in subsequent Get, Put and Delete tests. Below is how I'm saving the id as a variable (have also saved it in the environment) and my API schema.
pm.test("Status code is 201", function () {
pm.response.to.have.status(201);
var jsonData = pm.response.json();
pm.environment.set('todo2', jsonData.id)
});
{
"id": "integer",
"name": "string",
"isComplete": boolean
},
But when I try to call my Get request for that generated id using {{todo2}} in my header it instead returns everything from my API rather than the specific api which I thought I had saved in the variable. Can anyone help point me in the right direction, not sure where I'm going wrong.
are you sure you json is valid?
{
"id": "integer",
"name": "string",
"isComplete": "boolean"
}
you need double quotes for boolean value, because this is a string there.
Solved the problem! I was updating my environmental variables and trying to call global variables, so I was getting an undefined.
Solved by changing my code to the below and making sure I had declared my variables via the global environment menu on the top right.
pm.test("Status code is 201", function () {
pm.response.to.have.status(201);
var jsonData = pm.response.json();
pm.globals.set('todo2', jsonData.id)
});
I'm currently using node-ews in a project to access an Exchange Web Server via node.js. Now i ran into a weird problem. To run for example a "CreateItem" request, which can be an E-Mail or Appointment for example, I'm giving the function the arguments as a json similar to this
var args = {
"attributes" : {
"SendMeetingInvitations" : "SendToAllAndSaveCopy"
},
"SavedItemFolderId": {
"DistinguishedFolderId": {
"attributes": {
"Id": "calendar"
}
}
},
"Items" : {
"CalendarItem" : {
"Subject" : "",
"Body" : {
"attributes" : {
},
"$value" : ""
},
"ReminderIsSet" : "true",
"ReminderMinutesBeforeStart" : "30",
"Start" : "",
"End" : "",
"IsAllDayEvent" : "false",
"LegacyFreeBusyStatus" : "Busy",
"Location" : ""
}
}
};
As the REST-API I'm writing will receive Attributes like Subject, Start, End etc. I initially stripped out those out of the JSON and would define them later like
args.Items.CalendarItem.Subject = req.body.Subject;
Oddly this will make the internal validation of node-ews fail and tell me that CalendarItem has an invalid Child Subject. If i leave Subject als an empty string in the initial args and later change it set it to req.body.Subject it works just fine.
My question is this: Is the Object somewhat different if I later add attributes and if yes is there a way to do it right? Because I don't think its the best way to have a bunch of empty Attributes in my Object if they aren't used and define standard values for all of them even if api won't require them to be sent.
Would great if someone knew the answer. Hope i could clarify what the problem is
Ok,
so the problem seems to be this. Internally the JSON "object" seems to have an order based on the order the variable is defined. in JavaScript this is no problem. But when the xml is parsed, the tag that was defined last will also be at the end of the xml so if you had
<someTag>
<variable2 />
<variable3 />
</someTag>
and you add variable1 to your json by someTag.variable1 = x in the end the xml will look like this after beeing parsed by node-ews
<someTag>
<variable2 />
<variable3 />
<variable1 >x</variable1>
</someTag>
Now unfortunately the exchange web server seems to be picky about the order of the xml tags. so when you build your json be sure to use the direct order. Changing content of the json later will not affect the order.
I have a subject.js javascript file in which json data is stored:
Subject.js
Example:
Teacher = {
"Eng" : "English",
"Math" : "Maths",
"Sci" : "Science",
"SST" : "Social Studies",
"Hin" : "Hindi"
};
I want to read json data from this js file into another js file.
But I learnt that $.getJSON('filename.json', function(data) { is used to get data from json file but my json data is stored in js file. Can anyone tell me how to get started? I tried using getJson but can't get it to work.
There are two possibilities:
The file can just be included and use the teacher variable as if you ran the getJSON function.
The Teacher = and semi-colon at the end can be removed (verify it is a correct JSON structure) and save the file as .json. Assuming your server will send a JSON file, this should allow the file to be requested.
Remove the varibale declaration "Teacher =" and your js become a json content that can be called by $.getJSON
You simply need to include the file with your Teacher definition on the same page as your other JS file. Then you will have access to the variables defined in Subject.js. For instance:
<script src="Subject.js"></script>
<script>
console.log(Teacher.Sci)
</script>
would output Science to the javascript console.
JSON is not its own type in Javascript, it is simply a certain syntax for defining plain-old Javascript objects. JSON stands for JavaScript Object Notation. This is the JSON part of your example:
{
"Eng" : "English",
"Math" : "Maths",
"Sci" : "Science",
"SST" : "Social Studies",
"Hin" : "Hindi"
}
So when you set a variable equal to a JSON block as in your example, you are creating an object with those properties. As such, you can simply treat that JSON object like any other javascript object. The code you provided is the same as the following:
Teacher = new Object();
Teacher.Eng = "English";
Teacher.Math = "Maths";
Teacher.Sci = "Science";
Teacher.SST = "Social Studies";
Teacher.Hin = "Hindi";
$.getJSON, on the other hand, is used for converting a text file (or file output) in JSON notation into a javascript object, but that is not necessary in this case, as your JSON object is already created within the javascript code.
I want to create this parameter file so that I can send it to my web service.
var parms = {
"quiz_id":"120",
"owner_id":"1",
"solver_id":"1",
"answers":
[
{
"answer_text" : "YES",
"question_id" : "1"
},
{
"answer_text" : "NO",
"question_id" : "2"
},
{
"answer_text" : "YES",
"question_id" : "3"
},
{
"answer_text" : "YES",
"question_id" : "4"
},
{
"answer_text" : "YES",
"question_id" : "5"
}
]
};
I am stuck with the contents inside of the answers. I don't know how to create it dynamically.
for serializing Javascript objects to JSON strings either you can use
JSON.stringify(Object);
which is available in most of the latest browers, else you can use ExtJS inbuilt method
Ext.encode(Object);
and for deserializing JSON string you can use JSON.parse(JSONString) or Ext.decode(JSONString)
An easy way to do this is to create your data as a javascript object and then use a Json "stringifier" to turn it into a json string, which can then be passed to your server.
This same problem was answered previously at Serializing an object to JSON
If you use jquery (and I highly recommend it as a very useful tool for all serious javascript programmers), there is a nice plugin that I use for passing json back and forth in Ajax calls. See http://code.google.com/p/jquery-json/
Create an object with array and some objects inside and then look at the Ext.data.proxy.Server.encodeFilters() method.
I'm writing a simple web service that return a JSON response. It'll be heavily used, so I want to try and make the JSON response as small as possible for performance reasons. I'm on the fence over a design decision; penny for your thoughts!
My JSON response from the server looks like this:
{
"customers":
[
{
"id": "337",
"key": "APIfe45904c"
},
{
"id": "338",
"key": "somethingDifferent"
},
{
"id": "339",
"key": "APIfe45904c"
},
{
"id": "340",
"key": "APIfe45904c"
}
]
}
The APIfe45904c here is used in about 60-70% of the records, so I could also modify the the JSON response to remove the repeated information and add a default_key i.e. if there's no key specified, the client should assume the default_key like this:
{
"default_key": "APIfe45904c",
"customers":
[
{
"id": "337"
},
{
"id": "338",
"key": "somethingDifferent"
},
{
"id": "339"
},
{
"id": "340"
}
]
}
No client is using the web service yet, so this wouldn't break anything. Is this good practice? It works, and makes for a small JSON response, but I'm conflicted. I like the KISS principle for developers using the service, but I also want as small a JSON response as possible.
I was tempted to replace customers with c, id with i and key with k to aid reducing the file size, but I figured this will be a problem if I want to get other clients to start using it. Should I drop the idea of default_key for the same reason?
Each JSON response will likely be no more 200 lines of id/key pairs, so I don't need to incorporate pagination, etc.
I would keep it simple as you say, and then use gzip to compress it. It should compress very well as it is repetitive, and remains convenient for programmers.
See here for pointers in outputting gzip headers for AJAX: Is gzip encoding compatible with JSON?
Unless you have very special performance needs, I would always choose clarity over brevity. Especially for an API that is going to be used by many developers.
You should use the consistent format where each record has an id and a key field. What you lose in bandwidth you gain from not having to pre-process the JSON on the client-side.
I tend to analyze my JSON data structure like you but in the end it isn't worth the tiny bit of space you save. Your JSON data structure looks good... have you seen Twitter's JSON data structure? Now that is ugly.
I would go with the default key idea, but I wouldn't go as far as shortening the attribute names since that can be confusing. Perhaps you can take an argument from the web service call (from query string) that specifies whether or not the client desires to have shortened attribute names.