Any reason Provider doesn't use JSON for encoding/decoding?

[fetchinson]

Well, the subject pretty much says it all. The encodeValue/decodeValue functions in source/state/Provider.js are serializing objects in an ad hoc way. Why not use simply JSON?

The reason I came across this is that I'd like to read/write cookies on the server that will be understood from ext i.e. I need to conform to the encodeValue/decodeValue syntax in Provider.js so I need to implement these in python (my choice of server side solution) but if it would be in JSON I wouldn't need to write anything new. I bet there is a reason for the current situation but what is it?

[watrboy00]

The provider uses cookies so you can persist state over page refreshes without syncing state to the server. It could implement json stored in memory instead of cookies but if you did not save it on the server side it would be lost on page refresh.

EDIT: I am kind of off subject here. After re-reading your post it made more sense. If you look at the way it encodes the values, it sort of does a name value collection where the name is the data type of the value. You could possibly use JSON but I don't think there would be a need for it and I think it would technically take more memory. I believe however if you wanted to convert the contained state you could just use:


Ext.encode( Ext.state.Manager.getProvider().state )

and post that to the server side script.

[fetchinson]

Come on, the amount of memory this stuff takes is minimal. After all, the size of a cookie is limited so it can not possibly grow too big.

I'm guessing this weird serialization is a remnant from the past and the devs didn't want to change it for the sake of backward compatibility. But maybe there is another reason, any devs around here?

Implementing this weird serialization is not a big deal in python, I've already done it, so there is no real problem to be solved, I'm just wondering why things ended up as they are.

By the way, Provider has nothing to do with state stuff per se. For example CookieProvider can be used as a generic wrapper around cookie manipulation, a state manager doesn't have to be around at all.

[watrboy00]

Come on, the amount of memory this stuff takes is minimal. After all, the size of a cookie is limited so it can not possibly grow too big.

I'm guessing this weird serialization is a remnant from the past and the devs didn't want to change it for the sake of backward compatibility. But maybe there is another reason, any devs around here?

I'm not saying this is the reason why they chose to do it this way. Like you said it may be a legacy issue and kept around for backwards compatibility, just pointing out there would be a memory difference, although small.


Implementing this weird serialization is not a big deal in python, I've already done it, so there is no real problem to be solved, I'm just wondering why things ended up as they are.

By the way, Provider has nothing to do with state stuff per se. For example CookieProvider can be used as a generic wrapper around cookie manipulation, a state manager doesn't have to be around at all.

I guess this all depends on your implementation. If you are using the Provider without the State Manager then you really wouldn't need the encodeValue & decodeValue methods of Provider and probably wouldn't benefit from the Provider anyway. A simple object reference encoded to JSON would be easier to use than the Provider. All goes down to requirements and implementation.

[jay@moduscreate.com]

Always wrap your json encode with a try catch.