Specify the input other than FormType

[ruudk]

I'm using FOSRestBundle with JMSSerializerBundle for my API. The input isn't specified with a Form but with a Class that is annotated with JMSSerializer annotations.

Would it be possible to support this too?

[Seldaek]

It definitely would/should be possible yes :) If you feel like contributing it, even better.

[ruudk]

What would be the best way to set this up? Maybe I can find some time to develop it.

[Seldaek]

There are a few things to change:

• IMO the formType attribute of the annotation should be changed to input or inputClass or something: https://github.com/nelmio/NelmioApiDocBundle/blob/master/Annotation/ApiDoc.php#L41
• Then you need a parser class that can read metadata from the JMSSerializerBundle like this one https://github.com/nelmio/NelmioApiDocBundle/blob/master/Parser/FormTypeParser.php

[willdurand]

• the formType has to be changed to inputClass;
• each parser should have a supports() method to determine if they can parse the input class, or not;
• an interface for parsers has to be created (ParserInterface seems fine) with two methods parse(), and supports();
• the getData() method in the AbstractFormatter has to be tweaked;
• each parser should be registered somewhere, and passed to the AbstractFormatter.

<?php

class AbstractFormatter implements FormatterInterface
{
    protected $registeredParsers = array();

    // …

    protected function getData(ApiDoc $apiDoc, Route $route)
    {
        // …

        if (null !== $inputClass = $apiDoc->getInputClass()) {
            foreach ($this->registeredParsers as $parser) {
                if ($parser->supports($inputClass)) {
                    $data['parameters'] = $parser->parse(new $inputClass());

                    break;
                }
            }

            // ...
        }
    }
}

[grEvenX]

@willdurand was that a suggestion for the interface? I can't find the code implemented in the git repo?

[willdurand]

No it's a suggestion to handle the different parsers.

[willdurand]

@ruudk any news on this?

[ruudk]

@willdurand Sorry, but I don't have time for it right now. Quite busy with the development of the API.

[evillemez]

Enabling the suggestions mentioned here seems like a necessary step before tackling issue #47, which would enable the suggestions in issue #48.

If no one is working on this, I have some thoughts on implementing it, and as I have a project in the early stages that needs it, I can justify time to work on it.

[evillemez]

To implement this, I was thinking of doing the following (I just noticed some refactoring going on, so I might have some things in the wrong spot conceptually):

• Change ApiDocExtractor to accept a ParserInterface in the constructor, instead of the FormTypeParser, but otherwise leave it alone
• Implement a ParserInterface, and a DelegatingParser that can have multiple parsers registered internally, which it will call until one of them returns data
• Add a JmsMetadataParser
• Register the necessary services to have the DelegatingParser be the default parser, with FormTypeParser and JmsMetadataParser automatically registered via container tags

This way it would leave the door open for implementing new parsers down the road fairly easily. Thoughts?

EDIT: And this raises a question... if someone doesn't have JMS installed, then what? Just document that it's something you can enable manually via configuration if you do have it installed?

[willdurand]

Why not just registering parsers in the Extractor? Then, we just iterate over the list of parsers, and that's it.

[evillemez]

Yeah, that's simpler... remove passing parsers via the constructor and just have a registerParser setter method?

[willdurand]

yes

[evillemez]

This can be closed now.

[evillemez]

ping @willdurand This one can be closed too