LiveCycle: Load JSON data into pre-existing objects - javascript

A quick overview of the situation:
For simplicity of complicated data, I've got a series of JavaScript objects (built using function Object Factories) that handle auditing data, so for example, you have a child object inside a parent object inside a user object (these are basically arrays). These objects contain functions that help process the data they contain, both in and out, when in the UI.
On the top level, a single JSON function call pulls the data the objects contain out, without the functions (which is what I want to happen, as only the data is stored in an external database).
The problem
However, on pulling the information back from the database, using JSON.parse and assigning the result into the top level object holder obviously only contains just the data, no functions.
Bearing in mind the object arrays won't be initialised (as they won't know the length until extracted from the JSON data), how can I reinsert the JSON data back into the objects, functions included?
Is there some way of saying to the parser 'for this level of data, use this object, for this level, use this one'?
[Note: due to the nature of the organisation and security, external libraries aren't permitted. No jQuery suggestions etc.]

Related

Sharing array of nested objects between workers

I have an array of objects which contains more objects as values. I'm working with Web Workers and I need to use this exact array of objects (or another object) in worker file. Problem is I couldn't find any solution to forward this array or object from main file to worker.
I cannot use Shared Array Buffer because it needs Typed Arrays (or I couldn't find any solution). And stringifying doesn't work because after parsing the reserve array that keeping my objects which I am using to compare can not recognize object.
Two threads cannot share an array of objects. While it's possible to transfer arrays with some objects in them between threads (where the source thread loses access to those objects, until or unless the target thread sends them back), you can only do that with transferrable objects, and plain objects are not transferrable.
You'll need to use some kind of serialization turning the objects into strings or transferable objects, and then handle deserializing them.
And stringifying doesn't work because after parsing the reserve array that keeping my objects which I am using to compare can not recognize object.
You'll need to give them unique IDs that allow you to relate the serialized version back to the original.

Why is serialisation necessary for sending data?

I've been reading up on JSON and serialization, from what I understand JSON is a format often used for transferring data over a network e.g. from/to a web server or storing the data to disk.
The data could be strings, numbers, objects etc. I haven't found a clear explanation for why the serialization is needed, for instance when sending a string to a web server or saving it to disk, isn't the string already stored as a series of bits and bytes by the computer, isn't this the most basic form for the data? so why can't these be sent/stored as they are?
Why does it need to be stringified into JSON i.e. serialised, which turns it into a string?
To be clear, I'm asking why it's needed and a simple clear explanation for that.
Thanks
Broadly speaking serialization does two important, mostly independent jobs:
collects all the information into a single "chunk" (stream) of data that's self-contained and
turns all the information into an agreed-on format (usually optimized for either compactness or ease of parsing)
#1 is important because a single object with many properties and sub-object can be spread all over the memory of a running program.
For example a JavaScript runtime could have a dedicated memory pool for strings constants. Then an object that uses some constant as a key would just reference into that pool from its data structure. That means that the object is no longer in a single self-contained block in memory: it's spread out over multiple areas. This kind of spreading-out is actually the norm: objects don't usually contain complex data directly and depending on the language even "primitive" values such as number could be stored as references to another place in memory.
#2 is important mostly because the format used to quickly access data in-memory might not be suitable to transfer (because it might contain unnecessary redundancy or memory pointers that don't make any sense when transferred to another computer, which partially ties to reason #1).
An example of that would be a map (or dictionary): the in-memory representation will usually involve multiple buckets that hold hashed-values and some kind of collision-handling structure inside those buckets (a linked list or a tree, for example). That structure helps with efficient access to separate keys, but transferring that structure directly over the wire is pointless: it's very easy to re-build and there's no guarantee that the receiving end uses the exact same way to represent a map. So instead we just send each key and the associated value and let the receiving end deal with re-constructing any data structures it needs for efficient access.
The simple reason is that data can be stored differently in memory on different computers, or even by programs on the same computer written in different programming languages.
Serialization formats like JSON provide a defined way for exchanging data between computers or programs.
Not everyone knows how to parse or interpret those series of bits. Sometimes you need some general structure, some format, that can be passed around so that other people understand what it is you're trying to tell them.

Redux multilevel nested entities

I've got some data that looks like:
videoGameCharacter:
----data
----actionSequence:
--------data
--------actionsArray:
------------data
and so on.. So my corresponding characterReducer holds an array of videoGameCharacter objects.
The question :
a) would you recommend i broke this up into a less nested format making it more flat and referencing everything with keys? I dont know if it should make a difference at all. Its the first time im dealing with data that belongs together so strictly having this many nested entitities with nested entities.
b) if not, should the one api call retrieve data in this format or should i keep the data in the corresponding seperate api calls? currently iv e structured my api call to return data as displayed above and even though this saves me some extra calls to the server it makes things a bit more complex.

Can you store a reference to a mongo collection?

At the top of a file can I put something like...
var collection = db.mongo.collection('test', function(err, collection){return collection});
and then in any of the files functions use collection.find() etc
I guess my question is... is collection a reference to the collection or a copy of the data?
If data in the collection changes will i still get up to date data by querying the collection variable?
Thanks!!
Collection is a reference for the collection object. Until you issue a find (or findOne) you don't have real data in your hands. And even then, it returns a Cursor object leaving the collection object always untouched.
Storing both Collections or cursors will not store your data. remember that you could be dealing with millions of records. dealing with data itself could be overwhelming for the server memory. Instead, mongo returns cursors and references for you to filter away. In PHP you have a function called iterator_to_array that you can pass it the cursor and it converts to an array of data. In javascript I don't know if there is such functions. But I guess it doesn't makes sense to be such functions. Filter the information until you have manageable data size, then iterate over the cursor and do your thing. If you have something like a config array or such, intead of several documents, try to store everything on one and fetch it with the findOne() function.
But in the end I guess that's just a design question whether your data is possible to filter or not.

How to create a tree representation of generic JSON data in HTML?

I have some data stored in JSON format. I would like to be able to display it in a browser as a dynamic tree structure in a similar way MongoVUE presents the mondodb documents:
Screenshot
I have found a very nice jquery plugin, called jsTree. Unfortunately, in order to process JSON documents it requires data to have a very specific verbose (and redundant, in my opinion) structure: link. Using it means significant modifications of my json documents. I am rather searching for a tool that is able to build the tree automagically, without making severe manual adjustments to the data, yet allowing me to potentially apply some modifications to the view, if I would need to.
The tool at json.bloople.net makes something similar using a table, but because I have several levels of nested documents, the output looks very bloated. Moreover, the structure is not dynamically collapsible.
I would appreciate any hints regarding the right tools to do the job, including both those that might require (automated!) pre-processing of JSON data in Java/Groovy or pure JavaScript-based solution.
This is just a simple example of how you could output a tree like JSON structure in html. http://jsfiddle.net/K2ZQQ/1/ (see here for browser support for white-space). Note that the second parameter to JSON.stringify is a replacer function:
From http://msdn.microsoft.com/en-us/library/ie/cc836459(v=vs.94).aspx
If replacer is a function, JSON.stringify calls the function, passing
in the key and value of each member. The return value is used instead
of the original value. If the function returns undefined, the member
is excluded. The key for the root object is an empty string: "".
So if you need to add any further modifications to the dislpay of your JSON tree the replacer function may be of help.

Categories

Resources