zf-fr/ZfrRest — pull request #35 by bakura10 (2013-02-22 11:11:25+00:00)
Title: Cleanup factories

This cleanup a bit the factories (I've renamed the folder "Factory" instead of Service, I find it less confusing), and now I use the Factory Interface instead of the AbstractPluginManagerFactory (it was not rightly used, as it couldn't extract config, it has to be used in pair with ModuleManagerListener).

By the way, I'm still not sure if we really need the decoder and encoders plugin managers. Currently, the only place it is used is by BodyParser. However, the decoders/encoders will be specified per entity, either using config:

```php
return array(
'resource_metadata' => array(
'my-resource' => array(
'decoders' => array(
'mimeType' => 'My\Decoder'
)
)
)
);
```

or through annotations:

```php
/**
* @Rest\Decoders(
* @Rest\Decoder(mimeType="blabla", name="My\Decoder")
* )
*/
class Entity
```

This means the user will never fill the "encoders" / "decoders" key globally (as it would mean duplicate those information). So basically we have three choices:

1. Remove completely the Decoder/Encoder plugin manager, as we can retrieve them from the resource metadata. BUT this means that if we need to have access to the "vnd.my-entity-json" decoder outside of resource context (in the BodyParser for instance), we cannot do it (but do we need the BodyParser ?).

2. When parsing the metadata (from Php driver or annotation driver), automatically add to the encoder/decoder plugin manager the mimeType => decoder.

3. The resource metadata only contains the mime-type:

```php
/**
* @Rest\Decoders(
* @Rest\Decoder(mimeType="blabla")
* )
*/
class Entity
```

and the user is asked to fill the "encoders"/"decoders" array by matching the mimeType. This has the benefit that now the user has a finer control about how they are constructed (either through a factory, or an invokable...), but this means the config is more cluttered and (as you need to specify both annotation AND php file...).