Add Album tutorial to docs

[RalfEggert]

I really love Zend\Expressive so far. To really get in rolling for beginners, I would love to see a tutorial like the Album tutorial for a Zend\Mvc project. It is really nice to see the examples, but beginners will also look for help how to structure their applications based on Zend\Expressive properly.

Any ideas and thoughts about this?

[dannym87]

This is a great skeleton app for Expressive that provides a good base structure with a couple of small examples.

https://github.com/zendframework/zend-expressive-skeleton

[RalfEggert]

Yep, you are right. It is the perfect start into Zend\Expressive and all its cool features.

But the examples are a little too small for a real world application.

[weierophinney]

@RalfEggert — Since you asked for it, I'm going to take that as you volunteering to write it. 😄 I'll certainly proofread and provide feedback, if you want to create a WIP pull request for it.

[weierophinney]

@dannym87 — The skeleton gives structure, but doesn't really go into a full-fledged application; I think @RalfEggert is wanting something that shows off the various features and concerns when creating more than just the home page and a single API endpoint.

[codeliner]

@RalfEggert If you're looking for inspiration check out proophessor-do. Since the early days of zend-expressive this demo app is available and shows how expressive can be used to serve an event sourced domain model.

[RalfEggert]

@codeliner I really like your approach with an event sourced domain model, but (yes there must be one), I was thinking about a beginners tutorial for Zend\Expressive. Event sourcing would be too much for starters. But your structure is a way to start.

@weierophinney Kudos to you! Just turn the demander into the executor! ;-)

I would really love to spend all my free time on this. But currently I am writing on my new ZF3 book so my time is very limited. But I will try to spend as much time as possible on this. Furthermore this tutorial shouldn't be a one man show. I think a good approach would be something like this:

• Discuss the structure of files and paths
• Implement the tutorial code
• Write the tutorial

I will start to provide a structure to start the discussion soon. And then we will see how it goes.

[RalfEggert]

This is the first prototype of a structure to implement the "Getting Started" tutorial (http://framework.zend.com/manual/current/en/user-guide/overview.html) from the manual with Zend\Expressive. It is based on the Skeleton https://github.com/zendframework/zend-expressive-skeleton.

This is basically the structure of a Zend\Expressive project after the installation. The biggest problem would be that a tutorial will never be able to consider all combinations of routers, containers and template engines. So we should choice a set of components for the tutorial. I have chosen all the possible Zend Framework components for this structure. With other components like FastRoute or Twig it will look different.

+--- config/
|  +--- autoload/
|  |  +--- .gitignore
|  |  +--- dependencies.global.php
|  |  +--- errorhandler.local.php
|  |  +--- local.php.dist
|  |  +--- middleware-pipeline.global.php
|  |  +--- routes.global.php
|  |  +--- templates.global.php
|  |  +--- zend-expressive.global.php
|  +--- config.php
|  +--- container.php
+--- data/
+--- public/
|  +--- assets/
|  +--- .htaccess
|  +--- index.php
+--- src/
|  +--- Action/
|     +---  HomePageAction.php
|     +---  HomePageFactory.php
|     +---  PingAction.php
+--- templates/
|  +--- app/
|  |  +--- home-page.phtml
|  +--- error/
|  |  +--- 404.phtml
|  |  +--- error.phtml
|  +--- layout/
|     +--- default.phtml
+--- test/
|  +--- Action/
|     +---  HomePageActionTest.php
|     +---  HomePageFactoryTest.php
|     +---  PingActionTest.php
+--- vendor/
+--- composer.json

And this is my suggestion for a new more complex structure to implement the album tutorial. I marked all new files and directories.

+--- config/
|  +--- autoload/
|  |  +--- .gitignore
|  |  +--- album.routes.global.php                             <-- new
|  |  +--- album.dependencies.global.php                       <-- new
|  |  +--- album.templates.global.php                          <-- new
|  |  +--- database.global.php                                 <-- new
|  |  +--- dependencies.global.php
|  |  +--- errorhandler.local.php
|  |  +--- local.php.dist
|  |  +--- middleware-pipeline.global.php
|  |  +--- routes.global.php
|  |  +--- templates.global.php
|  |  +--- zend-expressive.global.php
|  +--- config.php
|  +--- container.php
+--- data/
+--- public/
|  +--- assets/
|  +--- .htaccess
|  +--- index.php
+--- src/
|  +--- Action/
|  |  +---  HomePageAction.php
|  |  +---  HomePageFactory.php
|  |  +---  PingAction.php
|  +--- Album/                                                 <-- new
|     +--- Action/                                             <-- new
|     |  +---  CreateAction.php                                <-- new
|     |  +---  CreateActionFactory.php                         <-- new
|     |  +---  DeleteAction.php                                <-- new
|     |  +---  DeleteActionFactory.php                         <-- new
|     |  +---  EditAction.php                                  <-- new
|     |  +---  EditActionFactory.php                           <-- new
|     |  +---  ListAction.php                                  <-- new
|     |  +---  ListActionFactory.php                           <-- new
|     |  +---  ShowAction.php                                  <-- new
|     |  +---  ShowActionFactory.php                           <-- new
|     +--- Entity/                                             <-- new
|     |  +---  AlbumEntity.php                                 <-- new
|     +--- Form/                                               <-- new
|     |  +---  AlbumForm.php                                   <-- new
|     +--- InputFilter/                                        <-- new
|     |  +---  AlbumInputFilter.php                            <-- new
|     +--- Table/                                              <-- new
|        +---  AlbumTable.php                                  <-- new
+--- templates/
|  +--- album/                                                 <-- new
|  |  +--- create.phtml                                        <-- new
|  |  +--- edit.phtml                                          <-- new
|  |  +--- delete.phtml                                        <-- new
|  |  +--- list.phtml                                          <-- new
|  |  +--- show.phtml                                          <-- new
|  +--- app/
|  |  +--- home-page.phtml
|  +--- error/
|  |  +--- 404.phtml
|  |  +--- error.phtml
|  +--- layout/
|     +--- default.phtml
+--- test/
|  +--- Action/
|     +---  HomePageActionTest.php
|     +---  HomePageFactoryTest.php
|     +---  PingActionTest.php
+--- vendor/
+--- composer.json

Any comments?

[dannym87]

@RalfEggert This looks very similar to the structure I've been working on. I started putting together an application yesterday evening using the default FastRoute router, twig, and Doctrine DBAL.

Check it out and let me know what you think

https://github.com/dannym87/expressive-album

[moderndeveloperllc]

@RalfEggert The only suggestion I could make is to not have the single action per class pattern, but to use a single class whose _invoke switches the method to private functions to handle the CRUD. This would make bring the files from 10 to 2 for the Album entity Action/ directory. Maybe I'm just too old school. I think that Apigility still does multiple methods per class, but that might change.

[weierophinney]

@moderndeveloperllc For RPC, we do a single method; however, how you break that up based on request method is up to you. We typically end up delegating to other methods. For REST, it's a bit different; the end-user doesn't interact with the controller, but rather the resource listener, which has methods for each possible action type. This is more of a service layer, though.

I'm generally of the mind 1 route/HTTP method combination per middleware It makes it far simpler to map, and keeps things nicely compartmentalized. It also removes the possibility of having required dependencies that might never be called — something quite common when you lump handlers for all request methods (not to mention routed paths) into a single class.

[moderndeveloperllc]

@weierophinney Thanks for taking the time to comment on this. You are correct in that I was thinking of the listener layer in Apigility. I guess my brain is trying to make the pattern middleware-as-controller instead of middleware-as-service. @RalfEggert I retract my suggestion :-) I do hope that #171 will help alleviate the need for some of those factory classes when using the zf service manager.

[RalfEggert]

Any comments to the suggested structure at the bottom of #176 (comment)

I think it is not optimal yet, since the files for the album are spread in three directories /config/, /src/ and /templates/.

What do others think? What is the best practice to write more complex Zend\Expressive applications?

[geerteltink]

@RalfEggert I would add a config/autoload/database.local.php as well with the database username and password.

Why add these: album.routes.global.php, album.dependencies.global.php, album.templates.global.php? You can just use the files that are already there: routes.global.php, dependencies.global.php, templates.global.php. Or if you like place all the album config in config/autoload/album.global.php.

Also you place all Album source files in an Album folder. You can just place them in src/, so in stead of src/Album/Action/CreateAction.php you could use src/Action/CreateAlbumAction.php or src/Action/Album/CreateAction.php. This is how I would do it:

+--- src/
|  +--- Action/
|  |  +---  HomePageAction.php
|  |  +---  HomePageFactory.php
|  |  +---  Album/
|  |  |     +---  CreateAction.php
|  |  |     +---  CreateFactory.php
|  |  |     +---  DeleteAction.php
|  |  |     +---  DeleteFactory.php
|  +--- Entity/
|  |  +---  AlbumEntity.php
|  +--- Form/
|  |  +---  AlbumForm.php
|  +--- InputFilter/
|  |  +---  AlbumInputFilter.php
|  +--- Table/
|     +---  AlbumTable.php

The beauty of expressive is that you choose your own structure.

EDIT: Or you can figure out a module structure like in ZF2. It only requires that you need to make sure the config files are loaded in config/config.php. I'm not sure if this works:

// Load config from src/Album/config/autoload/
foreach (Glob::glob('src/*/config/autoload/{{,*.}global,{,*.}local}.php', Glob::GLOB_BRACE) as $file) {
    $config = ArrayUtils::merge($config, include $file);
}

[weierophinney]

@RalfEggert I see pros and cons to both the structure you propose, as well as the one @xtreamwayz proposes. My feedback:

• I personally like the idea of putting all configuration related to a conceptual unit in a single file, e.g. config/autoload/album.global.php. This makes it easy for the developer to see the dependencies, routes, etc. specific to that "unit" in one place.
• One problem we have in the current skeleton is that we map the src/ directory to the Application namespace, which means that you end up with Application\Album as the namespace for the album-specific code. This would be an argument for a "module"-like system (e.g., modules/Album/); I'm not sure if I'm ready to consider such a feature for the skeleton for the initial stable version, however. Alternately, you can map the Album namespace to src/Album/, and be done with it.

My main feedback: choose something, and start writing!

[wwwgo-pl]

Maybe You can advise how ACL should look like in middleware app? Standard application has modules, controllers and actions which are natural resources. What is resource and privilege (in term of Zend ACL) in Expressive and ZF3? URI? (I see some disadvantages)

[akrabat]

I agree about a single config/autoload/album.global.php too.

The basic choice of organisation comes down:

1. src, templates and test are top-level directories with App and Application separated within each top-level directory
2. App and Application are at the top level (within a modules directory) with src, templates and test segregated within.

The structures would then look like:

1. src, templates & test at top-level    *  2. Application and Album at top-level
=====================================    *  =====================================
.                                        *  .
├── config                               *  ├── config
│   ├── autoload                         *  │   ├── autoload
│   │   ├── album.global.php             *  │   │   ├── album.global.php
│   │   ├── ...                          *  │   │   ├── ...
│   │   └── zend-expressive.global.php   *  │   │   └── zend-expressive.global.php
│   ├── config.php                       *  │   ├── config.php
│   └── container.php                    *  │   └── container.php
├── data                                 *  ├── data
├── src                                  *  ├── modules
│   ├── Album                            *  │   ├── Album
│   │   ├── Action                       *  │   │   ├── src
│   │   │   ├── CreateAction.php         *  │   │   │   ├── Action
│   │   │   └── CreateFactory.php        *  │   │   │   │   ├── CreateAction.php
│   │   ├── AlbumEntity.php              *  │   │   │   │   └── CreateFactory.php
│   │   ├── AlbumForm.php                *  │   │   │   ├── AlbumEntity.php
│   │   └── AlbumTable.php               *  │   │   │   ├── AlbumForm.php
│   └── App                              *  │   │   │   └── AlbumTable.php
│       └── Action                       *  │   │   ├── templates
│           ├── HomePageAction.php       *  │   │   │   └── album
│           ├── HomePageFactory.php      *  │   │   │       ├── create.phtml
│           └── PingAction.php           *  │   │   │       └── list.phtml
├── templates                            *  │   │   └── test
│   ├── album                            *  │   │       └── Action
│   │   ├── create.phtml                 *  │   │           ├── CreateActionTest.php
│   │   └── list.phtml                   *  │   │           └── CreateFactoryTest.php
│   ├── app                              *  │   └── App
│   │   └── home-page.phtml              *  │       ├── src
│   ├── error                            *  │       │   └── Action
│   │   ├── 404.phtml                    *  │       │       ├── HomePageAction.php
│   │   └── error.phtml                  *  │       │       ├── HomePageFactory.php
│   └── layout                           *  │       ├── templates
│       └── default.phtml                *  │       │   ├── app
├── test                                 *  │       │   │   └── home-page.phtml
│   ├── Album                            *  │       │   ├── error
│   │   └── Action                       *  │       │   │   ├── 404.phtml
│   │       ├── CreateActionTest.php     *  │       │   │   └── error.phtml
│   │       └── CreateFactoryTest.php    *  │       │   └── layout
│   └── App                              *  │       │       └── default.phtml
│       └── Action                       *  │       └── test
│           ├── HomePageActionTest.php   *  │           └── Action
│           └── HomePageFactoryTest.php  *  │               ├── HomePageActionTest.php
├── public                               *  │               └── HomePageFactoryTest.php
│   ├── ...                              *  ├── public
│   └── index.php                        *  │   ├── ...
└── vendor                               *  │   └── index.php
                                         *  └── vendor

Either works for me.

Whatever you do, don't make the src/ directory map to the \Application namespace and src/Album/ map to the \Album namespace.

[asgrim]

@akrabat I guess on the tree structure, it's going to depend on the scale of application you're working on. Advantages of having modules is that they can easily be separated into re-usable, standalone components.

If you're expecting to scale up with this being a potential future requirement, then having separate modules makes a lot of sense IMO, and they can be tested individually to. If you know you're never going to grow with that kind of requirement, then just having namespaces in the src structure should be fine.

For directly relating to this Album tutorial, I'd be slightly inclined to go with the "scalable" approach of having module\Application and module\Album as it demonstrates a more scalable approach.

[Maks3w]

1. I like to have the tests as close as possible to the original source. So the test controller could be in the same folder of the production controller. Reduce lot of waste time scrolling folders list up and down for move from test to controller
2. I prefer use domain names for the directory instead instead by types. So Action folder could be named as "Create" or even not exists and put all the content in the parent directory.

[RalfEggert]

@akrabat

I really like your second approach. It gives a lot of structure which is very important for beginners when they start to learn Zend\Expressive. I really tend to use that structure in the tutorial.

But wouldn't it make sense to start with a similar structure with the Zend\Expressive skeleton? Otherwise the beginning of the tutorial would look like this:

1. Install Zend\Expressive skeleton
2. Move application files around to /modules/Application/ path follow proper structure
3. Start with the new /modules/Album/ to implement album
4. ...

If the tutorial leaves the Application where they have been installed beginners will be confused. The same applies for one config/autoload/album.global.php file for the Album and for a couple of files for the Application.

Thoughts?

[geerteltink]

@RalfEggert I would say start with the skeleton anyway. It has an option for beginners with some examples or a bare bone option for pros.

Personally for me the structure is less important. Especially as a beginner I couldn't care less. Yes it would be helpful to mention something about expanding it and I need to start thinking about a modular structure in the future. But as a beginner I would be more interested in how to get a database connection started (doctrine, zend, pdo), forms, users, authentication (sessions, oauth, Ocramius/PSR7Session), authorization, how to separate the backend and the frontend. In a framework most of these are included already, in expressive not. And even though those modules are available in frameworks, people still struggle with them according to the questions on the web. I think that is where a tutorial can be really helpful.

Besides that, why a tutorial for an album? Who actually needs an album? Why not about building your own blog or a basic company website with a contact form etc.

[RalfEggert]

@xtreamwayz

I have done a lot of ZF2 consulting in the last two years and in almost every project I identified the same pattern. Due to bad knowledge of how to structure and modularize a ZF2 MVC application the project is a real mess in most cases. People start with basic tutorials and put files almost anywhere. The Application module turns into a God module with dozens and hundreds of classes. To know how to structure an application is essential for beginners.

But you are right. Starting with the skeleton might be a still a good idea. Within such a 2. part explaining HOW to move files around it is the best place to explain WHY to move these files around. That will help beginners how to structure their applications. If the tutorial stuffs database, forms, users, auth, etc. anywhere without really caring of a good base structure will teach beginners how to build applications with a bad structure.

Why an album tutorial? Because the MVC part has it as well and it will be good start for beginners when they compare both tutorials...

[geerteltink]

@RalfEggert Thanx for the explanation. Makes perfect sense.

[akrabat]

Tricky, isn't it?! It all depends on how you "think" about application structure.

I think that the "layout 1" option that I presented works well for a lot of even relatively complex applications. Of course, as @asgrim points out, layout 1 doesn't allow for easily reusing a code between applications, though I wonder how common that actually is. Personally, I'd have src/App and test/App directories in the skeleton to make it clear the additional namespaces are encouraged. This would then make it easy to extend it for an album tutorial that fits the current structure.

If you do want to go down then "modules layout" route, then I would start the tutorial by deleting the src, test and templates/app directories completely along with both App autoload lines in composer.json & the relevant sections from the config files in from the config/autoload directory. This would leave you with an "empty" application structure and you can then start with "Now lets create a modules directory..." I probably wouldn't bother with an Application namespace at all and route / to \Album\Action\ListAction. This leaves the top level templates directory holding the layouts and error view scripts, which is probably fine as it saves having to reconfigure them.

Dealing with the configuration is the most complex in some ways as the organisation of the skeleton's set of config/autoload files really doesn't lend itself to easily reorganising, which is why the skeleton lends itself to apps that look more like layout 1 than layout 2.

[geerteltink]

I'm not sure how useful it is, but I could add an option to the skeleton to create layout 1 for small projects and layout 2 for big modular applications. The namespaces are still the same, only the files are saved in a different structure.

[RalfEggert]

@xtreamwayz

An option would be nice.

@akrabat

Clearing the application to start with an empty application structure sounds interesting.

[snapshotpl]

https://github.com/RalfEggert/zend-expressive-tutorial/blob/part4/doc/book/part2.md AlbumListAction - constructor shouldn't allow to null for template renderer

[RalfEggert]

Good catch, fixed it.

[RalfEggert]

Ok, I finally finished all 6 parts of the tutorial:

https://github.com/RalfEggert/zend-expressive-tutorial/tree/part6/doc/book

Please review and send suggestions and PRs for any typo or other stuff that needs to be improved.

@weierophinney

Please review as well. If everything is ok I will be happy to add the tutorial to the Zend\Expressive docs then.

[RalfEggert]

Oh, just one thing. I will update the code and the text whenever RC6 is out. Maybe we should wait for the addition to Zend\Expressive then.

[RalfEggert]

@weierophinney

Forgot to write here, that I updated the tutorial to the newest RCs. Ready to review!

[weierophinney]

@RalfEggert Thanks!

We're planning on releasing the stable version today. Once that's done, I'll start doing a thorough review of the tutorial as well as the tutorial code, and we can hopefully then add it very soon; I'm sure many folks will be wanting to see this!

[froschdesign]

@RalfEggert
Is your tutorial ready or any updates needed for version 2 of zend-expressive?

[lowtower]

Hello @froschdesign,
I have tried to make the tutorial v2 ready.
You can have a look at gitlab.io.
https://lowtower.gitlab.io/zend-expressive2-tutorial/book/part1.

[RalfEggert]

@froschdesign

Unfortunately, I never found the time to make the tutorial ready for Zend\Expressive 2. So, maybe the version of @lowtower is a better start. It even looks as if it has more parts added.

[froschdesign]

@lowtower
Very good, but I see some problems. How can we fix them?

@RalfEggert
Do you see any chance to continue your work?

[RalfEggert]

@froschdesign

Not in the next weeks or even months. I have not enough spare time at present. Too much work and a family, if you know what I mean...

What are the problems with the version of @lowtower then?

[lowtower]

@froschdesign if you mean, where to find the code, it's to find at gitlab as well.
https://gitlab.com/lowtower/zend-expressive2-tutorial

I have to say that I am not a professional programmer and created/amended the tutorial to learn myself and have it as a reminder.
I used it as a playground to learn about unit testing, ci, coding styles, ...
But I can easily bring it back to github if needed and make required changes.
Cheers,
Lowtower.

[froschdesign]

@RalfEggert
I know what you mean – no problem. Thanks for the quick response!

@lowtower

…it's to find at gitlab as well.

I know this, but we are here at GitHub. 😉

Some problems I found:

• Mixed coding styling
• Unit testing in the tutorial is too much. This should be separated, like the MVC tutorial:
  • Getting Started with Zend Framework
  • Unit Testing A zend-mvc Application
• The extra hydrator Zend\Hydrator\ArraySerializable is not needed for a Table Gateway or a form. (Zend\Db\ResultSet\ResultSet uses already exchangeArray and Zend\Form\Fieldset adds the hydrator ArraySerializable automatically.)
• Part 7 - Make the album module more modular: an alternative way for configuration is explained here. I think only one way should be explained, if the name of the tutorial is "Getting Started with Zend Expressive".
• I like Part 8 ("Abstract factory") and Part 9 ("Config abstract factory") because of the concrete examples. But we should add a title like "Extras". The tutorial itself ends with Part 5 ("Updating and deleting albums").
• Part 9 - Using zend-paginator in your Album Module: In the entire tutorial there is no "AlbumTable". (I think this was copied from the MVC tutorial.)

Btw. Thanks for your work! 👍

[lowtower]

Hello @froschdesign,

I have just created a repository at github for my tutorial changes/additions (see https://github.com/lowtower/zend-expressive2-tutorial).

I propose to keep the repository similar to the one of Ralf regarding the parts 1-5.
I would like to create another repository (e.g. zend-expressive2-tutorial-extra) for additional parts as suggested by You, just like unit tests, pagination, navigation, abstract factory vs. config abstract factory, ...
My idea is to take zend-expressive2-tutorial/part5 as a starting point and extend it with only one of the topics above.
Maybe another repo could combine all the features/best practices from above in one single place.

I started with part1 from scratch using the latest skeleton and would like to get Your feedback regarding coding style (e.g. where to get a valid .php_cs file for zend-expressive?).
I guess, I need Your help regarding all that travis, coveralls, ... stuff as I am used to gitlab ci.

Cheers,
LowTower.

[lowtower]

Hello @froschdesign,

I have finished and uploaded part3 to github.
Maybe You find the time to review. I would appreciate it much before I continue.
I have switched to sqlite, because I see the advantage that the user immediately has a working project, but kept a comment about configuring MySQL, which is not very elegant - I admit.

Cheers,
LowTower.

[froschdesign]

@lowtower

I have just created a repository at github for my tutorial changes/additions

Thanks! 👍

Maybe You find the time to review. I would appreciate it much before I continue.

I think tomorrow I'll have time for it.
One thing I have seen: if the Zend\Stdlib\ArraySerializableInterface is implemented then no hydrator is needed.

@weierophinney
Any comments or some suggestions for the next steps?

[lowtower]

I have added some issues/questions that arose while writing the first chapters, e.g. php version, ...
I will add more, If I have doubts or questions on how to proceed.

[lowtower]

@froschdesign

parts 1 - 5 are ready to review!

[lowtower]

Hello @froschdesign,

I have removed the zend-hydrator from the form factory.
Question: why is the zend-hydrator only in require-dev in zend-db.
That way it's not installed by composer and I still have to do it manually!

Cheers,
LT.

[froschdesign]

@lowtower

…I still have to do it manually!

You can use zend-db without zend-hydrator. It's only a soft dependency.
See in the "suggest" section:

https://github.com/zendframework/zend-db/blob/748f065ab8e64ab66213182a671513e9499957bc/composer.json#L26-L30

---

In the AlbumTableGatewayFactory you can use Zend\Db\ResultSet\ResultSet:

$resultSetPrototype = new Zend\Db\ResultSet\ResultSet();
$resultSetPrototype->setArrayObjectPrototype(new AlbumEntity());

return new AlbumTableGateway(
    $container->get(AdapterInterface::class),
    $resultSetPrototype
);

Maybe this is easier to explain, because the first parameter (null) of the HydratingResultSet is misleading. And if we remove the hydrator from the quick start, then we should remove also the HydratingResultSet.
The topic hydrator can be moved to an additional part.

[froschdesign]

@lowtower
Sorry for the late response, I hope I can fork and review the tutorial over the weekend.

[lowtower]

@froschdesign,

the first parameter wasn't null in ralfeggert's original tutorial.
I made it null, because I misunderstood You, when You said,

The extra hydrator Zend\Hydrator\ArraySerializable is not needed ...

That's what it was before:

$resultSetPrototype = new HydratingResultSet(
    new ArraySerializable(),
    new AlbumEntity()
);

return new AlbumTableGateway(
    $container->get(AdapterInterface::class),
    $resultSetPrototype
);

[lowtower]

@froschdesign,

I put my effort on hold until the psr-15 discussion has settled down and maybe zend-expressive 3 is released or whatever comes with psr-15.

Cheers,
LT.

[weierophinney]

This repository has been closed and moved to mezzio/mezzio; a new issue has been opened at mezzio/mezzio#19.