summaryrefslogtreecommitdiff
path: root/json-glib/json-gobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Fixed json_deserialize_pspec() to handle null nodes.Tristan Van Berkom2011-05-031-1/+13
| | | | This fixes deserialization to match serialization (bug 648539)
* Warn from json_gobject_deserialize() if a listed property cannot be ↵Tristan Van Berkom2011-04-231-0/+3
| | | | deserialized.
* gobject: Fix deserialization of construct-only propertiesEmmanuele Bassi2010-09-251-2/+2
| | | | | | | | Commit 2d7550948dfb2e5907b851bc2c4bd296a7526086 broke the construct-only properties; we now only check for the G_PARAM_CONSTRUCT_ONLY flag, and pass construct-only properties to g_object_newv(); all the properties flagged as G_PARAM_CONSTRUCT gets passed with the rest of the properties after that.
* debug: Add debug notes in the GObject codeEmmanuele Bassi2010-09-251-2/+12
|
* Add introspection annotationsEmmanuele Bassi2010-09-251-2/+2
|
* gobject: Use construct and construct-only propertiesEmmanuele Bassi2010-08-151-1/+1
| | | | | | | Right now, we're checking twice for G_PARAM_CONSTRUCT_ONLY, but what we really want is to check for both G_PARAM_CONSTRUCT and G_PARAM_CONSTRUCT_ONLY properties when creating a new instance from a JSON definition.
* Initialize out variables before using themVincent Untz2009-12-291-2/+2
| | | | | | | | | | | Here's a small patch for json-glib, to fix some gcc warnings breaking the build with -Werror (gcc can't know if the variable will get initialized or not). I didn't find a product for json-glib in bugzilla, but I guess a mail will work ;-) Happy holidays :-) Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
* docs: Fix annotation for json_gobject_to_data()Emmanuele Bassi2009-11-291-1/+1
|
* boxed: Split (de)serialization registrationEmmanuele Bassi2009-11-231-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A GBoxed type defined as: struct Boxed { int foo; gboolean bar; int baz; }; Can be represented either by a JSON object: { "foo" : 1, "bar" : true, "baz" : 3 } Or by a JSON array: [ 1, true, 3 ] The current function for registering a serialization and a deserialization pair does not allow registering more than one deserialization function - which means that there can only be one way to deserialize a GBoxed type into a specific JsonNode type. To allow having more than one JsonNodeType associated to a GBoxed type and a deserialization function we need to split out the registration of the serialization and deserialization functions into two distinct functions.
* serializable: Make Serializable in charge of parsingTristan Van Berkom2009-11-121-2/+5
| | | | | | | | | | | | | | If a GObject class implements JsonSerializable and has overridden the serialize_property() vfunc then the Serializable should be fully in charge of serializing a property - that is: JSON-GLib should not try to add a fallback in case the serialize_property() implementation returned NULL. This is a change in semantics for JsonSerializable implementations. http://bugzilla.openedhand.com/show_bug.cgi?id=1859 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
* gobject: Use from/to data naming conventionEmmanuele Bassi2009-10-281-4/+59
| | | | | | | | | | | | | | | | | | | | | | Be more GLib-like, and use <namespace>_<type>_from_data() <namespace>_<type>_to_data() Instead of the homebrew "construct" and "serialize", when dealing with string buffers. This means: • adding json_gobject_from_data() to deprecate json_construct_gobject() • adding json_gobject_to_data() to deprecate json_serialize_gobject() The json_construct_gobject() function also contains a mistake: it uses gsize with the special value of -1 meaning "slurp the whole string", but gsize is an unsigned type. The newly added json_gobject_from_data() correctly uses gssize instead.
* gobject: Uniform JSON<->GObject mapping codeEmmanuele Bassi2009-10-281-28/+54
| | | | | | | | | Rename json_gobject_new() to json_gobject_deserialize(), and json_gobject_dump() to json_gobject_serialize(); this maps the JSON GBoxed API. Also for consistency, change the serialize() return value and the deserialize() argument to be JsonNodes of type JSON_NODE_OBJECT.
* build: Split out GBoxed and SerializableEmmanuele Bassi2009-10-271-367/+4
| | | | | | The json-gobject.c is getting pretty crowded; we should split out the JsonBoxed API and the JsonSerialized implementation into their separate source files.
* gobject: Make GObject<->JsonObject functions publicEmmanuele Bassi2009-10-271-2/+28
| | | | | The functions mapping a GObject to and from a JsonObject should be public, as they can be used by parsers.
* gobject: Reuse the list dataEmmanuele Bassi2009-10-271-1/+1
| | | | | | | | | | | Since we ignore all members that don't have a corresponding GParamSpec for the class we cannot use: members = g_list_prepend (members, pspec->name); Because pspec might also be NULL. We can reuse the GList iterator data field, since that points to data internal to the JsonObject we are iterating over.
* gobject: Add experimental GBoxed<->JSON transformationEmmanuele Bassi2009-10-271-2/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Serializing and deserializing GBoxed types is fairly complicated currently. If a GObject implements JsonSerializable it is possible for the class to intercept the JsonNode, parse it manually and then set the value to the property. This leaves a hole opened for: • manual (de)serialization of GBoxed types • (de)serialization of GBoxed properties in classes not implementing JsonSerializable In order to serialize and deserialize a GBoxed JSON-GLib should provide a mechanism similar to the GValue transformation functions: when registering the boxed type the developer should also be able to register a serialization and a deserialization functions pair matching the tuple: (GBoxed type, JSON type) The serialization function would be: JsonNode *(* JsonBoxedSerializeFunc) (gconstpointer boxed); And, conversely, the deserialization function would be: gpointer (* JsonBoxedDeserializeFunc) (JsonNode *node); Obviously, the whole machinery works only for GBoxed types that register the serialization and deserialization functions.
* Remove a stray ';' that broke deserializing GStrvEmmanuele Bassi2009-10-271-1/+1
| | | | | The stray semicolon was preventing the GPtrArray from being updated.
* Fix compiler warnings (remove unused variables)Emmanuele Bassi2009-10-271-2/+1
|
* gobject: Support constructor propertiesEmmanuele Bassi2009-10-271-11/+87
| | | | | | | | | | | | The GObject deserialization code currently skips all the constructor and constructor-only properties. In order to implement them we can add a preliminary pass on the JSON object members and build a GParameter array. As we don't have a GObject instance we cannot really use the Serializable interface to provide custom parsing for complex data structures, thus we fall back to the default deserialization code path.
* gobject: Serialize properties holding a GObjectEmmanuele Bassi2009-10-271-0/+14
| | | | | Like we deserialize them, we can serialize GObject properties defined using GParamSpecObject.
* gobject: Split GObject serialization codeEmmanuele Bassi2009-10-271-52/+61
| | | | | | Like for the deserialization of a GObject into a JsonObject we should split out the serialization of a GObject into a JsonObject part of json_serialize_gobject() into its own private function.
* gobject: Recurse in GParamSpecObject propertiesEmmanuele Bassi2009-10-271-1/+13
| | | | | | | | | | | | | Use the newly added json_gobject_new() internal function to recurse into properties defined using GParamSpecObject. The same rules used by json_construct_gobject() apply to the properties storing a GObject - including JsonSerializable support. The test case for serialization and deserialization of a GObject has been updated to include a property holding a GObject.
* gobject: Split JSON to GObject codeEmmanuele Bassi2009-10-271-69/+83
| | | | | | If we want to be able to parse a GParamSpecObject property we need to use the same code as json_construct_gobject(), minus the parsing.
* [docs] Small documentation fixesEmmanuele Bassi2009-09-021-12/+12
| | | | Clean up some notes, and add introspection annotations where needed.
* Auto-promote integer types to G_TYPE_INT64Emmanuele Bassi2009-08-121-13/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The JSON RFC does not specify the size of the integer type, thus implicitly falling back to machine-size. This would all be fine and dandy if some demented Web Developer (and I use the term "developer" *very much* loosely) did not decide to use integers to store unique identifiers for objects; obviously, you can't have more than 2^32-1 status messages in a database with millions of users who update their status multiple times per day. Right, Twitter? Anyway, some languages do a type auto-promotion from Integer to Long, thus pushing the limit of allowed positive values -- until the next integer overflow, that is. C, and GLib, do not do that transparently for us so we need to: - always use gint64 when parsing a JSON data stream using JsonScanner - move all the Node, Object and Array APIs to gint64 - auto-promote G_TYPE_INT to G_TYPE_INT64 when setting a GValue manually - auto-promote and auto-demote G_TYPE_INT properties when (de)serializing GObjects. The GLib types used internally by JSON-GLib are, thus: integer -> G_TYPE_INT64 boolean -> G_TYPE_BOOLEAN float -> G_TYPE_DOUBLE string -> G_TYPE_STRING
* [node] Make JsonNode completely privateEmmanuele Bassi2009-06-091-0/+2
| | | | | | | | | | The JsonNode structure has always been meant to be completely opaque; we indirectly exposed the :type member, but only for access through the JSON_NODE_TYPE() macro. Since that macro has become a proxy for the json_node_get_node_type() function we can safely move everything into a private, uninstalled header file and let JsonNode be completely opaque to the developer.
* Intern the remaining type namesEmmanuele Bassi2009-04-171-1/+2
| | | | | JsonArray and JsonSerializable type names should be interned like the rest of the types.
* Update after the json_object_add_member() deprecationEmmanuele Bassi2009-04-171-1/+1
| | | | | | | Since json_object_add_member() has been deprecated and it's using a gcc compiler attribute to loudly complain while compiling the library, we should restore the sanity and use json_object_set_member() instead.
* Correctly terminate a string arrayEmmanuele Bassi2008-11-031-1/+3
| | | | | | | | | | | | | | When converting from a JsonArray of strings to a GStrv we need to add a NULL at the end of the GPtrArray we use to perform the conversion. This two lines patch fixes the issue. See bug 1203. Patch by: Kouhei Sutou <kou@cozmixng.org> Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
* Use an array to hold the strings in a vectorEmmanuele Bassi2008-05-011-10/+5
| | | | | | | | | Instead of building a GString by concatenating every string inside an array to deserialize the array into a string vector property, use a GPtrArray. This is far more efficient (no reallocations are necessary, as we know the size of the array) and safe (the separator used to build the string buffer and then split it might exist in one of the original strings).
* Update after the JsonParser::get_root changeEmmanuele Bassi2008-01-291-3/+1
| | | | | Do not free the root node returned by the get_root() method in the JSON-GObject API and in the JsonParser tests.
* Wrap config.h include with conditionalsEmmanuele Bassi2007-12-251-0/+2
| | | | | Including the autotools generated config.h should always be conditional on the HAVE_CONFIG_H definitions.
* Provide a default implementation of JsonSerializableEmmanuele Bassi2007-12-251-88/+120
| | | | | | | | The JsonSerializable interface can provide a default implementation, using the powers of GTypeInterface. This means that classes implementing the interface can opt to implement both, either or none of the JsonSerializable methods, and still be able to retain some basic functionality for the methods they decide not to implement.
* Free the root node obtained using json_parser_get_root()Emmanuele Bassi2007-11-211-0/+2
| | | | | Update json_construct_gobject() to the change of behaviour in the root node getter function of JsonParser.
* Allow deserialization of strings into enums/flagsEmmanuele Bassi2007-11-201-0/+170
| | | | | | | | If the target value is a G_TYPE_ENUM or a G_TYPE_FLAGS we can effectively deserialize a string into the corresponding value (or bit mask) using the introspection API for the GEnum and GFlags types. This code is taken from ClutterScript and it was adapted from GtkBuilder.
* Change "responsible" to "asked" in the (de)serialization functions docsEmmanuele Bassi2007-11-131-7/+8
| | | | | We provide fallbacks in case a JsonSerializable object does not translate a property into a JSON object member and vice versa.
* Use the fallback value-to-node generator even for serializablesgobject-deserializeEmmanuele Bassi2007-11-131-6/+11
| | | | | | | To avoid reimplementing the same code all over again, if the implementation of the serialize_property virtual function of JsonSerializable returns NULL we will fall back to the simple value-to-node generator we provide for non-serializable classes.
* Fix a couple of dumb typos in the GObject deserialization codeEmmanuele Bassi2007-11-131-2/+4
| | | | | | We need to skip if the CONSTRUCT_ONLY flag is set, not unset. We also need to copy the value from the JSON node into the target GValue, not the other way around.
* Add node-to-property simple fallback parser for deserializationEmmanuele Bassi2007-11-131-9/+85
| | | | | | | | | The fallback parser for json_construct_gobject() is invoked if the GType does not implement the JsonSerializable interface, or if the interface was not handling the property. It will natively convert integers, booleans, strings and double precision floating point values; it also handles string vectors in form of arrays.
* Initial implementation of GObject deserialization functionEmmanuele Bassi2007-11-101-12/+170
| | | | | | | | | | The json_construct_gobject() function takes a GType and a JSON data stream and constructs a new instance for the given type. If the type is a JsonSerializable, it will use the JsonSerializable interface for parsing the JsonNodes of each object member. This is the initial implementation of the function: the JsonNode-to-GValue fallback parser is just a stub.
* We need the actual implementation of the JsonSerializable GType functionEmmanuele Bassi2007-10-161-0/+6
| | | | A placeholder, while syntactically correct, won't do.
* Add the JsonSerializable interfaceEmmanuele Bassi2007-10-161-31/+157
| | | | | | | The JsonSerializable interface allows implementations to override the GObject-to-JSON serialization process, by providing two virtual methods to control the (de)serialization of GObject properties. This way it's possible to serialize GObjects with properties holding complex data types.
* Add GObject serialization support for JSON-GLibEmmanuele Bassi2007-10-021-0/+169
This commit adds json-gobject.h and json_serialize_gobject() to JSON-GLib, to serialize a GObject instance into a JSON data stream.
View Lorry Controller Status