Proposal for a PSR-7 middleware skeleton application

[Enrico Zimuel-2]

Hi All,

i just updated the zend-stratigility-dispatch (https://github.com/ezimuel/zend-stratigility-dispatch) and zend-stratigility-skeleton (https://github.com/ezimuel/zend-stratigility-skeleton) proposals with some of the feedbacks collected in the list, in particular:

For zend-stratigility-dispatch:

- removed the constructor in the RouterInterface in favor of setConfig(array $config) and getConfig() methods.

For zend-stratigility-skeleton:

- changed the folder structure of the skeleton in favor of:

/app (the root folder of the application)

/app/config (the configuration folder)

/app/template (the template folder)

/app/src (the source code of the application, with namespace App\)

/app/src/Action (the action folder, App\Action)

/app/src/Model (the model folder, App\Model)

/public (the public folder)

/test (the unit test folder)

This new folder structure looks better, because all the application is inside the /app folder.

I also renamed the domain folder with model.

- added the .htaccess in public

- added the apache and nginx virtual host configuration in README.md

- updated the README.md with more details about the middleware architecture

- renamed the template.php file with layout.php

Regards,

Enrico Zimuel

On Thu, Jun 18, 2015 at 2:00 PM, Mike Willbanks <[hidden email]> wrote:

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.

--

[Sascha-Oliver Prolic]

Hi Enrico,

you should either move test to app, or have test/app. But test/Action is not as clean.

Again I like to say, that having action-domain-responder should be another project, not part of the middleware skeleton.

Best Regards

Sascha

2015-06-18 17:54 GMT+02:00 Enrico Zimuel <[hidden email]>:

Hi All,

i just updated the zend-stratigility-dispatch (https://github.com/ezimuel/zend-stratigility-dispatch) and zend-stratigility-skeleton (https://github.com/ezimuel/zend-stratigility-skeleton) proposals with some of the feedbacks collected in the list, in particular:

For zend-stratigility-dispatch:

- removed the constructor in the RouterInterface in favor of setConfig(array $config) and getConfig() methods.

For zend-stratigility-skeleton:

- changed the folder structure of the skeleton in favor of:

/app (the root folder of the application)

/app/config (the configuration folder)

/app/template (the template folder)

/app/src (the source code of the application, with namespace App\)

/app/src/Action (the action folder, App\Action)

/app/src/Model (the model folder, App\Model)

/public (the public folder)

/test (the unit test folder)

This new folder structure looks better, because all the application is inside the /app folder.

I also renamed the domain folder with model.

- added the .htaccess in public

- added the apache and nginx virtual host configuration in README.md

- updated the README.md with more details about the middleware architecture

- renamed the template.php file with layout.php

Regards,

Enrico Zimuel

On Thu, Jun 18, 2015 at 2:00 PM, Mike Willbanks <[hidden email]> wrote:

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.

--

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]

Sorry, I replied only to Sascha, forwarding to the list:

---------- Forwarded message ----------
From: Enrico Zimuel <[hidden email]>
Date: Thu, Jun 18, 2015 at 6:07 PM
Subject: Re: [zf-contributors] Proposal for a PSR-7 middleware skeleton application
To: Sascha-Oliver Prolic <[hidden email]>

Hi Sascha,

On Thu, Jun 18, 2015 at 5:59 PM, Sascha-Oliver Prolic <[hidden email]> wrote:

Hi Enrico,

you should either move test to app, or have test/app. But test/Action is not as clean.

I don't like that proposal because I would like to have separate root folders for the source code and for the test itself.

You should think at the /app folder as the module Application of a ZF2 app.

 

Again I like to say, that having action-domain-responder should be another project, not part of the middleware skeleton.

I'm not doing any of particular architecture set here, and btw I don't mention anymore the action-domain-responser term in the README.md.

The Action folder is only a directory that contains the code to be executed against a matched route and the Model is an empty folder that will contain the business logic, if any.

This is just a proposal, you can change it as you want, everything will continue to work. You need to change only the paths of the configuration files and the namespace of the actions, that's it.

I proposed this tree structure primarily as basic guide for beginners.

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]

league/plates is a beautiful template system but I see this choice as a defeat to Zend\View :) 

This component has this features but for a design problem it's not reusable could we try to think a good way to refactor this component?

Into the Zend Framework ecosystem a good template system is necessary IMO, we can try to move off this section to use it into the middleware and into MVC app..

2015-06-18 17:48 GMT+02:00 Enrico Zimuel-2 [via Zend Framework Community] <[hidden email]>:

Sorry, I replied only to Sascha, forwarding to the list:

---------- Forwarded message ----------
From: Enrico Zimuel <[hidden email]>
Date: Thu, Jun 18, 2015 at 6:07 PM
Subject: Re: [zf-contributors] Proposal for a PSR-7 middleware skeleton application
To: Sascha-Oliver Prolic <[hidden email]>

Hi Sascha,

On Thu, Jun 18, 2015 at 5:59 PM, Sascha-Oliver Prolic <[hidden email]> wrote:

Hi Enrico,

you should either move test to app, or have test/app. But test/Action is not as clean.

I don't like that proposal because I would like to have separate root folders for the source code and for the test itself.

You should think at the /app folder as the module Application of a ZF2 app.

 

Again I like to say, that having action-domain-responder should be another project, not part of the middleware skeleton.

I'm not doing any of particular architecture set here, and btw I don't mention anymore the action-domain-responser term in the README.md.

The Action folder is only a directory that contains the code to be executed against a matched route and the Model is an empty folder that will contain the business logic, if any.

This is just a proposal, you can change it as you want, everything will continue to work. You need to change only the paths of the configuration files and the namespace of the actions, that's it.

I proposed this tree structure primarily as basic guide for beginners.

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

---

If you reply to this email, your message will be added to the discussion below:

http://zend-framework-community.634137.n4.nabble.com/Proposal-for-a-PSR-7-middleware-skeleton-application-tp4662563p4662585.html

To start a new topic under ZF Contributor, email [hidden email]
To unsubscribe from Zend Framework Community, click here.
NAML

--

[GianArb]

league/plates is a beautiful template system but I see this choice as a defeat to Zend\View :) 

This component has this features but for a design problem it's not reusable could we try to think a good way to refactor this component?

Into the Zend Framework ecosystem a good template system is necessary IMO, we can try to move off this section to use it into the middleware and into MVC app..

2015-06-18 18:08 GMT+02:00 Enrico Zimuel <[hidden email]>:

Sorry, I replied only to Sascha, forwarding to the list:

---------- Forwarded message ----------
From: Enrico Zimuel <[hidden email]>
Date: Thu, Jun 18, 2015 at 6:07 PM
Subject: Re: [zf-contributors] Proposal for a PSR-7 middleware skeleton application
To: Sascha-Oliver Prolic <[hidden email]>

Hi Sascha,

On Thu, Jun 18, 2015 at 5:59 PM, Sascha-Oliver Prolic <[hidden email]> wrote:

Hi Enrico,

you should either move test to app, or have test/app. But test/Action is not as clean.

I don't like that proposal because I would like to have separate root folders for the source code and for the test itself.

You should think at the /app folder as the module Application of a ZF2 app.

 

Again I like to say, that having action-domain-responder should be another project, not part of the middleware skeleton.

I'm not doing any of particular architecture set here, and btw I don't mention anymore the action-domain-responser term in the README.md.

The Action folder is only a directory that contains the code to be executed against a matched route and the Model is an empty folder that will contain the business logic, if any.

This is just a proposal, you can change it as you want, everything will continue to work. You need to change only the paths of the configuration files and the namespace of the actions, that's it.

I proposed this tree structure primarily as basic guide for beginners.

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 Gianluca,

On Thu, Jun 18, 2015 at 8:28 PM, Gianluca Arbezzano <[hidden email]> wrote:

league/plates is a beautiful template system but I see this choice as a defeat to Zend\View :) 

Zend\View is not a defeat, absolutely not. It's a robust view manager component designed for an MVC architecture, that's it.

Here, we are discussing about a new approach to build web applications in PHP using a different pattern, the middleware.

 

This component has this features but for a design problem it's not reusable could we try to think a good way to refactor this component?

It's not a design problem, it was a design choice, it's different.

Of course, we can think to refactor this in favor of alternative solution but why we need to do that now?

We have a solution, using Plates that works just fine. We have more interesting problems to solve at the moment.

We should try to invest our energy to really help PHP developers with something new or better.

If we identify an open source component that works great with our zend-* we should use it, we don't want to reinvent the wheel.

 

Into the Zend Framework ecosystem a good template system is necessary IMO, we can try to move off this section to use it into the middleware and into MVC app..

We can, but as I said I think this is not a priority at the moment.

Moreover, Plates uses a pure PHP syntax in the views so should not be so difficult to change it in favor of a new zend-view like component.

 

Regards,

Enrico Zimuel

--

[Ismael]

Hi,

sorry for the offtopic, but please can anyone tell me where I can learn about midleware pattern and in which conditions it is more suitable than the MVC?

Thank you in advance,
ismael trascastro

El vie, 19 de junio de 2015 07:51 AM, Enrico Zimuel <[hidden email]> escribió:

Hi Gianluca,

On Thu, Jun 18, 2015 at 8:28 PM, Gianluca Arbezzano <[hidden email]> wrote:

league/plates is a beautiful template system but I see this choice as a defeat to Zend\View :) 

Zend\View is not a defeat, absolutely not. It's a robust view manager component designed for an MVC architecture, that's it.

Here, we are discussing about a new approach to build web applications in PHP using a different pattern, the middleware.

 

This component has this features but for a design problem it's not reusable could we try to think a good way to refactor this component?

It's not a design problem, it was a design choice, it's different.

Of course, we can think to refactor this in favor of alternative solution but why we need to do that now?

We have a solution, using Plates that works just fine. We have more interesting problems to solve at the moment.

We should try to invest our energy to really help PHP developers with something new or better.

If we identify an open source component that works great with our zend-* we should use it, we don't want to reinvent the wheel.

 

Into the Zend Framework ecosystem a good template system is necessary IMO, we can try to move off this section to use it into the middleware and into MVC app..

We can, but as I said I think this is not a priority at the moment.

Moreover, Plates uses a pure PHP syntax in the views so should not be so difficult to change it in favor of a new zend-view like component.

 

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 Ismael,

we started to work on a middleware skeleton proposal after the PSR-7 standard, that defines common interfaces for HTTP request and response.

The main idea of middleware and PSR-7 is covered in this Matthew's blog post: https://mwop.net/blog/2015-01-08-on-http-middleware-and-psr-7.html

The main idea is that you can inject (pipe) different middleware in a chain and create your specific workflow.

The real advantage, in my opinion, is the simplicity of the architecture and the good reusability of code.

The middleware architecture can be used in any use case, even complex scenarios. 

That said, the examples that I've seen so far in PHP are for API development and simple web application.

I'm sure we'll see more examples in the future, even complex site built using middleware in PHP.

Regards,

Enrico Zimuel

On Fri, Jun 19, 2015 at 10:57 AM, Ismael <[hidden email]> wrote:

Hi,

sorry for the offtopic, but please can anyone tell me where I can learn about midleware pattern and in which conditions it is more suitable than the MVC?

Thank you in advance,
ismael trascastro

El vie, 19 de junio de 2015 07:51 AM, Enrico Zimuel <[hidden email]> escribió:

Hi Gianluca,

On Thu, Jun 18, 2015 at 8:28 PM, Gianluca Arbezzano <[hidden email]> wrote:

league/plates is a beautiful template system but I see this choice as a defeat to Zend\View :) 

Zend\View is not a defeat, absolutely not. It's a robust view manager component designed for an MVC architecture, that's it.

Here, we are discussing about a new approach to build web applications in PHP using a different pattern, the middleware.

 

This component has this features but for a design problem it's not reusable could we try to think a good way to refactor this component?

It's not a design problem, it was a design choice, it's different.

Of course, we can think to refactor this in favor of alternative solution but why we need to do that now?

We have a solution, using Plates that works just fine. We have more interesting problems to solve at the moment.

We should try to invest our energy to really help PHP developers with something new or better.

If we identify an open source component that works great with our zend-* we should use it, we don't want to reinvent the wheel.

 

Into the Zend Framework ecosystem a good template system is necessary IMO, we can try to move off this section to use it into the middleware and into MVC app..

We can, but as I said I think this is not a priority at the moment.

Moreover, Plates uses a pure PHP syntax in the views so should not be so difficult to change it in favor of a new zend-view like component.

 

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

--

[jesus vieira]

Hello!

I noticed that you are using the template "plates" Will not it would be better to use the "twig", to be more popular and have extensive documentation and examples on the internet?

2015-06-19 6:49 GMT-03:00 Enrico Zimuel <[hidden email]>:

Hi Ismael,

we started to work on a middleware skeleton proposal after the PSR-7 standard, that defines common interfaces for HTTP request and response.

The main idea of middleware and PSR-7 is covered in this Matthew's blog post: https://mwop.net/blog/2015-01-08-on-http-middleware-and-psr-7.html

The main idea is that you can inject (pipe) different middleware in a chain and create your specific workflow.

The real advantage, in my opinion, is the simplicity of the architecture and the good reusability of code.

The middleware architecture can be used in any use case, even complex scenarios. 

That said, the examples that I've seen so far in PHP are for API development and simple web application.

I'm sure we'll see more examples in the future, even complex site built using middleware in PHP.

Regards,

Enrico Zimuel

On Fri, Jun 19, 2015 at 10:57 AM, Ismael <[hidden email]> wrote:

Hi,

sorry for the offtopic, but please can anyone tell me where I can learn about midleware pattern and in which conditions it is more suitable than the MVC?

Thank you in advance,
ismael trascastro

El vie, 19 de junio de 2015 07:51 AM, Enrico Zimuel <[hidden email]> escribió:

Hi Gianluca,

On Thu, Jun 18, 2015 at 8:28 PM, Gianluca Arbezzano <[hidden email]> wrote:

league/plates is a beautiful template system but I see this choice as a defeat to Zend\View :) 

Zend\View is not a defeat, absolutely not. It's a robust view manager component designed for an MVC architecture, that's it.

Here, we are discussing about a new approach to build web applications in PHP using a different pattern, the middleware.

 

This component has this features but for a design problem it's not reusable could we try to think a good way to refactor this component?

It's not a design problem, it was a design choice, it's different.

Of course, we can think to refactor this in favor of alternative solution but why we need to do that now?

We have a solution, using Plates that works just fine. We have more interesting problems to solve at the moment.

We should try to invest our energy to really help PHP developers with something new or better.

If we identify an open source component that works great with our zend-* we should use it, we don't want to reinvent the wheel.

 

Into the Zend Framework ecosystem a good template system is necessary IMO, we can try to move off this section to use it into the middleware and into MVC app..

We can, but as I said I think this is not a priority at the moment.

Moreover, Plates uses a pure PHP syntax in the views so should not be so difficult to change it in favor of a new zend-view like component.

 

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 Jesus,

I choose Plates because it's very simple, fast and it uses the PHP syntax as template language, very similar to what we did with Zend\View.

Anyway, this is just a proposal for a skeleton, you can use the template language that you want. 

My skeleton proposal is template agnostic, the basic components zend-stratigility and zend-stratigility-dispatch and not related to a specific template engine. 

You can render the output from the actions, using the library/mechanism that you want.

Regards,

Enrico Zimuel

On Tue, Jun 23, 2015 at 1:14 PM, jesus vieira <[hidden email]> wrote:

Hello!

I noticed that you are using the template "plates" Will not it would be better to use the "twig", to be more popular and have extensive documentation and examples on the internet?

2015-06-19 6:49 GMT-03:00 Enrico Zimuel <[hidden email]>:

Hi Ismael,

we started to work on a middleware skeleton proposal after the PSR-7 standard, that defines common interfaces for HTTP request and response.

The main idea of middleware and PSR-7 is covered in this Matthew's blog post: https://mwop.net/blog/2015-01-08-on-http-middleware-and-psr-7.html

The main idea is that you can inject (pipe) different middleware in a chain and create your specific workflow.

The real advantage, in my opinion, is the simplicity of the architecture and the good reusability of code.

The middleware architecture can be used in any use case, even complex scenarios. 

That said, the examples that I've seen so far in PHP are for API development and simple web application.

I'm sure we'll see more examples in the future, even complex site built using middleware in PHP.

Regards,

Enrico Zimuel

On Fri, Jun 19, 2015 at 10:57 AM, Ismael <[hidden email]> wrote:

Hi,

sorry for the offtopic, but please can anyone tell me where I can learn about midleware pattern and in which conditions it is more suitable than the MVC?

Thank you in advance,
ismael trascastro

El vie, 19 de junio de 2015 07:51 AM, Enrico Zimuel <[hidden email]> escribió:

Hi Gianluca,

On Thu, Jun 18, 2015 at 8:28 PM, Gianluca Arbezzano <[hidden email]> wrote:

league/plates is a beautiful template system but I see this choice as a defeat to Zend\View :) 

Zend\View is not a defeat, absolutely not. It's a robust view manager component designed for an MVC architecture, that's it.

Here, we are discussing about a new approach to build web applications in PHP using a different pattern, the middleware.

 

This component has this features but for a design problem it's not reusable could we try to think a good way to refactor this component?

It's not a design problem, it was a design choice, it's different.

Of course, we can think to refactor this in favor of alternative solution but why we need to do that now?

We have a solution, using Plates that works just fine. We have more interesting problems to solve at the moment.

We should try to invest our energy to really help PHP developers with something new or better.

If we identify an open source component that works great with our zend-* we should use it, we don't want to reinvent the wheel.

 

Into the Zend Framework ecosystem a good template system is necessary IMO, we can try to move off this section to use it into the middleware and into MVC app..

We can, but as I said I think this is not a priority at the moment.

Moreover, Plates uses a pure PHP syntax in the views so should not be so difficult to change it in favor of a new zend-view like component.

 

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

--

JESUS VIEIRA
Programador back-end

http://cursozendframework.com.br/

--