Justin
I am well aware that the original object remains unchanged.
Sorry, I was using 'morphs' a bit loosely.
But the point remains.
When you have the observable live that is what you are working with and the user interaction changes the structure and data in the observable in accordance with the app's code.
At the time the observable is created the POTS object and the observable can be considered in some sense equivalent, they at least describe the same data.
The observable becomes out of synch with it's originating object and the more pushing/pulling attr/removeAttr-ing that goes on the more the observable is different from it's originating object which is now lying abandoned in JS land having done its job of instantiating the observable.
The requirement is to turn the final observable back into a POJS object, which will now be somewaht different from that which we started with. It's THAT that the app needs to store, it's THAT that the next app in the chain needs to work on, NOT the observable with it's shed load of extras that the next app knows nothing whatever about. The next app may well (probably won't) even be a CanJS app.
I use json as a data definition and interchange format and have a 'builder' app with live binding that takes in a definition that the user can then edit, add to etc, the result of this editing might well be something COMPLETELY different than the original starting definitiion. Bothe keys and data can be changed, added to and extended.
I now want to create a new definition that can be stored and in turn read in and further editied at some later date. It's no good serializing the observable and trying to use that as it no longer conforms to the required definition standard, it's been 'morphed' ...
At the moment I have to inspect the observable looking for _.data: etc recursively, overwriting the parent container with its _.data, stripping out stuff etc etc etc
All of which works, BUT
This is all HUGELY dependant on what you guys have done to create the observable so it could very easily break, and in fact will for certain as your API does not claim to standardise the contents of the observable prototype in any way whatever and this probably changes version by version. At least it COULD do.
None of this is a criticism. I'm merely enquiring whether I have missed some technique to accomplish what I want without a lot of good old fashioned hackery and hoping that 2.1 (3.0 etc) hasn't changed some internal that breaks my hacks.
Ron
I am well aware that the original object remains unchanged.
Sorry, I was using 'morphs' a bit loosely.
But the point remains.
When you have the observable live that is what you are working with and the user interaction changes the structure and data in the observable in accordance with the app's code.
At the time the observable is created the POTS object and the observable can be considered in some sense equivalent, they at least describe the same data.
The observable becomes out of synch with it's originating object and the more pushing/pulling attr/removeAttr-ing that goes on the more the observable is different from it's originating object which is now lying abandoned in JS land having done its job of instantiating the observable.
The requirement is to turn the final observable back into a POJS object, which will now be somewaht different from that which we started with. It's THAT that the app needs to store, it's THAT that the next app in the chain needs to work on, NOT the observable with it's shed load of extras that the next app knows nothing whatever about. The next app may well (probably won't) even be a CanJS app.
I use json as a data definition and interchange format and have a 'builder' app with live binding that takes in a definition that the user can then edit, add to etc, the result of this editing might well be something COMPLETELY different than the original starting definitiion. Bothe keys and data can be changed, added to and extended.
I now want to create a new definition that can be stored and in turn read in and further editied at some later date. It's no good serializing the observable and trying to use that as it no longer conforms to the required definition standard, it's been 'morphed' ...
At the moment I have to inspect the observable looking for _.data: etc recursively, overwriting the parent container with its _.data, stripping out stuff etc etc etc
All of which works, BUT
This is all HUGELY dependant on what you guys have done to create the observable so it could very easily break, and in fact will for certain as your API does not claim to standardise the contents of the observable prototype in any way whatever and this probably changes version by version. At least it COULD do.
None of this is a criticism. I'm merely enquiring whether I have missed some technique to accomplish what I want without a lot of good old fashioned hackery and hoping that 2.1 (3.0 etc) hasn't changed some internal that breaks my hacks.
Ron