summaryrefslogtreecommitdiff
path: root/json-glib/json-gobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix translator commentsPiotr Drąg2017-01-281-1/+1
| | | | They need to be exactly one line above a string to show up in .po files.
* node: Add json_node_ref() and json_node_unref()Philip Withnall2016-03-011-2/+2
| | | | | | | | | | | | | | Add reference counting semantics to JsonNode, in addition to the existing init/unset and alloc/free semantics. json_node_free() must only be used with nodes allocated using json_node_alloc(). json_node_unref() may be used with all nodes (if correctly paired; it may be paired with json_node_alloc()). It is not valid to call json_node_free() on a node whose reference count is not 1. https://bugzilla.gnome.org/show_bug.cgi?id=756121
* Handle serialization/deserialization of glong gulong and guint64Tristan Van Berkom2014-12-301-0/+28
| | | | | | | | Long and unsigned long was properly serialized but not deserialized, guint64 handling is not ideal as the type is cast into a gint64, however this is better than not handling the fundamental type at all. https://bugzilla.gnome.org/show_bug.cgi?id=725972
* Remove conditional inclusion of config.hEmmanuele Bassi2014-03-181-2/+0
| | | | All the platforms and build system we support have a config.h header.
* docs: Port to MarkDownEmmanuele Bassi2014-03-181-2/+2
| | | | | Drop the DocBook documentation, and move everything to the MarkDown format used by modern gtk-doc.
* Remove compile time GLib version checkEmmanuele Bassi2013-08-211-8/+0
| | | | | We depend on a new version of GLib, so we can remove a bunch of old version checks.
* Use typed initializers for JsonNodeEmmanuele Bassi2012-10-271-63/+52
|
* gobject: Use JsonSerializable APIEmmanuele Bassi2012-10-261-7/+9
| | | | Instead of directly accessing the vfunc from the interface vtable.
* Use g_value_[sg]et_schar() with GLib ≥ 2.31Emmanuele Bassi2011-10-121-1/+9
| | | | The non-explicitly signed variant is deprecated.
* gobject: Deserialize CONSTRUCT propertiesEmmanuele Bassi2011-08-231-8/+5
| | | | | | | | | | | | While we have to give up deserializing CONSTRUCT_ONLY properties with JsonSerializable, CONSTRUCT properties should just be deserialized like any other property. Sadly, there's still a refuse in the json_gobject_new() code that skips CONSTRUCT properties along with CONSTRUCT_ONLY ones — a remnant of a period when we deserialized them both without JsonSerializable. https://bugzilla.gnome.org/show_bug.cgi?id=655526
* Handle integer to float/double conversions in json_deserialize_pspec()Tristan Van Berkom2011-07-311-1/+21
| | | | | | | It happens that while serializing that float/double properties are set to round numbers, this results in deserialization as gint64 values and a parse failure. This patch addresses it by accepting round gint64 numbers as valid values for float/double properties.
* Added an additional warning to json_gobject_new()Tristan Van Berkom2011-07-131-1/+6
| | | | | | The same warning that is fired when failing to deserialize properties normally needed to be added for the case that we fail to deserialize construct-only properties.
* Avoid serializing default property values only afterTristan Van Berkom2011-07-091-8/+2
| | | | | | | | consulting the JsonSerializable. This patch gives the JsonSerializable class a chance to decide whether it's appropriate to serialize a property before JsonGObject checks for a default value and skips the property.
* Fixed badly handled fundamental types in json_deserialize_pspec().Tristan Van Berkom2011-07-071-12/+30
| | | | | | | | This patch fixes json_deserialize_pspec() to return FALSE when failing to deserialize some properties. Consequently the patch ensures we get the intended warnings when failing to deserialize pspecs for some fundamental types: Failed to deserialize property "foo" of type "int" on object "bar"
* Mark GError messages for translationsEmmanuele Bassi2011-06-011-2/+2
| | | | These errors might find their way into a UI.
* Add i18n machineryEmmanuele Bassi2011-06-011-0/+2
| | | | We need to translate the GError messages.
* gobject: Do not serialize default valuesEmmanuele Bassi2011-06-011-0/+7
| | | | | If a property is set to its default value then we can skip its serialization, to keep the number of JSON object members down.
* serializable: Allow introspecting propertiesEmmanuele Bassi2011-06-011-9/+34
| | | | | This allows a Serializable implementation to override the property list, and the setter and the getter function.
* 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.
View Lorry Controller Status