Proposal for a PSR-7 middleware skeleton application

[Enrico Zimuel-2]

Hi all,

i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:

https://github.com/ezimuel/zend-stratigility-skeleton

I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:

https://github.com/ezimuel/zend-stratigility-dispatch

The goal of this skeleton application is to give a minimum infrastructure to be able to build simple web applications using middleware, compliant with PSR-7. I used the architecture proposal of Action-Domain-Responder (an MVC like approach explained here http://pmjones.io/adr/).

The idea is to have actions (inside the /action folder) that can be executed by the dispatcher using a simple configuration file (/config/route.php). In the skeleton, the dependencies of the action are managed using Factories. In the configuration file we used the factories directly, e.g. App\Action\HomepageFactory::factory.

This is just an example, you can use also different methods, for instance using a closure inside the configuration file:

'action' => function($request, $response, $next) {

    $user = new App\Domain\User(); 

    $page = new App\Action\Foo($user);

    return $page->action($request, $response, $next);

}

Or using object from a Container, using the setContainer() method, see example here:

https://github.com/ezimuel/zend-stratigility-dispatch#using-a-container

Let me know what do you think about this skeleton proposal.

Thanks!

Regards,

Enrico Zimuel

--

[Sascha-Oliver Prolic]

Hi Enrico,

What I dislike is the constructor being part of the Zend\Stratigility\Dispatch\Router\RouterInterface.

How you get some config there (or if you even need any) should be part of the implementation detail.

About the stratigility skeleton itself:

I dislike two things, first the domain folder. Can be a nice hint for some beginners, but I expect middleware in more complex scenarios, where having a "put your stuff here" folder called "domain" doesn't work that well. I would leave this as suggestion in the readme, f.e.

Second, the proposed action and template directories. Again nice start for very very small demo-apps, but I can't imagine that being usefull for a real word middleware application.

Last a question: Is this also meant to play together with zend-diactoros? If so, a short example would be helpfull.

Sorry, I can't contribute much more right now, but lot's of other usefull stuff is coming out from me the next few months :-) Anyway, thanks for your work !!!

Best

Sascha

2015-06-15 16:07 GMT+02:00 Enrico Zimuel <[hidden email]>:

Hi all,

i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:

https://github.com/ezimuel/zend-stratigility-skeleton

I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:

https://github.com/ezimuel/zend-stratigility-dispatch

The goal of this skeleton application is to give a minimum infrastructure to be able to build simple web applications using middleware, compliant with PSR-7. I used the architecture proposal of Action-Domain-Responder (an MVC like approach explained here http://pmjones.io/adr/).

The idea is to have actions (inside the /action folder) that can be executed by the dispatcher using a simple configuration file (/config/route.php). In the skeleton, the dependencies of the action are managed using Factories. In the configuration file we used the factories directly, e.g. App\Action\HomepageFactory::factory.

This is just an example, you can use also different methods, for instance using a closure inside the configuration file:

'action' => function($request, $response, $next) {

    $user = new App\Domain\User(); 

    $page = new App\Action\Foo($user);

    return $page->action($request, $response, $next);

}

Or using object from a Container, using the setContainer() method, see example here:

https://github.com/ezimuel/zend-stratigility-dispatch#using-a-container

Let me know what do you think about this skeleton proposal.

Thanks!

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

[Sascha-Oliver Prolic]

And: Please forget about my diactoros question, it's in the public/index.php of course ! Me, stupid, lol

Best

Sascha

2015-06-16 1:57 GMT+02:00 Sascha-Oliver Prolic <[hidden email]>:

Hi Enrico,

What I dislike is the constructor being part of the Zend\Stratigility\Dispatch\Router\RouterInterface.

How you get some config there (or if you even need any) should be part of the implementation detail.

About the stratigility skeleton itself:

I dislike two things, first the domain folder. Can be a nice hint for some beginners, but I expect middleware in more complex scenarios, where having a "put your stuff here" folder called "domain" doesn't work that well. I would leave this as suggestion in the readme, f.e.

Second, the proposed action and template directories. Again nice start for very very small demo-apps, but I can't imagine that being usefull for a real word middleware application.

Last a question: Is this also meant to play together with zend-diactoros? If so, a short example would be helpfull.

Sorry, I can't contribute much more right now, but lot's of other usefull stuff is coming out from me the next few months :-) Anyway, thanks for your work !!!

Best

Sascha

Sascha-Oliver Prolic

2015-06-15 16:07 GMT+02:00 Enrico Zimuel <[hidden email]>:

Hi all,

i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:

https://github.com/ezimuel/zend-stratigility-skeleton

I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:

https://github.com/ezimuel/zend-stratigility-dispatch

The goal of this skeleton application is to give a minimum infrastructure to be able to build simple web applications using middleware, compliant with PSR-7. I used the architecture proposal of Action-Domain-Responder (an MVC like approach explained here http://pmjones.io/adr/).

The idea is to have actions (inside the /action folder) that can be executed by the dispatcher using a simple configuration file (/config/route.php). In the skeleton, the dependencies of the action are managed using Factories. In the configuration file we used the factories directly, e.g. App\Action\HomepageFactory::factory.

This is just an example, you can use also different methods, for instance using a closure inside the configuration file:

'action' => function($request, $response, $next) {

    $user = new App\Domain\User(); 

    $page = new App\Action\Foo($user);

    return $page->action($request, $response, $next);

}

Or using object from a Container, using the setContainer() method, see example here:

https://github.com/ezimuel/zend-stratigility-dispatch#using-a-container

Let me know what do you think about this skeleton proposal.

Thanks!

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

[Ralf Eggert]

Hi Enrico,

firstly, like Sascha said, I don't really like interfaces which contain
the constructor for a class.

Then, the installation went very smooth except that a .htaccess was
missing in the public folder to do the mod_rewrite stuff for apache.
With the absence of a .htaccess the /page route does not work. If you
don't want to bind the project to a specific webserver you should at
least document the absence of the .htaccess.

Next, I wonder why you checked in the composer.lock file. Just by
mistake or for a deeper sense?

Finally, I wonder why you use the Plates template system. I never heard
of it before. It looks very lightweight but I really wonder why
Zend\View is not used at all. Maybe due to its complexity? Maybe we need
a lightweight alternative for Zend\View as well?

Thanks and best regards,

Ralf

[Enrico Zimuel-2]

Hi Sascha,

thanks for your comments, I reply inline.

On Tue, Jun 16, 2015 at 1:57 AM, Sascha-Oliver Prolic <[hidden email]> wrote:

Hi Enrico,

What I dislike is the constructor being part of the Zend\Stratigility\Dispatch\Router\RouterInterface.

How you get some config there (or if you even need any) should be part of the implementation detail.

The router adapter requires configuration, the idea is to read a common configuration files (like https://github.com/ezimuel/zend-stratigility-dispatch/blob/master/test/TestAsset/config.php) and create a concrete route object based on the specific router system.

You right for the constructor in the interface, it's not a great idea. We can replace it by a setConfig(array $config), we can even add a getConfig().

  

About the stratigility skeleton itself:

I dislike two things, first the domain folder. Can be a nice hint for some beginners, but I expect middleware in more complex scenarios, where having a "put your stuff here" folder called "domain" doesn't work that well. I would leave this as suggestion in the readme, f.e.

Second, the proposed action and template directories. Again nice start for very very small demo-apps, but I can't imagine that being usefull for a real word middleware application.

I don't think this skeleton proposal cannot be valid even for big applications. The "domain" folder is just a proposal where to put the business logic. It can contains complex structure with sub-folder and namespace. I think this is a good start and also a best practices for beginners. Experienced developers can add/remove stuff as they want. I think this skeleton will be more useful for beginners so we need to have a clear and simple folder structure here. Moreover, I'm trying to advertize here the Action-Domain-Responder (http://pmjones.io/adr/), that's why I created action and domain folders.

Regarding the template folder, again I don't think this is too simplistic. Why do you think so? 

This folder can contains sub-folder, like layout, or specific template for specific actions.

Regards,

Enrico Zimuel

--

[Enrico Zimuel-2]

Hi Ralf,

thanks for your comments, I reply inline.

On Tue, Jun 16, 2015 at 5:47 AM, Ralf Eggert <[hidden email]> wrote:

Hi Enrico,

firstly, like Sascha said, I don't really like interfaces which contain
the constructor for a class.

As I replied to Sascha this was a bad idea, I agree. We can replace it by a setConfig(array $config). 

Then, the installation went very smooth except that a .htaccess was
missing in the public folder to do the mod_rewrite stuff for apache.
With the absence of a .htaccess the /page route does not work. If you
don't want to bind the project to a specific webserver you should at
least document the absence of the .htaccess.

You right, I forgot it :)

I will add a specific .htaccess and I'll update the README with a mini how-to for .nginx and even IIS.

 

Next, I wonder why you checked in the composer.lock file. Just by
mistake or for a deeper sense?

It's not a mistake, composer.lock should be put under version control for applications because it simplifies the management and deployment phase.

Without the composer.lock when you do a "composer install" you can get a different version of the vendor library, because some libraries can have more recent version.

The composer.lock file is the only way to be sure to reuse the exact same version.

Imagine you have a 1.* version specified in composer and you develop against 1.1.4. If you pass your application to another user with composer.lock and the user executes a composer install, he will get the same version 1.1.4, even if even 1.2 has been released in the meantime.

A skeleton project is de facto a starter of an application, that means composer.lock should be part of the skeleton.

We applied this practice also to ZendSkeletonApplication and zf-apigility-skeleton.

 

Finally, I wonder why you use the Plates template system. I never heard
of it before. It looks very lightweight but I really wonder why
Zend\View is not used at all. Maybe due to its complexity? Maybe we need
a lightweight alternative for Zend\View as well?

I used Plates because it supports template using just PHP, no external template language. It's very simple and light and it's a perfect fit for this skeleton use case.

Zend\View is quite complex, it requires the EventManager and it's quite coupled with the MVC logic.

This is also the reason because I choose to term "Template" instead of "View" to differentiate it against Zend\View.

I don't think we need to implement a new light template system in Zend, we can use an external component like Plates, we don't want to reinvent the wheel.

Regards,

Enrico Zimuel

--

[Spabby]

Personally...

I don't like the approach of having an "action" and a "domain" folder that is an autoloaded location for "App\Action" and "App\Domain". I don't know what annoys me about this but I suppose that it's we're binding users to one namespace - I'd prefer we allowed flexibility here.

I completely agree that being opinionated is needed to help new users to understand what's going on, but I personally feel that grouping user code in it's own directory would be cleaner. It would also open the door to including the module manager at a later date.

Enrico, would you be open to be doing some work around integrating the module manager please?

Gary

On Tue, 16 Jun 2015 at 07:27 Enrico Zimuel <[hidden email]> wrote:

Hi Ralf,

thanks for your comments, I reply inline.

On Tue, Jun 16, 2015 at 5:47 AM, Ralf Eggert <[hidden email]> wrote:

Hi Enrico,

firstly, like Sascha said, I don't really like interfaces which contain
the constructor for a class.

As I replied to Sascha this was a bad idea, I agree. We can replace it by a setConfig(array $config). 

Then, the installation went very smooth except that a .htaccess was
missing in the public folder to do the mod_rewrite stuff for apache.
With the absence of a .htaccess the /page route does not work. If you
don't want to bind the project to a specific webserver you should at
least document the absence of the .htaccess.

You right, I forgot it :)

I will add a specific .htaccess and I'll update the README with a mini how-to for .nginx and even IIS.

 

Next, I wonder why you checked in the composer.lock file. Just by
mistake or for a deeper sense?

It's not a mistake, composer.lock should be put under version control for applications because it simplifies the management and deployment phase.

Without the composer.lock when you do a "composer install" you can get a different version of the vendor library, because some libraries can have more recent version.

The composer.lock file is the only way to be sure to reuse the exact same version.

Imagine you have a 1.* version specified in composer and you develop against 1.1.4. If you pass your application to another user with composer.lock and the user executes a composer install, he will get the same version 1.1.4, even if even 1.2 has been released in the meantime.

A skeleton project is de facto a starter of an application, that means composer.lock should be part of the skeleton.

We applied this practice also to ZendSkeletonApplication and zf-apigility-skeleton.

 

Finally, I wonder why you use the Plates template system. I never heard
of it before. It looks very lightweight but I really wonder why
Zend\View is not used at all. Maybe due to its complexity? Maybe we need
a lightweight alternative for Zend\View as well?

I used Plates because it supports template using just PHP, no external template language. It's very simple and light and it's a perfect fit for this skeleton use case.

Zend\View is quite complex, it requires the EventManager and it's quite coupled with the MVC logic.

This is also the reason because I choose to term "Template" instead of "View" to differentiate it against Zend\View.

I don't think we need to implement a new light template system in Zend, we can use an external component like Plates, we don't want to reinvent the wheel.

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

[GianArb]

Hi! Thanks for your work

I have one question though, , why did you decide to don't integrate the module manager?

Was the ZendSkeletonApplication a bad fit for the purpose or simply this approach doesn't require such integration?

2015-06-15 16:07 GMT+02:00 Enrico Zimuel <[hidden email]>:

Hi all,

i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:

https://github.com/ezimuel/zend-stratigility-skeleton

I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:

https://github.com/ezimuel/zend-stratigility-dispatch

The goal of this skeleton application is to give a minimum infrastructure to be able to build simple web applications using middleware, compliant with PSR-7. I used the architecture proposal of Action-Domain-Responder (an MVC like approach explained here http://pmjones.io/adr/).

The idea is to have actions (inside the /action folder) that can be executed by the dispatcher using a simple configuration file (/config/route.php). In the skeleton, the dependencies of the action are managed using Factories. In the configuration file we used the factories directly, e.g. App\Action\HomepageFactory::factory.

This is just an example, you can use also different methods, for instance using a closure inside the configuration file:

'action' => function($request, $response, $next) {

    $user = new App\Domain\User(); 

    $page = new App\Action\Foo($user);

    return $page->action($request, $response, $next);

}

Or using object from a Container, using the setContainer() method, see example here:

https://github.com/ezimuel/zend-stratigility-dispatch#using-a-container

Let me know what do you think about this skeleton proposal.

Thanks!

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

[Enrico Zimuel-2]

Hi Gary,

are you suggesting to collect the 3 folders: /action, /domain, and /template inside a /src or /app ?

\app\action

\app\domain

\app\template

\config

\public

\test

If this is not your idea, can you explain in more detail? 

Regarding the module manager I don't think it makes sense to integrate it for a middleware skeleton like that.

The goal of this middleware skeleton is to have a different architecture, in addition to the MVC, to build web applications. 

In ZF3 we'll have 2 possibility to build web applications or API: Middleware or MVC.

Of course, we can work on a bridge to connect MVC with Middleware (and maybe viceversa), but this is another story.

A middleware component that can route MVC applications based on ZF2, for backward compatibilty?

 

Regards,

Enrico Zimuel

On Tue, Jun 16, 2015 at 10:54 AM, Gary Hockin <[hidden email]> wrote:

Personally...

I don't like the approach of having an "action" and a "domain" folder that is an autoloaded location for "App\Action" and "App\Domain". I don't know what annoys me about this but I suppose that it's we're binding users to one namespace - I'd prefer we allowed flexibility here.

I completely agree that being opinionated is needed to help new users to understand what's going on, but I personally feel that grouping user code in it's own directory would be cleaner. It would also open the door to including the module manager at a later date.

Enrico, would you be open to be doing some work around integrating the module manager please?

Gary

On Tue, 16 Jun 2015 at 07:27 Enrico Zimuel <[hidden email]> wrote:

Hi Ralf,

thanks for your comments, I reply inline.

On Tue, Jun 16, 2015 at 5:47 AM, Ralf Eggert <[hidden email]> wrote:

Hi Enrico,

firstly, like Sascha said, I don't really like interfaces which contain
the constructor for a class.

As I replied to Sascha this was a bad idea, I agree. We can replace it by a setConfig(array $config). 

Then, the installation went very smooth except that a .htaccess was
missing in the public folder to do the mod_rewrite stuff for apache.
With the absence of a .htaccess the /page route does not work. If you
don't want to bind the project to a specific webserver you should at
least document the absence of the .htaccess.

You right, I forgot it :)

I will add a specific .htaccess and I'll update the README with a mini how-to for .nginx and even IIS.

 

Next, I wonder why you checked in the composer.lock file. Just by
mistake or for a deeper sense?

It's not a mistake, composer.lock should be put under version control for applications because it simplifies the management and deployment phase.

Without the composer.lock when you do a "composer install" you can get a different version of the vendor library, because some libraries can have more recent version.

The composer.lock file is the only way to be sure to reuse the exact same version.

Imagine you have a 1.* version specified in composer and you develop against 1.1.4. If you pass your application to another user with composer.lock and the user executes a composer install, he will get the same version 1.1.4, even if even 1.2 has been released in the meantime.

A skeleton project is de facto a starter of an application, that means composer.lock should be part of the skeleton.

We applied this practice also to ZendSkeletonApplication and zf-apigility-skeleton.

 

Finally, I wonder why you use the Plates template system. I never heard
of it before. It looks very lightweight but I really wonder why
Zend\View is not used at all. Maybe due to its complexity? Maybe we need
a lightweight alternative for Zend\View as well?

I used Plates because it supports template using just PHP, no external template language. It's very simple and light and it's a perfect fit for this skeleton use case.

Zend\View is quite complex, it requires the EventManager and it's quite coupled with the MVC logic.

This is also the reason because I choose to term "Template" instead of "View" to differentiate it against Zend\View.

I don't think we need to implement a new light template system in Zend, we can use an external component like Plates, we don't want to reinvent the wheel.

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

[Enrico Zimuel-2]

Hi Gianluca,

the idea of this skeleton application is to give a minimum infrastructure for building web application using a different approach: middleware.

As I wrote also to Gary, I don't think we should support the module manager for this scenario.

I see a possible module manager integration for backward compatibility scope (or maybe for a new middleware module manager).

Regards,

Enrico Zimuel

On Tue, Jun 16, 2015 at 11:07 AM, Gianluca Arbezzano <[hidden email]> wrote:

Hi! Thanks for your work

I have one question though, , why did you decide to don't integrate the module manager?

Was the ZendSkeletonApplication a bad fit for the purpose or simply this approach doesn't require such integration?

2015-06-15 16:07 GMT+02:00 Enrico Zimuel <[hidden email]>:

Hi all,

i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:

https://github.com/ezimuel/zend-stratigility-skeleton

I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:

https://github.com/ezimuel/zend-stratigility-dispatch

The goal of this skeleton application is to give a minimum infrastructure to be able to build simple web applications using middleware, compliant with PSR-7. I used the architecture proposal of Action-Domain-Responder (an MVC like approach explained here http://pmjones.io/adr/).

The idea is to have actions (inside the /action folder) that can be executed by the dispatcher using a simple configuration file (/config/route.php). In the skeleton, the dependencies of the action are managed using Factories. In the configuration file we used the factories directly, e.g. App\Action\HomepageFactory::factory.

This is just an example, you can use also different methods, for instance using a closure inside the configuration file:

'action' => function($request, $response, $next) {

    $user = new App\Domain\User(); 

    $page = new App\Action\Foo($user);

    return $page->action($request, $response, $next);

}

Or using object from a Container, using the setContainer() method, see example here:

https://github.com/ezimuel/zend-stratigility-dispatch#using-a-container

Let me know what do you think about this skeleton proposal.

Thanks!

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

Gianluca Arbezzano
www.gianarb.it

--

[Sascha-Oliver Prolic]

Hi Enrico,

some additional input for you:

I dislike the directory name "domain". It easily maps to the action-domain-responder pattern, but, "domain" is a pretty useless word without any meaning here. It's the same as having a "model" folder, just rename "domain" to model". It explains not much about the application. I try not to use words like "domain", "model" or "service" when i seek for class names in my current domain i am modelling.

Having app/action, app/domain, app/template doesn't solve this much. It's just moving the stuff another folder down.

But perhabs the main problem I see is another one: Why do we need an Action-domain-responder at all? I understand, that this is meant as a distinct implemenation to MVC, but I see middleware and mvc as complementary tools, not as opponents. Therefore I like to see a middleware skeleton, without the need for an action-domain-responder, that should be opt-in, just like the MVC.

Best

Sascha

2015-06-16 13:39 GMT+02:00 Enrico Zimuel <[hidden email]>:

Hi Gianluca,

the idea of this skeleton application is to give a minimum infrastructure for building web application using a different approach: middleware.

As I wrote also to Gary, I don't think we should support the module manager for this scenario.

I see a possible module manager integration for backward compatibility scope (or maybe for a new middleware module manager).

Regards,

Enrico Zimuel

On Tue, Jun 16, 2015 at 11:07 AM, Gianluca Arbezzano <[hidden email]> wrote:

Hi! Thanks for your work

I have one question though, , why did you decide to don't integrate the module manager?

Was the ZendSkeletonApplication a bad fit for the purpose or simply this approach doesn't require such integration?

2015-06-15 16:07 GMT+02:00 Enrico Zimuel <[hidden email]>:

Hi all,

i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:

https://github.com/ezimuel/zend-stratigility-skeleton

I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:

https://github.com/ezimuel/zend-stratigility-dispatch

The goal of this skeleton application is to give a minimum infrastructure to be able to build simple web applications using middleware, compliant with PSR-7. I used the architecture proposal of Action-Domain-Responder (an MVC like approach explained here http://pmjones.io/adr/).

The idea is to have actions (inside the /action folder) that can be executed by the dispatcher using a simple configuration file (/config/route.php). In the skeleton, the dependencies of the action are managed using Factories. In the configuration file we used the factories directly, e.g. App\Action\HomepageFactory::factory.

This is just an example, you can use also different methods, for instance using a closure inside the configuration file:

'action' => function($request, $response, $next) {

    $user = new App\Domain\User(); 

    $page = new App\Action\Foo($user);

    return $page->action($request, $response, $next);

}

Or using object from a Container, using the setContainer() method, see example here:

https://github.com/ezimuel/zend-stratigility-dispatch#using-a-container

Let me know what do you think about this skeleton proposal.

Thanks!

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

Gianluca Arbezzano
www.gianarb.it

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

[kontakt]

Hi,

I agree with Sascha: domain should be renamed to model. In DDD domain  
is the problem space and model the solution space. So when you want to  
define a generic folder structure in your app then model is the better  
choice. Or when you really want to represent ADR in the folder  
structure then you should rename template to responder.

I also agree that ADR should be opt-in. For example I want to use  
zend-stratigility in front of a CQRS layer, so instead of having  
actions I have commands, queries and events. So I neither want to use  
MVC nor ADR but zend-stratigility. Enrico maybe you should rename the  
skeleton to zend-stratigility-adr-skeleton and also provide a  
zend-stratigility-mvc-skeleton with support for the module manager.  
Btw. I think you are right that the module manager should not be  
included by default. The middleware stack is a lightweight alternative  
but not as powerful as the module manager is. Integrating the module  
manager with a dedicated middleware sounds interesting.

Best,
Alexander Miertsch

[Spabby]

Hi Enrico,

That's exactly what I'm proposing, it opens up middleware to be more than one namespace this way.

With regards to the module manager, remember, it's only job is to merge config files etc. I'm wondering if we can have the lightweight middleware approach while keeping the epic resuability of modules. I'll do some investigation.

Gary

On Tue, 16 Jun 2015 at 12:36 Enrico Zimuel <[hidden email]> wrote:

Hi Gary,

are you suggesting to collect the 3 folders: /action, /domain, and /template inside a /src or /app ?

\app\action

\app\domain

\app\template

\config

\public

\test

If this is not your idea, can you explain in more detail? 

Regarding the module manager I don't think it makes sense to integrate it for a middleware skeleton like that.

The goal of this middleware skeleton is to have a different architecture, in addition to the MVC, to build web applications. 

In ZF3 we'll have 2 possibility to build web applications or API: Middleware or MVC.

Of course, we can work on a bridge to connect MVC with Middleware (and maybe viceversa), but this is another story.

A middleware component that can route MVC applications based on ZF2, for backward compatibilty?

 

Regards,

Enrico Zimuel

On Tue, Jun 16, 2015 at 10:54 AM, Gary Hockin <[hidden email]> wrote:

Personally...

I don't like the approach of having an "action" and a "domain" folder that is an autoloaded location for "App\Action" and "App\Domain". I don't know what annoys me about this but I suppose that it's we're binding users to one namespace - I'd prefer we allowed flexibility here.

I completely agree that being opinionated is needed to help new users to understand what's going on, but I personally feel that grouping user code in it's own directory would be cleaner. It would also open the door to including the module manager at a later date.

Enrico, would you be open to be doing some work around integrating the module manager please?

Gary

On Tue, 16 Jun 2015 at 07:27 Enrico Zimuel <[hidden email]> wrote:

Hi Ralf,

thanks for your comments, I reply inline.

On Tue, Jun 16, 2015 at 5:47 AM, Ralf Eggert <[hidden email]> wrote:

Hi Enrico,

firstly, like Sascha said, I don't really like interfaces which contain
the constructor for a class.

As I replied to Sascha this was a bad idea, I agree. We can replace it by a setConfig(array $config). 

Then, the installation went very smooth except that a .htaccess was
missing in the public folder to do the mod_rewrite stuff for apache.
With the absence of a .htaccess the /page route does not work. If you
don't want to bind the project to a specific webserver you should at
least document the absence of the .htaccess.

You right, I forgot it :)

I will add a specific .htaccess and I'll update the README with a mini how-to for .nginx and even IIS.

 

Next, I wonder why you checked in the composer.lock file. Just by
mistake or for a deeper sense?

It's not a mistake, composer.lock should be put under version control for applications because it simplifies the management and deployment phase.

Without the composer.lock when you do a "composer install" you can get a different version of the vendor library, because some libraries can have more recent version.

The composer.lock file is the only way to be sure to reuse the exact same version.

Imagine you have a 1.* version specified in composer and you develop against 1.1.4. If you pass your application to another user with composer.lock and the user executes a composer install, he will get the same version 1.1.4, even if even 1.2 has been released in the meantime.

A skeleton project is de facto a starter of an application, that means composer.lock should be part of the skeleton.

We applied this practice also to ZendSkeletonApplication and zf-apigility-skeleton.

 

Finally, I wonder why you use the Plates template system. I never heard
of it before. It looks very lightweight but I really wonder why
Zend\View is not used at all. Maybe due to its complexity? Maybe we need
a lightweight alternative for Zend\View as well?

I used Plates because it supports template using just PHP, no external template language. It's very simple and light and it's a perfect fit for this skeleton use case.

Zend\View is quite complex, it requires the EventManager and it's quite coupled with the MVC logic.

This is also the reason because I choose to term "Template" instead of "View" to differentiate it against Zend\View.

I don't think we need to implement a new light template system in Zend, we can use an external component like Plates, we don't want to reinvent the wheel.

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

[Enrico Zimuel-2]

Hi Gary,

actually, using a middleware approach the need of a module manager is not so relevant, let me explain with an example.

Suppose we have a ZF2 application that consumes three modules Foo, Bar and Baz. We can have an application.config.php that looks like that:

return array(
    'modules' => array(
        'Foo',

        'Bar',

        'Baz'
    ),

    // ...
);

In our stratigility solution this is equivalent to a simple pipe of 3 middleware "modules":

$app = new MiddlewarePipe();
$app->pipe('/', MiddlewareDispatch::factory(require '../foo/config/route.php'));

$app->pipe('/', MiddlewareDispatch::factory(require '../bar/config/route.php'));

$app->pipe('/', MiddlewareDispatch::factory(require '../baz/config/route.php'));

Of course, we can have some components that facilitates the management of configuration files, instanciate a service manager if you want, etc, but the main idea of reusability is already there.

Regards,

Enrico Zimuel

On Tue, Jun 16, 2015 at 4:41 PM, Gary Hockin <[hidden email]> wrote:

Hi Enrico,

That's exactly what I'm proposing, it opens up middleware to be more than one namespace this way.

With regards to the module manager, remember, it's only job is to merge config files etc. I'm wondering if we can have the lightweight middleware approach while keeping the epic resuability of modules. I'll do some investigation.

Gary

On Tue, 16 Jun 2015 at 12:36 Enrico Zimuel <[hidden email]> wrote:

Hi Gary,

are you suggesting to collect the 3 folders: /action, /domain, and /template inside a /src or /app ?

\app\action

\app\domain

\app\template

\config

\public

\test

If this is not your idea, can you explain in more detail? 

Regarding the module manager I don't think it makes sense to integrate it for a middleware skeleton like that.

The goal of this middleware skeleton is to have a different architecture, in addition to the MVC, to build web applications. 

In ZF3 we'll have 2 possibility to build web applications or API: Middleware or MVC.

Of course, we can work on a bridge to connect MVC with Middleware (and maybe viceversa), but this is another story.

A middleware component that can route MVC applications based on ZF2, for backward compatibilty?

 

Regards,

Enrico Zimuel

On Tue, Jun 16, 2015 at 10:54 AM, Gary Hockin <[hidden email]> wrote:

Personally...

I don't like the approach of having an "action" and a "domain" folder that is an autoloaded location for "App\Action" and "App\Domain". I don't know what annoys me about this but I suppose that it's we're binding users to one namespace - I'd prefer we allowed flexibility here.

I completely agree that being opinionated is needed to help new users to understand what's going on, but I personally feel that grouping user code in it's own directory would be cleaner. It would also open the door to including the module manager at a later date.

Enrico, would you be open to be doing some work around integrating the module manager please?

Gary

On Tue, 16 Jun 2015 at 07:27 Enrico Zimuel <[hidden email]> wrote:

Hi Ralf,

thanks for your comments, I reply inline.

On Tue, Jun 16, 2015 at 5:47 AM, Ralf Eggert <[hidden email]> wrote:

Hi Enrico,

firstly, like Sascha said, I don't really like interfaces which contain
the constructor for a class.

As I replied to Sascha this was a bad idea, I agree. We can replace it by a setConfig(array $config). 

Then, the installation went very smooth except that a .htaccess was
missing in the public folder to do the mod_rewrite stuff for apache.
With the absence of a .htaccess the /page route does not work. If you
don't want to bind the project to a specific webserver you should at
least document the absence of the .htaccess.

You right, I forgot it :)

I will add a specific .htaccess and I'll update the README with a mini how-to for .nginx and even IIS.

 

Next, I wonder why you checked in the composer.lock file. Just by
mistake or for a deeper sense?

It's not a mistake, composer.lock should be put under version control for applications because it simplifies the management and deployment phase.

Without the composer.lock when you do a "composer install" you can get a different version of the vendor library, because some libraries can have more recent version.

The composer.lock file is the only way to be sure to reuse the exact same version.

Imagine you have a 1.* version specified in composer and you develop against 1.1.4. If you pass your application to another user with composer.lock and the user executes a composer install, he will get the same version 1.1.4, even if even 1.2 has been released in the meantime.

A skeleton project is de facto a starter of an application, that means composer.lock should be part of the skeleton.

We applied this practice also to ZendSkeletonApplication and zf-apigility-skeleton.

 

Finally, I wonder why you use the Plates template system. I never heard
of it before. It looks very lightweight but I really wonder why
Zend\View is not used at all. Maybe due to its complexity? Maybe we need
a lightweight alternative for Zend\View as well?

I used Plates because it supports template using just PHP, no external template language. It's very simple and light and it's a perfect fit for this skeleton use case.

Zend\View is quite complex, it requires the EventManager and it's quite coupled with the MVC logic.

This is also the reason because I choose to term "Template" instead of "View" to differentiate it against Zend\View.

I don't think we need to implement a new light template system in Zend, we can use an external component like Plates, we don't want to reinvent the wheel.

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

[Spabby]

Superb!

I didn't realise I could add routes within middleware, thanks Enrico.

G

On Wed, 17 Jun 2015 at 16:06 Enrico Zimuel <[hidden email]> wrote:

Hi Gary,

actually, using a middleware approach the need of a module manager is not so relevant, let me explain with an example.

Suppose we have a ZF2 application that consumes three modules Foo, Bar and Baz. We can have an application.config.php that looks like that:

return array(
    'modules' => array(
        'Foo',

        'Bar',

        'Baz'
    ),

    // ...
);

In our stratigility solution this is equivalent to a simple pipe of 3 middleware "modules":

$app = new MiddlewarePipe();
$app->pipe('/', MiddlewareDispatch::factory(require '../foo/config/route.php'));

$app->pipe('/', MiddlewareDispatch::factory(require '../bar/config/route.php'));

$app->pipe('/', MiddlewareDispatch::factory(require '../baz/config/route.php'));

Of course, we can have some components that facilitates the management of configuration files, instanciate a service manager if you want, etc, but the main idea of reusability is already there.

Regards,

Enrico Zimuel

On Tue, Jun 16, 2015 at 4:41 PM, Gary Hockin <[hidden email]> wrote:

Hi Enrico,

That's exactly what I'm proposing, it opens up middleware to be more than one namespace this way.

With regards to the module manager, remember, it's only job is to merge config files etc. I'm wondering if we can have the lightweight middleware approach while keeping the epic resuability of modules. I'll do some investigation.

Gary

On Tue, 16 Jun 2015 at 12:36 Enrico Zimuel <[hidden email]> wrote:

Hi Gary,

are you suggesting to collect the 3 folders: /action, /domain, and /template inside a /src or /app ?

\app\action

\app\domain

\app\template

\config

\public

\test

If this is not your idea, can you explain in more detail? 

Regarding the module manager I don't think it makes sense to integrate it for a middleware skeleton like that.

The goal of this middleware skeleton is to have a different architecture, in addition to the MVC, to build web applications. 

In ZF3 we'll have 2 possibility to build web applications or API: Middleware or MVC.

Of course, we can work on a bridge to connect MVC with Middleware (and maybe viceversa), but this is another story.

A middleware component that can route MVC applications based on ZF2, for backward compatibilty?

 

Regards,

Enrico Zimuel

On Tue, Jun 16, 2015 at 10:54 AM, Gary Hockin <[hidden email]> wrote:

Personally...

I don't like the approach of having an "action" and a "domain" folder that is an autoloaded location for "App\Action" and "App\Domain". I don't know what annoys me about this but I suppose that it's we're binding users to one namespace - I'd prefer we allowed flexibility here.

I completely agree that being opinionated is needed to help new users to understand what's going on, but I personally feel that grouping user code in it's own directory would be cleaner. It would also open the door to including the module manager at a later date.

Enrico, would you be open to be doing some work around integrating the module manager please?

Gary

On Tue, 16 Jun 2015 at 07:27 Enrico Zimuel <[hidden email]> wrote:

Hi Ralf,

thanks for your comments, I reply inline.

On Tue, Jun 16, 2015 at 5:47 AM, Ralf Eggert <[hidden email]> wrote:

Hi Enrico,

firstly, like Sascha said, I don't really like interfaces which contain
the constructor for a class.

As I replied to Sascha this was a bad idea, I agree. We can replace it by a setConfig(array $config). 

Then, the installation went very smooth except that a .htaccess was
missing in the public folder to do the mod_rewrite stuff for apache.
With the absence of a .htaccess the /page route does not work. If you
don't want to bind the project to a specific webserver you should at
least document the absence of the .htaccess.

You right, I forgot it :)

I will add a specific .htaccess and I'll update the README with a mini how-to for .nginx and even IIS.

 

Next, I wonder why you checked in the composer.lock file. Just by
mistake or for a deeper sense?

It's not a mistake, composer.lock should be put under version control for applications because it simplifies the management and deployment phase.

Without the composer.lock when you do a "composer install" you can get a different version of the vendor library, because some libraries can have more recent version.

The composer.lock file is the only way to be sure to reuse the exact same version.

Imagine you have a 1.* version specified in composer and you develop against 1.1.4. If you pass your application to another user with composer.lock and the user executes a composer install, he will get the same version 1.1.4, even if even 1.2 has been released in the meantime.

A skeleton project is de facto a starter of an application, that means composer.lock should be part of the skeleton.

We applied this practice also to ZendSkeletonApplication and zf-apigility-skeleton.

 

Finally, I wonder why you use the Plates template system. I never heard
of it before. It looks very lightweight but I really wonder why
Zend\View is not used at all. Maybe due to its complexity? Maybe we need
a lightweight alternative for Zend\View as well?

I used Plates because it supports template using just PHP, no external template language. It's very simple and light and it's a perfect fit for this skeleton use case.

Zend\View is quite complex, it requires the EventManager and it's quite coupled with the MVC logic.

This is also the reason because I choose to term "Template" instead of "View" to differentiate it against Zend\View.

I don't think we need to implement a new light template system in Zend, we can use an external component like Plates, we don't want to reinvent the wheel.

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

[Ralf Eggert]

Hi Enrico,

thanks for clarification about the composer.lock file. I really wasn't
aware of that. But now I will know and remember.

Also thanks for the background of choosing Plates. Yes, Zend\View is
quite big because of the coupling to Zend\Mvc and Zend\EventManager.
Maybe in the future Zend\View could be decoupled further to make much
more lightweight. Since Zend\View has its own release cycle now it might
be possible.

Thanks and best regards,

Ralf

[Mike Willbanks]

Hello Enrico,

On Mon, Jun 15, 2015 at 9:07 AM, Enrico Zimuel <[hidden email]> wrote:

Hi all,

i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:

https://github.com/ezimuel/zend-stratigility-skeleton

I am going to take a look at this over the next couple of days.  I have some existing items to port and we're going down a semi-compatible trail...

 

I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:

https://github.com/ezimuel/zend-stratigility-dispatch

The goal of this skeleton application is to give a minimum infrastructure to be able to build simple web applications using middleware, compliant with PSR-7. I used the architecture proposal of Action-Domain-Responder (an MVC like approach explained here http://pmjones.io/adr/).

The idea is to have actions (inside the /action folder) that can be executed by the dispatcher using a simple configuration file (/config/route.php). In the skeleton, the dependencies of the action are managed using Factories. In the configuration file we used the factories directly, e.g. App\Action\HomepageFactory::factory.

This is just an example, you can use also different methods, for instance using a closure inside the configuration file:

'action' => function($request, $response, $next) {

    $user = new App\Domain\User(); 

    $page = new App\Action\Foo($user);

    return $page->action($request, $response, $next);

}

I'm not a huge fan of this pattern.  I far prefer a few various things:

1. Move all of the application logic to a folder called "app" this is generally fairly common for things like express.js and the like.

2. I'm not a fan of how the actions work, I far prefer a class being initialized and a method called (aka FooController::barAction) it makes things much more clean.  In addition, working and hooking in the Service Manager or a Container (such as League Container) would make a ton of sense.  This gets to the comment below...

 

Or using object from a Container, using the setContainer() method, see example here:

https://github.com/ezimuel/zend-stratigility-dispatch#using-a-container

This is pretty much what I do think is useful; however, as per our prior conversion we really need to the the interop for Service Manager to make this more useful.

 

Let me know what do you think about this skeleton proposal.

A few things that IMO are lacking:

1. We should ideally have Service Manager or a Container implementation setup for the skeleton application showing more of a DI / Service Locator as best practice.

2. Template directory should have more depth - aka views and/or templates are generally different things.  In addition there would likely be more structure around views.

A few things that I think are great:

1. The use of plates (I far prefer that for a view library than just about anything else out there).  However, we should look at how we might be able to place these types of things into an interop factory of sorts (so people that want Zend\View can utilize it).

 

Thanks!

Regards,

Enrico Zimuel

--

Enrico Zimuel
Senior Software Engineer | [hidden email]
Apigility Team           | http://apigility.org
Zend Framework Team      | http://framework.zend.com
Zend Technologies Ltd.
http://www.zend.com

[Enrico Zimuel-2]

Hi Mike,

On Thu, Jun 18, 2015 at 8:10 AM, Mike Willbanks <[hidden email]> wrote:

Hello Enrico,

On Mon, Jun 15, 2015 at 9:07 AM, Enrico Zimuel <[hidden email]> wrote:

Hi all,

i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:

https://github.com/ezimuel/zend-stratigility-skeleton

I am going to take a look at this over the next couple of days.  I have some existing items to port and we're going down a semi-compatible trail...

I'm going to push some changes today, incorporating some feedback hat I got here and on IRC.

 

 

I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:

https://github.com/ezimuel/zend-stratigility-dispatch

The goal of this skeleton application is to give a minimum infrastructure to be able to build simple web applications using middleware, compliant with PSR-7. I used the architecture proposal of Action-Domain-Responder (an MVC like approach explained here http://pmjones.io/adr/).

The idea is to have actions (inside the /action folder) that can be executed by the dispatcher using a simple configuration file (/config/route.php). In the skeleton, the dependencies of the action are managed using Factories. In the configuration file we used the factories directly, e.g. App\Action\HomepageFactory::factory.

This is just an example, you can use also different methods, for instance using a closure inside the configuration file:

'action' => function($request, $response, $next) {

    $user = new App\Domain\User(); 

    $page = new App\Action\Foo($user);

    return $page->action($request, $response, $next);

}

I'm not a huge fan of this pattern.  I far prefer a few various things:

1. Move all of the application logic to a folder called "app" this is generally fairly common for things like express.js and the like.

2. I'm not a fan of how the actions work, I far prefer a class being initialized and a method called (aka FooController::barAction) it makes things much more clean.  In addition, working and hooking in the Service Manager or a Container (such as League Container) would make a ton of sense.  This gets to the comment below...

I'm moving the application into a /app folder, that contains /config, /template and /src (where the source code lives, actions, models, etc).

The usage of anonymous function is only one possible way, think about API, this can be a very common use case.

I would like to present different approaches to consume the MiddlewareDispatch. I think the container is a good option, but I don't think we need to focus only on it.

We already support it via setContainer() and this is a very simple and general solution.

As I said, I would like to open the usage of zend-stratigility and zend-stratigility-dispatch outside the Zend Framework family, so I think to be more open as possible is the right strategy here.

 

Or using object from a Container, using the setContainer() method, see example here:

https://github.com/ezimuel/zend-stratigility-dispatch#using-a-container

This is pretty much what I do think is useful; however, as per our prior conversion we really need to the the interop for Service Manager to make this more useful.

 

Let me know what do you think about this skeleton proposal.

A few things that IMO are lacking:

1. We should ideally have Service Manager or a Container implementation setup for the skeleton application showing more of a DI / Service Locator as best practice.

I agree, we need to write a specific example for that.

 

2. Template directory should have more depth - aka views and/or templates are generally different things.  In addition there would likely be more structure around views.

I don't think this is really necessary. I don't want to force people to use specific folder structure or components. The main goal here is simplicity and performance.

I think using a template system like Plates with a simple folder management is simple and powerful enough (if people wants to differentiate between template and view they can create separate folder if they want, not a bid deal).

A few things that I think are great:

1. The use of plates (I far prefer that for a view library than just about anything else out there).  However, we should look at how we might be able to place these types of things into an interop factory of sorts (so people that want Zend\View can utilize it).

I don't know if Zend\View will be compatible with such middleware skeleton proposal because I'm not 100% sure that this will make sense. Anyway, this is not a priority at the moment, we have Plates that works very well and is very simple to use. We can promote it for our middleware skeleton scenarios.

Thanks for your feedback!

Regards,

Enrico Zimuel

--

[Stefano Torresi-2]

Hello Enrico, hello list,

I while ago (during PSR-7 first vote) I've discussed in #zftalk the possibility to reimagine the MVC event cycle as a middleware pipe cycle, i.e. an event fires at each middleware execution.

Would you consider something like a MiddlewareEvent so that one could alter the behaviour of the pipe at runtime? I reckon this would probably entail a decoration of the default MiddlewarePipe implementation, but this could open interesting options for the future interoperability between Stratigility and Zend\Mvc (thinking about cross-compatible event listeners).

Let me know if you find the idea intriguing.

Regards

P.S.
Apologies if this message arrived twice, apparently google has changed once more how it handles return paths for aliases, so the first message doesn't appear to have been delivered to the list.

[Mike Willbanks]

Hello Stefano,

On Thu, Jun 18, 2015 at 4:36 AM, Stefano Torresi <[hidden email]> wrote:

Hello Enrico, hello list,

I while ago (during PSR-7 first vote) I've discussed in #zftalk the possibility to reimagine the MVC event cycle as a middleware pipe cycle, i.e. an event fires at each middleware execution.

Would you consider something like a MiddlewareEvent so that one could alter the behaviour of the pipe at runtime? I reckon this would probably entail a decoration of the default MiddlewarePipe implementation, but this could open interesting options for the future interoperability between Stratigility and Zend\Mvc (thinking about cross-compatible event listeners).

I was thinking about something among these lines, the difficult aspect of this is that firing so many events can start to lead to performance implications.  However, MiddlewarePipe could take on an extended role such as MiddlewareEventPipe and so on.  This would then fire events that would be able to hook at different aspects of the middleware.  

 

Let me know if you find the idea intriguing.

Regards

P.S.
Apologies if this message arrived twice, apparently google has changed once more how it handles return paths for aliases, so the first message doesn't appear to have been delivered to the list.