Serializing all types to strings?

[maria-p]

Hello,

I'm trying to use your bundle for our application REST API, and I'm serializing my objects to json format.

I need to keep parameter types when serializing, so that null values will be nulls after serialization, and integers remain integers. But I found that for some reason you convert all the json values to strings when calling getClientData() method in serializeForm(). If I change this to getNormData() - everything works just fine.

The question is - was that done intentionally? If yes, then why?

[beberlei]

It was not done intentionally, but using getNormData() breaks the serialization for everything that is not a scalar type. This will be a tricky to come up with good solution.

[beberlei]

@bschussek same here, i need an idea. How do i solve this problem? Its only relevant in JSON, since xml needs everything as string as well anyways.

[webmozart]

I'll check whether string casting can be deferred to buildView(). Then you'd have whatever-your-data-type-is in getViewData() and the string version of that in $view->vars['value'].

[beberlei]

@bschussek does whatever your data type include DateTime instances? or is that the array already?

[webmozart]

That's an array already, otherwise it couldn't be mapped to its fields.

[beberlei]

That would be really awesome, exactly what would be necessary here :-)

[beberlei]

@bschussek i dont think it makes sense to think about this. Just checked performance, its MUCH to slow.

See 714b61e#diff-4

Serializing this object graph, takes the following times on my machine:

• FormSerializer: 0.78
• JMS: 0.04

So it would actually make much more sense to use JMS Serializer for serializing, and FormSerializer for deserializing using a form when necessary.

[webmozart]

@beberlei I'd be interested though if you could analyze why exactly it is so much slower. I'm not surprised by the numbers, because the Form component needs to do a lot of stuff that probably isn't needed for a pure serializer. But if the results help us to improve the Form code, that'd be excellent.

[mvrhov]

@maria-plyasunova: I'm not going to say that this is not the problem.
However I'm going to guess you are running on 64bit php just because of integers? Or are you integers never going over 2^31 -1

[beberlei]

@mvrhov no its really converting everything into strings :-) Thats what getViewData() does.

[beberlei]

@bschussek i split up the performance test into 3 parts, and you can probably guess whats the slowest part:

• create: 0.7819
• serialize: 0.0126
• encoding: 0.0115
• total: 0.8274
• jms: 0.0429

[stof]

yeah, the main difference here is that JMSSerializerBundle can cache its metadata whereas the form needs to be built for each request I guess.
but I also see a case where a form can achieve something impossible for JMSSB (at least as far as I know the bundle): serializing an object with a self-referencing collection, without serializing the collection for the children.

[beberlei]

@stof my performance test even includes the metadata parsing for JMS.

[maria-p]

@beberlei what do you mean by 'breaks the serialization for everything that is not a scalar type'? I've serialized objects while using getNormData() and it worked fine.

[stof]

@maria-plyasunova a datetime type has a DateTime object as norm data. And an entity type will have the entity as norm data, not the choice value.