Decouple actions and responders

[ahundiak]

In my own implementation I found it convenient to decouple actions and responders. The wiring is done at the route level:

game_listing:
    path: /listing
    defaults:
        _controller: game_listing_action # service id
        _responder: game_listing_responder_html

The action adds any specific data that the responder needs to the request object then returns null. The responder then acts on the request and generates a response.

I did it this way mostly because the Symfony framework makes it easy to implement a responder listener. I can actually configure multiple responders based on the desired response format (html, json etc).

It also seems a bit more middleware-ish. The action does it's thing then moves onto the responder.

Just wondering if the notion of not having the action operate directly on the responder fits into your vision of ADR?

[pmjones]

Just wondering if the notion of not having the action operate directly on the responder fits into your vision of ADR?

To a first approximation: yes. The key point in ADR is the separation of those particular concerns. If the action returns (e.g.) a payload of some sort, and that payload is passed directly to a responder without intervening logic to determine which responder to use, then it seems at least in the spirit of ADR.

Where you'd need to be careful, I think, is in adding intercessory logic between the action and the responder. Anything that attempts to determine "which responder should be used based on the domain results" should be considered part of the responder concern, and thus not mixed in with anything else.

Do you get where I'm coming from here?

(p.s. Wiring actions to responders at the routing level is what I end up doing as well, though generally they get injected into a coordinating Arbiter.)

[ahundiak]

In my case I think having additional logic between the action and the responder is an implementation detail resulting from the use of the Symfony HttpKernel request handler. The handler has built in support for mapping the request to an action. You can plug in your own action resolver (arbiter?) but frankly it's a bit of a pain.

Fortunately, if the action return null then the handler sends out an event asking for someone to generate a response. This makes it easy to plugin a ResponderListener to decide which responder to use. The logic used to determine the responder is based on the original route and not anything that the action has done (aka domain results?). So I think it meets the spirit.

Here is a route with multiple possible responders:

schedule_team:
    path: /team.{_format}
    defaults:
        _format: html # default format
        _controller: schedule_team_action
        _responders:
            html:  schedule_team_responder_html
            xls:   schedule_team_responder_xls
            pdf:   schedule_team_responder_pdf

I actually think it is kind of nice that the action does not need to know about the responder and can just do it's domain thing and return null. Which basically triggers the next bit of middleware.

[pmjones]

I think having additional logic between the action and the responder is an implementation detail

Yup, that's definitely possible.

So I think it meets the spirit.

Yes, based on that description, I think the separation of concerns appears preserved.

As a side note, I'd be interested to see the schedule_team_action code. I need to find something to criticize. ;-)

[ahundiak]

Here it is warts and all: https://github.com/cerad/ng2016/blob/master/src/AppBundle/Action/Schedule2016/Team/ScheduleTeamController.php

Plenty of warts. Lots to criticize.

Most of the action code deals with the search form. The form itself is another object. I have often felt that forms don't get the respect they deserve. The session is used to make the search form sticky which means you can navigate away from the page and then come back with the search form still filled in.

This is also an example of an action returning a redirect response when the search form is posted.

But eventually the action determines which games need to be shown and stores them in the request. The responder (aka view in Symfony terms) then generates the response.