Given that
a) I have a need to generate a json string from an object (I don't want to write-json from a temp-table or dataset) ,
b) I have a generator that creates the model classes from the database
Should I
1) Use the generator to create a method in the model that returns a json string of the attributes
2) Use the generator to create a method in a Json library that takes a model object parameter and returns a json string of the attributes
IOW, where should the json formatter method live ?
For me, that - output - generation should be outside the model.
jmls wrote:
Given that
a) I have a need to generate a json string from an object (I don't want to write-json from a temp-table or dataset) ,
b) I have a generator that creates the model classes from the database
Should I
1) Use the generator to create a method in the model that returns a json string of the attributes
2) Use the generator to create a method in a Json library that takes a model object parameter and returns a json string of the attributes
IOW, where should the json formatter method live ?
To expand a little on what Mike said, if you want to change to the formatting of the attribute string from JSON to SOAP or whatever, you then only need to change the call you make, not the actual implementation in the model.
I wrote an example of serialisation which, following the Java approach, passes in a reference to a formatting class, in which the class being serialised calls a method. This approach allows you to swap out the class performing the serialisation without having to change the class being serialised.
class My.Model:
def pub prop SomeProp as char.
method Write(input objref as OutputStream):
objRef:WriteChar(SomeProp).
end method.
method Read(input objref as InputStream):
SomeProp = objRef:ReadChar().
end method.
end class.
class OutputStream:
method WriteChar(input pcValue as char):
/*example only */
put stream strOutput unformatted pcValue skip.
end method.
end class.
In the snippet above, you'd generate the Read() and Write() methods in the My.Model class
The code is in the code share area at http://communities.progress.com/pcom/docs/DOC-106227
I heartily agree that the serialization code should be external, both because it is shared across al classes and because one can then provide alternate serializations without modifying the individual classes. I can only think of two ways to do this at the moment. One is to pass in a reference as Peter suggests and then have the object serialize itself using a standard serialization object. The other is to have the object serialized itself into some simple form which is then passed to the serialization "factory". The latter is more likely to break when you encounter new requirements, e.g., having a property which is a temp-table that could cause you to have to modify the "neutral" format.
BTW, one might note that XML and JSON are attractive as standards which work across technologies, but they are both wordy compared to what one might do if one was passing the serialized object to another system where one had control of the decoding. This might be an ABL client, another service on the bus, or storage in a database for later use by an ABL client.
Which said, WRITE-XML and WRITE-JSON serialization are highly performant compared to big loops of ABL code.
Mike, Peter, and I all agreeing! ... guess that's an answer for you!
Mike, Peter, and I all agreeing! ... guess that's an answer for you!
Way to simple a miracle has occurred.