tl24/jsonexserializer

Automatically exported from code.google.com/p/jsonexserializer

Summary

JsonExSerializer is a serializer/deserializer framework for C# that uses JSON format for its storage format.
A small number of extensions are added to facilitate correct reconstruction of the object upon deserialization. It is mainly intended to serialize objects to and from a storage medium, but it fully supports being used in an AJAX/web environment as well. See the SetJsonStrictOptions on the extensions page for how to turn off the extensions if transmitting to a browser. See the Tutorial and Usage pages for examples on how to use it.

Why?

I wanted a framework that I could use to persist objects to disk. I also wanted something that was human readable and easy to edit. Binary serialization is not human readable, and I didn't want to use xml because I found it too verbose for this purpose. I examined a few other JSON packages, but found nothing that could recreate the object graph exactly as it was deserialized. Especially if normal OO techniques such as inheritance were used. None of the implementations could handle references as well, which was pretty important to me.

Features

• Easy to use: Serialize an object in about 2-3 lines of code.
• Deserialize objects exactly as you serialized them with [References] intact
• Supports classes, structs, Generics, properties and public fields
• Support for constructors with arguments
• Serialization can be controlled programmatically, with .NET attributes, or using app.config
• [TypeConversion Easy customization], just create a different object to serialize which could be a Dictionary, String, ArrayList or any other type that you choose
• Formatted output by default so its easy to read, or you can serialize it compactly if you choose
• Can be customized to use your own factories or dependency injection frameworks when constructing objects

Issues

Bug reports can be submitted to the issue log. Issues or questions about JsonExSerializer can be posted to the JsonExSerializer discussion group.

News

• 3.1.1.283 has just been released (Jan 24 2013). See ReleaseNotes for more details. Contains minor debugging enhancements.
• (Jan 24 2013) 4.0 release is in-process and will contain many new features to bring the codebase in-line with .NET 4.0 as well as other common frameworks. See the issue list for details.

See the wiki for more [Usage] and explanation of features.

jsonexserializer's Issues

Provide for TypeConversion

Allow for type conversion to convert an object to a more-suitable type for
serialization.

A converter can be specified in several different ways.  The forms are
list in order of precedence.  This order will be used in the
event that multiple converters exist for a given entity:
1. Registering a converter with the serializer instance.
Example: serializer.Context.RegisterConverter(typeof(MyObject), new
MyObjectConverter());

2. a converter attribute at the property level
[JsonConverter(typeof(SomeConverter))]
public string MyProp { get { ... } set { ... } }

3. a converter attribute at the class level
[JsonConverter(typeof(SomeConverter))]
class MyClass { ...

4. using System.ComponentModel.TypeConverterAttribute
This will only allow conversion to primitive types such as strings or number


- Converters should either implement an IConverter interface or provide an
AbstractBaseConverter abstract base class, depending upon which is the best
approach.

Converters can be chained by specifying the JsonConverter attribute
multiple times.  This will be implemented using a ChainedConverter class
instance.  This same class can be passed to the Register method as well.

Original issue reported on code.google.com by [email protected] on 6 Jun 2007 at 2:28

Support Collection properties with no Setter

It is often desirable to expose a collection from an object via only a
getter property and force clients to use the modifier methods on the
collection's interface rather than replacing the whole collection.  This is
especially important if the exposed property is an interface or abstract
type, but the class internally depends on a specific implementation.

Example:
public class Customer {
  private List<Order> _orders = new List<Order>();

  public ICollection<Order> Orders {
     get { return _orders; }
  }
}

Currently the serializer only supports properties with both a public getter
and setter.  Thus, a class has to provide a setter for serialization to
work.  Support should be added to allow either a collection, dictionary or
object type to work with only getter.  

1.  An attribute will be created to indicate that the property should be
serialized as it normally wouldn't be in this case and that should still be
the default behavior.
2. Upon deserialization instead of creating an instance of the class to be
held for the property, the value of the property will be retrieved from the
parent instance.  In this case the type used to expose metadata should be
the declared type of the property and not the actual object type.  
3. The desired type can be overriden in the attribute declaration if desired.
4. The attribute should be ignored on primitive properties
5. The converter attribute will be ignored and any converters defined for
the property type will be ignored


Attribute example:
[JsonExSerialize]  // use declared type on the property
public IOrder Order { ...

[JsonExSerialize(typeof(Acme.OrderImpl))]
public IOrder Order { ...

Usage:
public class Customer {
  private List<Order> _orders = new List<Order>();

  [JsonExSerialize]
  public ICollection<Order> Orders {
     get { return _orders; }
  }
}

Original issue reported on code.google.com by [email protected] on 21 Jan 2008 at 2:41

Can't Insert CollectionHandlers before the end of the list

What steps will reproduce the problem?
1. Have a strongly typed collection by extended CollectionBase
2. Build a handler for your collection
3. The default handlers contain a handler for IList, which CollectionBase
implements, so your custom handler never gets called.

Probably just need to give full access to the collection and get rid of the
"RegisterCollectionHandler" method.

Barring that, make the RegisterCollectionHandler method insert at the
beginning rather than the end, since you would always want a custom handler
to take precedence over the default ones.

Original issue reported on code.google.com by [email protected] on 10 Jul 2008 at 4:04

Common properties should be shared between base class and child class metadata

Currently each type creates its own property metadata for all properties.  
This means that for classes that use inheritance, and properties inherited 
from base classes have their own set of property metadata and thus changes 
made to them are not shared.  Example:

public class A {
   public int Prop { get; set; }
}

public class B : A { }

The following should succeed after the change;

context.TypeHandlerFactory[typeof(A)].FindProperty("Prop") ==
context.TypeHandlerFactory[typeof(B)].FindProperty("Prop");

Care should be taken that overriden properties and shadowed properties are
not shared.

Original issue reported on code.google.com by [email protected] on 4 Jan 2009 at 6:52

DateTime Deserializing Produces a String

What steps will reproduce the problem?
1. I have a hashtable which is keyed via a string.  In the value of the
hashtable I have an array list which contains an integer and a datetime.
2. Serialize this object to JSON.  The output for the datetime is in the
ISO format of 1995-04-30T00:00:00.0000000.
3. When de-serializing this object the parser reads the datetime as a
"quotedString" and will return a string value.  

What is the expected output? What do you see instead?
The expected output should be of type DateTime however the Deserialize
method will return a string instead.


What version of the product are you using? On what operating system?
Product version: 30.25.205. Operating System: Windows XP Pro SP3.


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 5 Aug 2009 at 2:36

A nullable value that is set is serialized with a casting prefix, which seems redundant.

What steps will reproduce the problem?

1.
Serialize some nullable value that is of type "System.Guid?" or 
"Nullable<System.Guid>".

What is the expected output? What do you see instead?

Expected:
"Id":"5b23029c-3a59-454b-8bf0-7ce3dcec1f3c"

Instead:
"Id":(System.Guid)"5b23029c-3a59-454b-8bf0-7ce3dcec1f3c"

What version of the product are you using? 
2.1.1.144

On what operating system?
Vista 32bit

Please provide any additional information below.

When types are serialized using jsonexlib, I don't like to see any type 
information that is redundant in the output.

Probably a custom type converter must be introduced for Nullables?

Original issue reported on code.google.com by [email protected] on 12 Nov 2008 at 9:12

Deserialisation of Double is CultureSpecific

Version 2.1.1.170

the deserialisation of double-values is culture specific (that is the used 
Convert.ChangeType(..) is culture specific)
in german a dot is used the delimit thousand and a comma is used as 
decimal delimiter
en: 1234.13
de: 1.234,13

so deserialisation of "1234.13" leads to "123413.0".
My quick fix was to always use the "en-US" culture to convert doubles.

File:ValueEvaluator.cs
My changed "Evaluate"-Method looks like this:

public override object Evaluate() {
    if (Expression.ResultType.IsEnum)
        return Enum.Parse(Expression.ResultType, Expression.Value);
    else if (Expression.ResultType == typeof(object))
        return Expression.Value;
    else {                
        if (Expression.ResultType.Name == "Double") {
            IFormatProvider formatter = 
System.Globalization.CultureInfo.CreateSpecificCulture("en-
US").NumberFormat;
            return Convert.ChangeType(Expression.Value, 
Expression.ResultType, formatter);
        } else {
            return Convert.ChangeType(Expression.Value, 
Expression.ResultType);
        }
    }
}

Original issue reported on code.google.com by [email protected] on 20 Jan 2009 at 9:57

Advanced Customization

Allow for advanced customization scenarios such as using factories or
dependency injection to create instances of types as well as non-standard
type meta-data such as a getter/setter method pair instead of a standard
property.

1. Change Serializer/Deserializer code to depend on interfaces for
TypeHandler and PropertyHandler.
2. A TypeHandler factory will produce instances of ITypeHandler and will be
available on the SerializationContext.
3. The DefaultTypeHandlerFactory will cache TypeHandler instances by default.
4. IPropertyHandler will not expose PropertyInfo property, this will allow
for "properties" that are not bound to actual properties on an object such
as public fields, or getter/setter method pair.
5. Default TypeHandler should add support for public fields.
6. SerializationContext will expose an IDictionary property for custom
converters,typehandlers, etc to use.

Example Dependency Injection scenario:
public class DITypeHandlerFactory : TypeHandlerFactory {
   public DITypeHandlerFactory(SerializationContext ctx) : base(ctx) {
   }

   protected override ITypeHandler CreateNew(Type t) {
      return new DITypeHandler(t, _context);
   }

}

public class DITypeHandler : TypeHandler {

   public DITypeHandler(Type t, SerializationContext ctx) : base(t, ctx) {
   }

   public override object CreateInstance(object[] args) {
       MyFMyFavoriteDIImpl container = (MyFavoriteDIImpl)
ctx.Data["Container"];
       return container.Resolve(typeof(ForType));
   } 
}

// Setup Code
MyFavoriteDIImpl container = new MyFavoriteDIImpl("someconfig.xml");
Serializer s = Serializer.GetSerializer(typeof(MyClass));
s.SerializationContext.Data["Container"] = container;
s.SerializationContext.TypeHandlerFactory = new
DITypeHandlerFactory(s.SerializationContext);

Original issue reported on code.google.com by [email protected] on 21 Jan 2008 at 3:09

Cast being used when property is of type System.Type

use property that uses System.Type

public Type DataType { get; set; }

Serializer will write out

(System.RuntimeType) { }

which can not be deserialized.  Converter is required as well to convert 
type to string.

Consider added a TypeToString converter as well.

Original issue reported on code.google.com by [email protected] on 10 Mar 2009 at 4:35

Detect Circular references

Add code to detect circular references.  This code will merely detect
circular references and either discard them or throw an exception.  The
behavior will be based on an option.

This will not support circular references at this time.

Original issue reported on code.google.com by [email protected] on 25 May 2007 at 12:03

No support for tree structures.

Does not work at all with tree structures formed using the composite pattern.

Original issue reported on code.google.com by [email protected] on 4 Aug 2008 at 2:03

Public Members do not serialized

Example of my problem:
say I have the following couple of classes

public class Hdr {
    public string A {get { return "A"; }}
}

public class Msg {
    public Hdr Header = new Hdr();
    public string Body {get{ return "Message";}}
    public Msg(){}
}

Calling:

Serializer ser = new Serializer(typeof(Msg));
Console.WriteLine(ser.Serialize(new Msg()));

Yields Msg.Headr -> Null.

Original issue reported on code.google.com by [email protected] on 12 Jun 2008 at 5:43

Constructor Type detection is not very robust

Given the following json string: new StringMessage("Information",
"messageName")

and the following constructors:

public StringMessage(MessageType type, string MessageName);
public StringMessage(MessageType type, MessageName MessageName);

The 2nd constructor is attempting to be used instead of the first one and
results in cast error.

Original issue reported on code.google.com by [email protected] on 27 Feb 2008 at 6:03

Support circular references

Devise a way to write references to objects that have already been
serialized in the current serialization operation.

Each object has a distinct path from the root to itself.  Write that path
out as a reference to find the object on deserialization.

Example:

{ cust: { name: "Ted", orders: [ {id: "12345", cust: this.cust } ] } }

The 1st element of the orders collection has a reference to the customer
object.  This is a circular reference.  The path to the customer object from
the root object is the cust property.  If we call the root object "this",
then its path is this.cust.  Upon deserialization the cust object will be
created first, so when we are in the order element, it will have been
created at that point.

Original issue reported on code.google.com by [email protected] on 25 May 2007 at 12:10

serialize read-only properties as well

it would be very convenient to serialize the properties even if they are read-
only (don't provide a set).

Cheers,
Sylvain

Original issue reported on code.google.com by [email protected] on 17 Jul 2009 at 12:14

Create Samples and improve Usage wiki

Need to have more sample code and/or tutorial up on the site.  Update the
Usage page to show the code for the class being serialized and the
resulting JSON text that is output.

Original issue reported on code.google.com by [email protected] on 21 Jan 2008 at 3:16

JSONReader issue

I need to read the Json string. And trying to find the value from many Key-
 Value pairs.
I am having a situation where in a base class is there and i am deriving 
various other classes from the base. 
I want to perform certain jobs and my extended classes are the various job 
types.
So depending on the job type the serializer is creating a different set of 
property and the property of the base class.

While reading i am not aware of which derividing class should i use to 
deserialze it back. I am trying with a base class then it gives me error.
since some of the metod he can not deserialize it.

How can add  i type information so that i can trace it back the proper 
derived type.

Or tell me the way to read the Json for any attribute at root level.

Original issue reported on code.google.com by [email protected] on 17 Jul 2008 at 1:24

Usability enhancements to ExpressionHandlersCollection

Add an IndexOf method to ExpressionHandlersCollection that takes a Type 
argument and finds the index of the handler equal to that type.  This makes 
it easier to replace an existing handler.

Original issue reported on code.google.com by [email protected] on 27 Jan 2009 at 3:25

Converter Delegate TypeConverter

Create a TypeConverter that takes 2 System.Converter<TInput, TOutput>
delegates as arguments.  The GetSerializedType method will infer its return
type from the types specified by the first or Serializer converter.


Example:

public class DelegateConverter<T1,T2> {

  public DelegateConverter(Converter<T1,T2> SerializerConverter, 
       Converter<T2,T1>) {
  }

  ...
}

Original issue reported on code.google.com by [email protected] on 10 Aug 2008 at 7:44

Reference Syntax using JsonPATH

Currently the reference syntax uses something like this:
this.foo.1.value

Change it to use JsonPATH syntax, as well as still accepting the old format

$.foo[1].value

or

$['foo'][1]['value']

Original issue reported on code.google.com by [email protected] on 24 Sep 2008 at 12:50

Add CollectionHandler attribute for Collection Classes

Make it easier to register your own collection handlers with a
CollectionHandler attribute.  The attribute should be allowed on the class,
and on a property if feasible.

When the attribute appears on a class the TypeHandler should use that
CollectionHandler for the collection test.  It should first search the list
for an instance of the type by exact match, then by inheritance if no exact
match found.  Finally if no instance of the class is available in the
collectionhandlers then it should try and create it with a noarg constructor.

Original issue reported on code.google.com by [email protected] on 10 Jul 2008 at 4:08

ExpressionHandlersCollection doesn't honor IContextAware when setting default or null handler properties

The setters for NullHandler and DefaultHandler on 
ExpressionHandlersCollection should check for the IContextAware interface 
on the incoming value and set the context if appropriate.

Original issue reported on code.google.com by [email protected] on 27 Jan 2009 at 3:22

Property converters not used when deserializing constructor parameters

A property converter that is set on a property that is also Constructor 
parameter does not get used during deserialization.

In the following example the "baz" argument does not get passed to the 
Foo2BarConverter upon deserialization.

public class MyClass {

  public MyClass(Bar baz) {
  }

  [JsonConvert(typeof(Foo2BarConverter))]
  [ConstructorParameter("baz")]
  public Foo FooProp { get { /* ... */ } set { /* ... */ }
}

Original issue reported on code.google.com by [email protected] on 7 Jul 2009 at 4:17

Support Ignore attribute on properties

Create an attribute for ignoring fields on serialization.  Any property
tagged with the attribute will not be written out on serialization.

Original issue reported on code.google.com by [email protected] on 25 May 2007 at 11:56

ParseTypeSpecifier incorrectly parses generic types

The ParseTypeSpecifier method in the Parser class will incorrectly parse
generic types.  This is because it calls Type.GetType(string typeName)
before checking to see if there are generic args.  If there is both a
non-generic type and a generic-type with the same name, it will find the
non-generic type, if there is only a generic type it will return null.

It should first parse the generic args.  Then append a "`" character and
the # of generic arguments to the name of the type.

Example to find:
class SomeNamespace.SomeGenericType<T, K> {
}

Use:
SomeNamespace.SomeGenericType`2

Original issue reported on code.google.com by [email protected] on 6 Jun 2007 at 5:44

Advanced Collection Support

Add advanced collection support for objects within collections.

Original issue reported on code.google.com by [email protected] on 25 May 2007 at 11:54

Something wrong in DictionaryToListConverter

In "ConvertTo()", the sourceType parameter is provided but the instance
variable _sourceType is getting used for looking up a TypeHandler. 

_sourceType is never assigned, so I think the instance variable should be
removed and replaced by the parameter sourceType.

Please review. TY! :)

...armin

Original issue reported on code.google.com by [email protected] on 29 Jul 2008 at 9:26

Reference should not have a Cast

What steps will reproduce the problem?
1. Assign a referenced object to a property that does not match the 
property type

What is the expected output? What do you see instead?
The reference should be rendered without type information.

The reference contains type information.

Original issue reported on code.google.com by [email protected] on 16 Nov 2008 at 5:46

Boolean serializer incompatible with JavaScript eval

What steps will reproduce the problem?
1. Create a class with a boolean property
2. Serialize an instance of the class to a JSON string
3. Call eval(JSON-string) in a browser

What is the expected output? What do you see instead?
It is expected that the eval method will convert the JSON string into
an object of type class. What happens instead is that the eval method 
throws an exception saying that the boolean value (True or False) is not 
valid. The reason the boolean value is not valid is that JavaScript 
expects a boolean value of all lower case "true" or "false" while the .Net 
framework (unlike every other framework in existence) returns a mixed 
case "True" or "False" value.

What version of the product are you using? On what operating system?
2.1.0.127

Please provide any additional information below.
The fix is to do the following:

In JsonWriter.cs, line 145 replace the method for writing a bool with this:

        public IJsonWriter Value(bool value)
        {
            PreWrite(OpType.OpValue);
            if (value)
            {
                _writer.Write(bool.TrueString.ToLower());
            }
            else
            {
                _writer.Write(bool.FalseString.ToLower());
            }
            return this;
        }

this will have the affect of taking the true and false values and writing 
them correctly to the JSON stream.

Original issue reported on code.google.com by [email protected] on 18 Jul 2008 at 1:46

A property with a private/protected get or set are not defaulted to ignore

A property that is not writable and readable is defaulted to Ignored.  
private or protected setters are incorrectly considered writable.

Reproduce
public class A
  private int _b;
  public int B {
      get { return _b; }
      private set { this._b = value; }
  }
}

The metadata for property "B" should default to "Ignored".

Original issue reported on code.google.com by [email protected] on 6 Jan 2009 at 8:07

Allow custom handling of property in json that doesn't exist in object

Given the following Json:

{
   ID: 1,
   OldProp: "value"
}

and the following class:
public class Foo {
   public int ID { get; set; }
   public string NewProp { get; set; }
}

Give the user a way of handling the fact that "OldProp" does not exist on 
the object.  The default will be to throw an exception.  The user can 
register a custom delegate to handle missing properties.  Typical actions 
could be to ignore the missing property or assign it to a different 
property in the case of a rename refactoring.

Original issue reported on code.google.com by [email protected] on 3 Jul 2009 at 12:47

Support for constructor-less classes

When there is no constructor for a class being serialized, deserialization
fails. 

I would like to suggest calling FormatterServices.GetUninitializedObject()
instead of Activator.CreateInstance() when TypeHandler.CreateInstance() is
called with an empty arguments list _and_ there is no (default) constructor
for that type available.

regards
...armin.

Original issue reported on code.google.com by [email protected] on 29 Jul 2008 at 1:19

Allow a way to omit properties that are null or have default value

As a way of compressing the output, allow a way to omit any properties that
are empty, null, or have the default value.

Since the concept of what is the "default value" is instance specific, the
user probably needs to be able to specify what the default is.

Something similar to:

[JsonExProperty(OmitDefaults=true, DefaultValue="")]
public string StringProperty {
  get { return _s; }
  set { _s = value; }
}

[JsonExProperty(OmitDefaults=true, DefaultValue=3.14)]
public double Pi {
  get { return _p; }
  set { _p = value; }
}

Should probably be a way to turn this on at the class level and globally.

Original issue reported on code.google.com by [email protected] on 23 Jul 2008 at 1:02

Support for Enums

Add support for serializing Enums.
An option should be given to output the Enum as text (its name), or as its
value.
For string JSON mode the value will be the default output type.

Example
class SomeClass {
  public PropertyType ObjectType{ get { ... } set { ... } }
}

Serialized Text in name mode:
{
   "ObjectType": PropertyType.Object
}

   or

Serialized Text in value mode:
{
   "ObjectType": 2
}

Original issue reported on code.google.com by [email protected] on 1 Jun 2007 at 12:12

Advanced Customization/TypeConversion

Allow advanced customization or TypeConversion during serialization.

Create a set of handler classes that convert to/from the target objects 
into an intermediate json representation of the data.  Custom handlers can 
then be built that override default handlers by altering the json 
representation before its passed on to be serialized/deserialized.

The following json representation classes are used:
ValueExpression
BooleanExpression
NumericExpression
ArrayExpression
ObjectExpression
CastExpression
NullExpression
ReferenceExpression

Original issue reported on code.google.com by [email protected] on 10 Oct 2008 at 2:54

the comment before the json text gets JQuery unable to work

What steps will reproduce the problem?
1. make a page that return a json data
2. use jquery to call that page (dataType="json")
3. success is never called, furthermore seems to interpret it few times as 
denied

What is the expected output? What do you see instead?
to get the json object, here success is never called

What version of the product are you using? On what operating system?
JsonExSerializer-3.01.148.219
on windows 2003 server

How to rid off of those comments at the beginning of the serialisation?

Original issue reported on code.google.com by [email protected] on 23 Jul 2009 at 8:03

Add basic collection support

Add support for basic collection of primitive objects.

Original issue reported on code.google.com by [email protected] on 25 May 2007 at 11:53

Create custom exceptions and replace ApplicationException

Need to create custom exception classes throughout the project where
ApplicationException or SystemException is used.

Original issue reported on code.google.com by [email protected] on 27 Jun 2007 at 5:07

Build the context from a config file

Build the serialization context through an app.config file.  The config
file would support multiple sections for different scenarios.  The name of
the section to use to build the context can be specified when constructing
the serializer.  If no config is specified, then use a default config.
Would like to allow for inheriting from other sections so that you can
define one default and then create other ones that only modify a few elements.

Need a way to specify the base context so that the serializer has
everything it needs to function in the event there is no config file or
default section.

See attached file for an example.

Modify the Serializer factory method as follows:
Add another method:
public static Serializer GetSerializer(Type t, string configSection);

The existing method with only the type parameter will call the new one with
"JsonExSerializer".

Also maybe allow it to be controlled by type.  Example:
<SerializerSection type="MyClass, MyAssembly">
  ...
</SerializerSection>

Then a call to Serializer.GetSerializer(typeof(MyClass)) would find the
SerializerSection and use that.

Original issue reported on code.google.com by [email protected] on 1 Aug 2007 at 8:21

Attachments:

• example.config

Deserialize into existing object

Implement the ability to deserialize into an existing object.

Foo f = new Foo();
Serializer s = new Serializer(typeof(Foo));

s.Deserialize("{ Bar: 1 }", f);

// Prints "1"
Console.WriteLine(f.Bar);

Original issue reported on code.google.com by [email protected] on 4 Oct 2009 at 2:38

'JsonExSerializer.TypeConversion.TypeToStringConverter.SupportsReferences(System.Type)': no suitable method found to override

 'JsonExSerializer.TypeConversion.TypeToStringConverter.SupportsReferences(
System.Type)': no suitable method found to override


public override bool SupportsReferences(Type sourceType)

should be 

public bool SupportsReferences(Type sourceType)

Original issue reported on code.google.com by [email protected] on 15 Jul 2009 at 12:57

Json Serializer string not validating with boolean field.

The JsonExSerializer is converting boolean DataType to value type 
as 'True' with capital T. While Validating the Json it gives the error.
Can u please suggest a way to make the 'True' to 'true' in the serializer 
only.

Original issue reported on code.google.com by [email protected] on 17 Jul 2008 at 2:18

Option to Escape whitespace characters

Currently per the JSON standard, carriage returns, line feeds, and tabs are 
escaped inside strings in serialization output.

Have an option to turn this off for more readable output.

EscapeWhitespace

Original issue reported on code.google.com by [email protected] on 5 Nov 2008 at 4:50

Instances of System.Type are written as references when used multiple types

Deserialize an array of Types.

Type[] types = { typeof(string), typeof(string) };

Serializer serializer = new Serializer(types.GetType());
serializer.Serialize(types);

produces:

[ "string", $[0], $[0] ]

NOTE: converter is being used as System.Type is not serializable by itself.

Priority is low as this can successfully be deserialized, it's just 
annoying.

Original issue reported on code.google.com by [email protected] on 10 Mar 2009 at 4:54

May make SerializationContext.GetTypeBinding() and GetTypeAlias() virtual

There may be exceptional scenarios in which deserialized types are lazily
resolved or created on the fly (by using dynamic assemblies, for example).
Here, the type mapping offered by SerializationContext may not be sufficient. 

Making GetTypeBinding() virtual could provide a bit more flexibility.

Probably GetTypeAlias() should be virtual, too. 

Alternatively, SerializationContext could be transformed into an interface
to separate the interface required by the serializer and the actual
implementation.

...armin.

Original issue reported on code.google.com by [email protected] on 11 Aug 2008 at 1:34

Serializing a .NET object sets boolean values to begin with a capital letter.

What steps will reproduce the problem?
1. Create an object (instance of a class in .net) with a boolean property 
2. Serializing returns a string with boolean property w/ Capital letter
e.g. 'True' instead of true or 'False' instead of false
3.

What is the expected output? What do you see instead?
I expect to see lower case boolean values so I can use in javascript

What version of the product are you using? On what operating system?
JsonExSerializer-2.1.0.127

Please provide any additional information below.

At work so can't do much else.

Original issue reported on code.google.com by [email protected] on 14 Jul 2008 at 6:01

Serialization/deserialization of types depends on current culture!

What steps will reproduce the problem?
1.
Serialize a DateTime using jsonexserializer.
2.
Change "current format" using ControlPanel => "Regional and Language 
Options"
3.
Deserialization of DateTime most probably fails.

What is the expected output? What do you see instead?

I expect deserialization to work independently of the current format 
settings.

What version of the product are you using? On what operating system?
2.1.1.144, Vista

Please provide any additional information below.

String type conversion must be done using the invariant culture, otherwise 
the serialization format itsself is not "invariant", which potentially 
breaks _every_ use of jsonexserializer for such types.

Probably only the TypeConverterAdapter needs to be adjusted to use 
invariant ConvertTo / From String methods.

This problem also exists in the alpha version 3.

Original issue reported on code.google.com by [email protected] on 12 Nov 2008 at 9:21

Include property while Serialize the object

In any class i can exclude the property to deserialize it.

 But i want one of my property in the base calss called "stackTrace" to be 
only added if any error occures. 

so I want a way by which i can by default exclude the property and at 
runtime i can add the property while deserializing it.

Original issue reported on code.google.com by [email protected] on 17 Jul 2008 at 2:49

Attachments:

Add AttributeService for processing Property and Class custom attributes

This is an idea to abstract out the handling of custom attributes from 
inside the code to make them more extensible.  This will accomplish a 
couple of things.
1) Provide custom properties to TypeConverters by overriding or providing a 
different attribute
2) Reuse existing attributes from .NET framework or other libraries that 
have similar meanings to JsonEx attributes, such as XmlIgnore to specify 
ignored fields.
3) Add custom behavior in places where attributes are supported.  These 
include Type metadata, property metadata, collection handlers, and type 
converters.

The current custom attributes are:

JsonExProperty
JsonExIgnore
JsonExCollection
ConstructorParameter
JsonConvert

The existing code checks for the existence of one of the pre-defined 
attributes and then uses its properties to initialize or modify the current 
object.

New code might look something like this:
PropertyInfo p;
Context.AttributeService.ProcessAttributes(p, this);

Handlers would be registered as:
Context.AttributeService.RegisterHandler(typeof(JsonExIgnoreAttribute), new 
JsonIgnoreHandler());

Handler class:
public class JsonIgnoreHandler {
   public void ProcessAttribute(Attribute a, object target) {
       if (target is IPropertyData)
           ((IPropertyData) target).Ignored = true;
   }
}

Specify XmlIgnore as the ignore attribute:
Context.AttributeService.RegisterHandler(typeof(XmlIgnore), new 
JsonIgnoreHandler());

Original issue reported on code.google.com by [email protected] on 11 Mar 2009 at 2:55

Provide Aliases and Naming Strategy

Allow the use of a naming strategy which will control how reflection 
property names get turned into JSON properties.

For instance using a camelCase naming strategy would cause this class:

public class MyClass {
  public int MyProperty { get; set; }
}

to get turned into this JSON

{ "myProperty": 0 }

Also allow aliasing a property using the JsonExProperty attribute.

public class MyClass {
  [JsonExProperty(Alias="my_property")]
  public int MyProperty { get; set; }
}

{ "my_property": 0 }

Original issue reported on code.google.com by [email protected] on 26 Sep 2009 at 2:19