ZF-2147: YAML Deserialization

Description

Add YAML deserialization

Comments

We will defer to an extension if it is present.

This doesn't appear to have been fixed in 1.5.0. Please update if this is not correct.

This functionality will require a full proposal transitioned through the proposal process.

My apologies since I haven't made clear exactly how the team at Zend views YAML in ZF. Short answer: we'd love to see full support. Long answer: after screwing up by not making our points of concern clear about a year ago, I revisited the common PHP/YAML alternatives. Nothing has really changed in these projects to address our original concerns. Spyc hasn't released a stable version, doesn't support many 1.1 features, and looks nothing like our recommended ZF code (it is php4 compatible, for one). Syck doesn't support 1.1, hasn't reached a stable version, and is not a particularly common extension. In short, YAML support in PHP just isn't that great as far as we can tell. That doesn't mean that we can't have a YAML component that is great for PHP, but the performance of a Pure PHP implementation is a concern. If we did have a Zend_Yaml component, then we'd want to bring value that isn't out there already. Maybe full 1.0 and 1.1 support, for example. The other alternative is to support only the YAML stuff we need for config and translation files. Any opinions or corrections?

Wil: Reading is quite easy. As you know we were not refactoring all XML based adapters on Zend_Config. The reason is that the translation adapters only read the files and these files have to have the correct syntax.

The second reason is that this way we can guarantee that you can use Zend_Translate alone without any other component (except Zend_Cache of course).

All translation adapters use php extensions where possible. I have still the opinion that the translation adapter can be made without being dependent on a second component like Zend_Yaml.

Regarding Yaml itself: As there are several extensions with pro and neg out I would propose that we build a simple and native API and then make adapters for the extensions which we want to use. As base support we could add a own implementation which means, you can decide if you use a extension or pure php. The component itself could detect this.

So I see no problem at all. But I have said this already in past.

I would suggest that if YAML support were to be pursued that it primarily wrap existing extensions in the wild. A native PHP parser is possible but it's performance on anything but small or simple YAML files can be prohibitive. I've used something similar as a last resort, but I've migrated closer to extensions like ext/syck where performance needed improvement.

Thomas, I see your point about Zend_Translate, and supporting a small subset of YAML seems to make sense there if there is a common standard for translation files in this format. The problem with creating adapters to extensions is that there doesn't appear to be an extension with the combination of quality, maturity, and functionality that would allow us to do a top-notch YAML component. Paddy, agreed. Wrapping an extension and either having a hard dependency or a fallback to a pure PHP implementation seems like the right way to go. Problem is: what extension? Any suggestions here?

This issue was implemented in ZF-1.11.

Resolved in 1.11

Hi @ralph

I think that the issue ZF-2148 too can be closed.

Thanks advance.