DOCS: Dont mention the inspection of the Accept HTTP Header

[MatthiasKuehneEllerhold]

The View Strategies are mentioning (in the code and in the docs) that they are inspecting the "Accept" HTTP header and determine if they are going to inject their renderer and response.

But in fact, they dont do that. They just test if the View Model is an instanceof their ViewModel (JsonModel and FeedModel). I trusted the documentation on that and spent a lot of time wondering why it doesnt work... :(

I've removed every (wrong) mentioning of the inspection of the "Accept" header from the php-docs and the md docs. I've left in the (correct) sections in the quick-start on how to inspect the "Accept" header and set the correct strategy accordingly.

There should be no changes in behavior at all because only documentation was changed.

[adamlundrigan]

That functionality was removed from both JsonStrategy and FeedStrategy ages ago (v2.0.4, IIRC) (PR) but the documentation was not updated to match. I believe it was replaced by the AcceptableViewModelSelector controller plugin, which requires you to define the allowable types and will juggle the ViewModel instance appropriately based on the Accept header.

[MatthiasKuehneEllerhold]

@adamlundrigan Ok, one more reason to update the documentation then :)

Maybe the docs Zend-View Quickstart should also include the link to AcceptableViewModelSelector ?

[adamlundrigan]

Yeah, that's a good idea...maybe a new blurb at the end of "Controllers and View Models" with an example of how to use the plugin. The example at the bottom of the page (AcceptStrategy class) should also be axed as it suffers from the same security problems the Accept handling in JsonRenderer/FeedRenderer had initially.

Could you add those two changes your PR as well?

[MatthiasKuehneEllerhold]

Ive looked over the whole quick start again and found another flaw:

1. "Creating and Registering Alternate Rendering and Response Strategies"
   This whole section is invalid or misleading at best. Just by injecting the JsonStrategy during the render event (rather than in the config?) there is no "ensurance that a JSON payload is created when requested".
   This whole section needs to be revised to say:
2. register the strategy (preferable via the config so its cacheable)
3. create a JsonModel (or FeedModel) in your controller and return it
4. => a JSON (or Feed) payload will be returned.

I'll try my hand on that, but english isnt my mother tongue so you'll have to except some awkward language ;)

Offtopic: Why do we have to enable JSON in two steps: register the strategy and explicitly return a JSON-Model. Whats the downside of always registering the two other strategies? Security, Performance, RAM? It would be a huge ease-of-use improvement if we could just return a JsonModel (or FeedModel) from a controller and it would switch the output completly.

[MatthiasKuehneEllerhold]

Using the acceptableViewModelSelector didnt work (correctly) either: zendframework/zend-mvc#194 :(

[MatthiasKuehneEllerhold]

I've clarified the acceptableViewModelSelector documentation in zendframework/zend-mvc#195
Any news on this PR?

[weierophinney]

Offtopic: Why do we have to enable JSON in two steps: register the strategy and explicitly return a JSON-Model. Whats the downside of always registering the two other strategies? Security, Performance, RAM?

Performance, flexibility, and consistency.

Performance, in that it reduces the number of view listeners required. Flexibility and consistency, in that the user is then required to register the strategy or a substitute at the priority required for their application; if we auto-register, there's a very real possibility that the "auto-magically" registered service might register at a priority that supercedes the user-registered service, which makes for hard-to-find error conditions. (As a real-world example, we have a separate JSON renderer in Apigility that renders HAL payloads; having ZF autoregister its own JSON strategy could lead to invalid response payloads.)

[weierophinney]

Import the abstract controller, and reference the imported class name.

[MatthiasKuehneEllerhold]

@weierophinney Any news on this?

[weierophinney]

Thanks, @MatthiasKuehneEllerhold