I am looking at my existing design and try to make this happen for some classes.
I did however discover a situation where there is a property (the type is a dictionary of objects ) in one of my classes that really only have meaning in the local context, so I do not want to pass it to the AppServer. But it seems the whole class goes or nothing goes. I would like to mark the property as irrelevant (even better if I can decide in runtime) en up with a Null value instead on the server side. Alternatively, if some "deserialisation constructor or event" exists, I can initialize it with a blank dictionary again.
If the object is INPUT-OUTPUT this would of course be a problem, since I will loose the reference to the local object when the call come back, unless there is a way to preserve it, but then the "deserialisation event" may get in the way...
Do I make sense here?
In java and .net you would mark the property with a "transient" keyword. which would indicate it shouldn't be sent over the wire, to disk or elsewhere. The ABL doesn't have this feature yet.
it better gets added before released into the wild, this is pretty important and it sure takes way less to implement this 'exclude' thing than what it took to have serialization added...
good job guys, do remember we said even in Brussels we don't really care how the serialization is done but can we have some details on what is going on under the hood? :)
maybe we can do something for this on java open client using an approach similar to jaxb for instance... is that json, xml, binary???
Yes, it's an all or nothing serialization for the 11.4 release. We have in our roadmap for some future release more enhancements to make object serialization more flexible, one of which is to allow you to mark class members so they are not serialized.
The serialization is in binary form. For this release, object serialization is only available for ABL clients.
My first reaction is to think that there is something wrong with the object decomposition if part should go and part should not ... but then I don't think much of passing anything but error objects across anyway. What I *would* like is to extend Progress.Lang.Object so that all objects were serializable for storage and the like.
why wouldn't you serialize the object as json ? wouldn't that make more sense ?
if you did that, you could then store objects into a database as a
clob and a whole heap more
On 28 March 2014 14:15, Fernando Souza
wrote:
> RE: Passing Objects to and from the AppServer
> Reply by Fernando Souza
>
> Yes, it's an all or nothing serialization for the 11.4 release. We have in
> our roadmap for some future release more enhancements to make object
> serialization more flexible, one of which is to allow you to mark class
> members so they are not serialized.
>
> The serialization is in binary form. For this release, object serialization
> is only available for ABL clients.
>
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.
--
Julian Lyndon-Smith
IT Director,
dot.r
http://www.dotr.com
"The bitterness of poor quality remains long after the sweetness of
low price is forgotten"
Follow dot.r on http://twitter.com/DotRlimited
Flag this post as spam/abuse.
That was my first thought as well, but I did not argue this particular case with myself. In this case I was simply looking for something to experiment with. I am playing with the concept of passing complex objects, rather than a simple error or context objects. I did not really reach the point of arguing if it is a good or bad idea to pass this particular object.
It is simply a nice complex object with enough serialization potential to test the concept. The object in question wraps a dataset. It has a factory method that creates objects wrapping buffers on the dataset. It keeps references to those in an internal temp-table to ensure they are all deleted if the object itself is deleted.
But when the compiler complained that the list of buffer objects is not serializable, it occurred to me that the buffers use in the client context are irrelevant in the AppServer context in any case, so I do not really want to pass that. It is the type of use case one will not encounter when passing simple errors or state/context tokens.
Currently the dataset itself is passed to the AppServer, where the interface .p promptly create a copy of the object and invoke a method. This would probably be the smallest payload anyway, but to be able to do this, I had to create an additional constructor to accept the dataset passed so that I can override the internal dataset and I need to pass the type name in a string to the .p in order to know what to reconstruct. One benefit of passing the object itself would be simpler code with less chance for errors, but the trade-off is most likely a larger payload for ever - which could be bad.