Controllers and Filters PSR(s) ?

283 views
Skip to first unread message

Rasmus Schultz

unread,
Jan 24, 2017, 11:45:56 AM1/24/17
to PHP Framework Interoperability Group
Any interest in a simple PSR for Controllers?

What I'm suggesting here is something that is extremely abstract and generic - something that builds upon PSR-7.

The interface itself could be as simple as this:

interface ControllerInterface
{
    public function dispatch(ServerRequestInterface $request): ResponseInterface;
}

To contrast this with the middleware-interface of PSR-15, "middleware" is a component that shares control with other middleware-components, e.g. *may* do something to a request, or might just pass - as opposed to a "controller", which is a component that *must* process the request and create a response, so this would be something to which routing (of any kind) has determined that, for the given request, this *is* the component responsible for processing.

This would work for front-controllers (such as a middleware-stack based on PSR-15) as well as for any other types front-controllers, e.g. anything you might use in a catch-all "index.php" as the top layer of request routing.

It would work for any kind of action-controller as well, e.g. using abstract base-classes to implement specific dispatch-strategies, and assuming any other dependencies would be provided via dependency-injection - which would be outside the scope of this PSR, but you can imagine abstract base-classes implementing different dispatch-strategies, such as dynamically mapping GET or POST params against argument-names of a run() method, providing integration with a DI container, etc.

We currently use such a strategy and an identical ControllerInterface at work, and it's been a real success. Our default base-class, for example, detects a JSON object body being posted, decodes it and maps object-properties against arguments - and for form-posts, it checks for scalar type-hints of the run-method and performs int, float and bool conversions, array and string type-checks, etc.

We enjoy the security of being able to replace our controller-pattern completely without breaking compatibility with existing controllers, and the freedom of being able to implement highly specialized controllers (such as a controller that resizes images) without using a base-class at all.

This pattern and interface makes any controller-implementation compatible with any router capable of resolving a request to a ControllerInterface instance, or perhaps a class-name for integration with a DI container. (In our stack, that means the router is responsible solely for determining a class-name - we use a class-per-action pattern, but a router could of course also resolve to an action-method name and provide that to a controller-implementation via constructor-injection - as with most patterns this simple, your imagination seems to be the limit.)

Basically any router that can resolve a path to a string and HTTP-method can interop with this - micro-frameworks that go beyond just resolving the request to a value (e.g. creates or runs controllers) would likely be able to interop with this in other ways.

This is one part of the story.

The other part is about filters - often there is a need to secure a controller, accept or reject certain content-types, apply caching, or do some other form of filtering before/after actually running the controller.

That sounds a lot like middleware - in fact, a lot of middleware components would be immediately useful if a controller could simply apply them as filters. So there is no need to invent a new concept here, PSR-15 would do the job, we only need to define how filters get created.

The following simple interface would do that:

interface FilterInterface
{
    /**
     * @return ServerMiddlewareInterface[]
     */
    public function getFilters(): array;
}

This could be part of the same PSR or separate.

Now a controller can (optionally) implement this and use it to declare controller-specific middleware as filters - e.g. return [new CacheMiddleware(), new PostFilter()] might apply some caching-headers and a POST-method restriction.

Whatever is returned by this method gets run before the controller itself is dispatched - in other words, to the last middleware-component (PostFilter in this example) the delegate that gets passed does not delegate to a middleware-component but to the controller itself.

How precisely the filter-middleware gets dispatched is outside the scope of this PSR - it's up to the controller base-class or framework, wherever you choose to place this responsibility. An abstract controller base-class could support FilterInterface internally, or it could be done in a router, middleware or micro-framework.

We haven't attempted the filter pattern in our own stack yet, so I can't say for sure if this would work out as dreamy as I think it would - but I think we eventually will try it, as there's a very real need and many practical use-cases.

As for the controller pattern, it's sort of a no-brainer - it's totally trivial, and it just works.

Well, I figured I'd put the idea out there, as it has already had great value for us, in terms of decoupling and separating concerns like routing and middleware from controllers and dispatch-strategies.

I figure it's worth sharing the idea :-)

Thoughts?

- Rasmus

Larry Garfield

unread,
Jan 24, 2017, 1:47:42 PM1/24/17
to php...@googlegroups.com
This strikes me as drifting too far into the "defining a framework" territory.  While I can certainly see the value in the architecture this would imply, it's by no means the only architecture.  Many controller systems I've seen (including Drupal's, even before Symfony) used one or another means of automatically extracting information from the request to pass into the controller; loaded domain objects based on the URL, for instance.  That creates a shallower and IMO better signature for individual controllers, but would be incompatible with the design below.

It's not that the model described here is bad; it's quite powerful.  But it's just one viable option among many that differ in more than just incidentals, and so I don't think a PSR (which would have the effect of pushing everyone toward this one model, which is the point of a PSR) is appropriate in this case.

--Larry Garfield
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b6c0ab24-9030-4f0f-aaca-facdfecc9f47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rasmus Schultz

unread,
Jan 24, 2017, 2:14:11 PM1/24/17
to php...@googlegroups.com
> While I can certainly see the value in the architecture this would imply, it's by no means the only architecture

I disagree that this implies architecture.

"takes a request and returns a response" is in my opinion the least opinionated, most open-ended definition you can have of a controller - in my opinion, it does not imply architecture, at all. You're completely free to use traits, composition, base-classes, external services, registries, dependency-injection, middleware - anything you can dream up, the only requirement is that you ultimately take a PSR-7 request and produce a response, which, ultimately, if you're using PSR-7, you're going to, one way or the other.

Are you commenting on the controller-interface itself or are you more opposed to the idea of going as far as defining filters?

I agree that maybe the filter concept is a bit more opinionated, but this would of course be optional - that's why it's a separate interface.


> Many controller systems I've seen (including Drupal's, even before Symfony) used one or another means of automatically extracting information from the request to pass into the controller; loaded domain objects based on the URL, for instance

Interestingly, that was our first approach - it's perfectly possible with this interface signature, and moving from our initial controller base-class to a new one was painless. We can port one controller at a time from one strategy to another, because no matter the internal architecture of each controller, or how we wire them up in our stack, they only ultimately need to have one thing in common: they take a request and return a response.

> it's just one viable option among many that differ in more than just incidentals

Can you name an example?

If you're building a PSR-7 application, no matter the architecture, taking a PSR-7 request and returning a response is ultimately what any PSR-7 application does, regardless of how it does that.

If you're building an HTTP application, no matter the architecture, taking a request and returning a response is ultimately what any application does, regardless of how it does it.

Besides mandating the use of PSR-7 models, how do you feel that this interface implies more architecture than the HTTP message exchange itself?

In my opinion, "takes a request and returns a response" is the broadest definition you can give and still imply that it's even an HTTP application.

Am I missing something?


To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/b6c0ab24-9030-4f0f-aaca-facdfecc9f47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/da0de433-f1e4-d534-530c-9d4ae103e42f%40garfieldtech.com.

Larry Garfield

unread,
Jan 24, 2017, 4:18:40 PM1/24/17
to php...@googlegroups.com
The implication that the controller itself is responsible for request and response is a particularly architectural choice.  It's not a bad choice, but there are plenty of others. 

For instance, in Drupal 8, the thing we call controllers (referenced by "_controller" in the request attributes) usually takes name-mapped parameters from the other request attributes (currently the same logic as Symfony, although we had a slight variant on the same idea before Symfony as well) and returns a render array, NOT a response.  The render array is essentially a ViewModel, and there's other code elsewhere that turns it into a Response.  (That lives in the Symfony View event in Drupal 8; it was hard-coded in Drupal 7.)  It's very ADR-ish.

A controller can ask for the request if it wants, but most don't.  A controller could return a Response object if it wants, but most don't.  A controller that both takes the request object directly and returns a Response directly is in practice an extreme edge case.  There's extra translation layers both incoming and outgoing that are a key part of the developer experience.

Now, you could argue that what you're describing here isn't a controller as Drupal defines it, but rather the "bottom middleware", which you're then calling a controller.  The term "controller" has at least 14 definitions, even just within the world of routing, IME. :-)  That makes it a poor name choice, at the very least.

OK, so next step would be to define it as a "bottom middleware" explicitly.  And a given implementation could very easily then contain the pre- and post-processing I describe above, and internally call the for-reals controller (or action, or whatever you want to call it).  Certainly true.  Drupal would then have only a single "controller" (bottom middleware).  However, I then don't see what the advantage is over having a middleware implementation that ignores the $next parameter entirely and just does... the exact same thing.  There's little additional value to a separate "bottom middleware" interface that I can see.

--Larry Garfield
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

Michael Mayer

unread,
Jan 24, 2017, 4:51:43 PM1/24/17
to PHP Framework Interoperability Group
I would love to see an interface like your ControllerInterface,

but I believe most developers associate the word Controller with MVC etc. hence I believe the concerns about framework-territory are partially justified, the name would raise unrelated expectations.


In my opinion, "takes a request and returns a response" is the broadest definition you can give and still imply that it's even an HTTP application.

Well, in that case I would suggest (similar to Symfony\Component\HttpKernel\HttpKernelInterface):
  • [Server]RequestHandlerInterface
  • [Server]RequestDispatcherInterface
  • [Server]RequestProcessorInterface
All of these are not burdened terms like Controller and the names work nicely in conjunction with concrete classes, e.g.:
class FooController implements RequestHandlerInterface {…}
class DefaultHandler implements RequestHandlerInterface {…}

The real benefit I see with such an interface is the absence of a framework – we do not need a MVC framework or a middleware stack/pipe/dispatcher to process a request, only a ServerRequestInterface instance is needed. Furthermore many libraries already support the signature of the interface method, which shows me that such an interface would not be too framework-specific, e.g. Aura.Router:
$ctrl = new Controller();

// add a route
$map->get('blog.read', '/blog/{id}', [$ctrl, 'dispatch']);

// or with an __invoke interface:
$map->get('blog.read', '/blog/{id}', $ctrl);

About the FilterInterface idea: honestly I would not bundle it with ControllerInterface. I believe, history has taught us that this is a bad idea, it only causes delays.


Bests,
Michael Mayer

Rasmus Schultz

unread,
Jan 25, 2017, 11:00:37 AM1/25/17
to php...@googlegroups.com
I agree that the term controller is probably too overloaded, yeah.

With regards to Drupal, being a framework with a very specific proprietary architecture, it's controllers are a completely distinct concept from the "controller" I'm referring to.

As you suggest, the Drupal core itself would be a "front-controller" in this context (same as any other framework, micro-framework, middleware-stack, etc.) and can implement this interface - the internal controller-concept (of Drupal or any other framework) of course is completely proprietary to it and has nothing to do with this PSR.

With that said, in my opinion, there would be pretty clear advantages for e.g. routers to support this, as compared with each of them inventing their own controller-concept - if the base-class concept fits. (It might not fit for Drupal or other frameworks at the low-level, but it will always fit at the high-level, as far as I can figure.)

And one *could* write controllers independently of any framework. It's possible by using (one or several different) controller base-classes. As explained, we have been doing that. A particular controller strategy can be packaged as a stand-alone dependency, and you can freely move from one base-class to another with changes (internally in your controller-implementations) without affecting the public interface or routing etc.

Anyways, I'm not campaigning for this - I'm putting it out there because our team has had a really positive experience doing this, and I figured it might be useful to others. It would obviously make a lot more sense if the interface/package/spec was standardized, rather than everyone implementing this pattern on their own - it doesn't provide any interop if there are multiple identical packages with the same interface in different namespaces.

I'm definitely not looking for another PSR to get involved with, I'm just putting the idea out there.


--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/da2f210d-5c2f-6226-14c4-919dfd24b662%40garfieldtech.com.

Matthew Weier O'Phinney

unread,
Jan 26, 2017, 1:03:13 PM1/26/17
to php...@googlegroups.com
On Tue, Jan 24, 2017 at 1:14 PM, Rasmus Schultz <ras...@mindplay.dk> wrote:
>> While I can certainly see the value in the architecture this would imply,
>> it's by no means the only architecture
>
> I disagree that this implies architecture.
>
> "takes a request and returns a response" is in my opinion the least
> opinionated, most open-ended definition you can have of a controller - in my
> opinion, it does not imply architecture, at all. You're completely free to
> use traits, composition, base-classes, external services, registries,
> dependency-injection, middleware - anything you can dream up, the only
> requirement is that you ultimately take a PSR-7 request and produce a
> response, which, ultimately, if you're using PSR-7, you're going to, one way
> or the other.

It does imply architecture, however: one controller, one action.

Most MVC systems I've surveyed or participated in maintaining provide
a way to map multiple actions to a single controller, which
necessarily means multiple entry points:

```php
class SomeController
{
public function listAction($request)
{
}

public function fetchAction($request)
{
}

public function createAction($request)
{
}

public function deleteAction($request)
{
}
}
```

Sometimes this means standardization of method names (as detailed
above), sometimes there is a 1:1 relationship between an action and
the method name, sometimes there's a single entry method that then
dispatches to the appropriate method based on the action matched, etc.

Additionally, I've seen systems that will pull path matches and pass
them as discrete arguments to the controller/action, often with the
request as a catch-all at the end of the list:

```php
// Route: /article/:id
public function update($id, $request)
{
}
```

I personally have been pushing folks to follow the "1 route, 1
controller" paradigm, which is what your proposal suggests, but that's
a _suggestion_; _requiring_ it via a standard, however, means any
implementing library _requires_ that approach, which I suggest would
limit adoption.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

Rasmus Schultz

unread,
Jan 26, 2017, 2:08:48 PM1/26/17
to php...@googlegroups.com
We have support both for path-matching (via attributes provided by the router) and multiple action-methods in our controller base-class - this design doesn't prevent either of those things.

I reckon you're taking the term "controller" as meaning something other or more specific than the definition I use: anything that takes a request and produces a response is a controller.

How the request is interpreted, or what further steps or external dependencies are involved in creating the response, is not defined, nor relevant.

If the term "controller" is confusing, try the term "dispatchable" or "request dispatcher".

Early on in the PSR-15 process, the same interface signatures was proposed as the interface for dispatching a middleware-stack - having an interface that is this generic for something that is that specific, is silly.

This interface can be usefully applied to an endless number of request/response scenarios - anything from a single controller, middleware-stack or micro-framework, all the way up to complex frameworks like Drupal or WordPress.

I find it quite unopinionated - you can put behind that interface any kind of controller-like concept you can imagine, there is absolutely nothing about this interface that implies anything more than "takes a request, produces a response", which will fit just about any top-layer of any PSR-7 based architecture you can dream up, even clients for that matter.

It seems a lot of you assign a lot more meaning and intent to this than I was trying to convey - being able to build stand-alone controllers (or base-classes) which could be supported by routers, is just one use-case. There is absolutely nothing mandating that strategy over any other strategy.

I obviously shouldn't have used the term "controller" - but to me, because the term is so overloaded, it really doesn't mean anything specific. For example, the term "controller" is common in client-side view/model-abstractions,  and "front controller" is common when describing a catch-all "index.php", which is pretty far from something live a Drupal controller. The term to me is about as open-ended as anything.

I'd be fine with any other term, though personally I think "dispatcher" might be even more overloaded - everything gets dispatched, HTTP requests, API requests, methods, functions, closures....

What matters is that almost anything that uses PSR-7 under the hood could potentially implement this interface on the server, which paves the way for very high-level architecture, e.g. higher than middleware, where the middleware runner itself could be described in the abstract at this level. Currently those top layers have nothing formally in common and don't compose well, besides, of course, as middleware, but then you've already made the decision to use middleware, and that *does* imply architecture.


--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myWsLaaPKMaT%3DwG1OvDjsw9KH7ZiEpWgvFKo2%2BfiVo55UA%40mail.gmail.com.

Oscar Otero

unread,
Jan 26, 2017, 3:54:34 PM1/26/17
to php...@googlegroups.com
The PSR-15 DelegateInterface uses this signature:
Maybe it could be used also for this purpose, instead of something used exclusively inside a middleware.



You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

Rasmus Schultz

unread,
Jan 26, 2017, 4:00:40 PM1/26/17
to php...@googlegroups.com
> Maybe it could be used also for this purpose, instead of something used exclusively inside a middleware.

Yep - I made efforts to convince the PSR-15 team that we should actually wait and standardize this first, but it's already been forever and nobody wants to wait any longer than necessary for this one...

That said, I have a hard time imagining how anyone would manage to come up with ways to complicate the discussion about an interface this simple. It doesn't need a long description or lengthy discussion, I think - it's the highest-level of request/response abstraction you can have, but yeah... nobody wants to wait ;-)


To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/D620C423-EDB5-4247-8616-87A1347915E9%40gmail.com.

Rasmus Schultz

unread,
Apr 24, 2017, 9:47:11 AM4/24/17
to php...@googlegroups.com
I'd like to revive this thread.

I got to thinking about this again after opening this can of worms:


What I'm thinking is, a PSR for message operations is more or less a no-brainer either way - and regardless of the mentioned can of worms, we need at least the request/response interface, which I'm now going to refer to as a "handler".

Going ahead with a custom definition of that interface as part of PSR-15 would be a huge mistake, as this interface is extremely general - and whether or not it's useful as a means of implementing middleware by itself, it's useful and necessary for many other things.

I'd propose to dub this "HTTP Message Operations", and I'd propose it include the following:

interface HandlerInterface {
    public function handle(ServerRequestInterface $request): ResponseInterface;
}

interface RequestFilterInterface {
    public function filterRequest(ServerRequestInterface $request): ServerRequestInterface;
}

interface ResponseFilterInterface {
    public function filterResponse(ResponseInterface $response): ResponseInterface;
}

All of these interfaces are designed for server-side message operations - client-side processing would be out of scope for this, it's a whole other can of worms involving async etc.

The request and response filter interfaces are useful for pre-processing requests and post-processing responses - I believe these operations are just as basic as the request/response handler.

I have similar interfaces on several projects currently myself. I don't think it's hard to see the usefulness of standardizing on these?

I also don't think the details could possibly warrant year-long ongoing discussion about minute details? These interface are about as basic as anything can get - the most we can quibble about would be interface/method-names, e.g. mostly bikeshedding.

I'd like to write up a formal proposal if there is interest, unless any of you have really good reasons why this shouldn't exist, or why it wouldn't for some reason be a "slam dunk"? I know most PSRs are notoriously never a slam dunk, but it's hard for me to imagine what else we could quibble about over something this simple?

Let me know what you think please. (and let's keep discussions about middleware out of this thread, if possible.)

Thanks,
  Rasmus

Rivera, John

unread,
Apr 24, 2017, 10:16:07 AM4/24/17
to php...@googlegroups.com
I may be re-treading a previous discussion, but as I read the discussion, I begun to ask: why?

Why do we need a PSR for this at all?

HTTP request/response handling/filtering is very integral and ‘internal’ to a framework/library. There are many ways to approach this problem (as we have clearly seen), and they are largely self-contained within, and integral to, the framework.

PSR-7 (as an example) makes complete sense because it enables inter-op between frameworks, libraries and projects.

But this proposal — and PSR-15 along with it — is pushing the boundary of ‘inter-op’ and into ‘dictation’. I feel like we’re beginning to build an 'interface-framework’, which, in my humble opinion, is overstepping the role and purpose of the FIG.

Let frameworks be themselves, and let them innovate. There’s no need for us to tell them how to do things like this.

What do you think?
John

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

Rasmus Schultz

unread,
Apr 24, 2017, 10:35:12 AM4/24/17
to php...@googlegroups.com
John,

That point of view is extremely in-tune with my thinking.

Hence that other thread I started this week-end, I don't know if you looked at that?

PSR-15, as-is, does require someone to implement a dispatcher - that middleware-interface is no use on it's own. It is, as you say, pushing the boundary into dictation, by, at least to some extend, mandating more than is required for basic inter-op.

I don't think the interfaces I'm proposing here do that?

They're not dictating any implied architecture - they'd exist only to make it possible to abstract very high-level operations and make them interoperable.

The handler-interface, for example, could be used as an entry-point for an entire project, as a front-controller, as middleware (as discusssed in the other thread) and probably has myriad other uses.

Likewise, filtering a request or response is a very basic operation with many uses.

The point is, I don't have a single designated use for any of these three interfaces - you have your complete architectural freedom, but when you do have components where it's possible (and meaningful) to abstract from these high-level operations, you can implement one (or more) of these interfaces.

That helps with interoperability by allowing components to depend on other components in the abstract - to depend on a very small facet, or a very high-level abstraction of a request/response transformation.

The current PSR-15 proposal has an implied architecture: a flat middleware stack, the use of delegates, and the need for a dispatcher.

These interfaces don't have those kinds of implications.

Incidentally, if PSR-15 becomes the middleware standard, the implementations of middleware-dispatchers could confirm with the handler-interface I'm proposing without conflict - which would make it possible to replace your PSR-15 dispatcher with any other handler-implementation - which I think demonstrates the architectural freedom provided by these much simpler high-level interfaces.


To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/443F69E7-8049-48CB-BE7E-A6508B2AE06D%40buffalo.edu.

Rivera, John

unread,
Apr 24, 2017, 10:47:35 AM4/24/17
to php...@googlegroups.com
Excellent points, and after reading your response, I concur.

John

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

Michael Mayer

unread,
Apr 26, 2017, 4:34:13 AM4/26/17
to PHP Framework Interoperability Group, riv...@buffalo.edu

Well, some work is already done:
Currently, the main difference, which is still up for discussion(!):
  • ServerAction:__invoke instead of Handler:handle
Some arguments for and against __invoke:
I know, Rasmus and I disagree on __invoke, but I'm willing to go with the majority. For this reason, I invite Rasmus as an organisation member and everybody else who is interested to participate.

Bests,
Michael
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/HD5meon7TX0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages