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:
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 |
Hi Enrico, you should either move test to app, or have test/app. But test/Action is not as clean.Sascha-Oliver Prolic 2015-06-18 17:54 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:
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.
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 |
This post has NOT been accepted by the mailing list yet.
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]>:
Gianluca Arbezzano aka GianArb
www.gianarb.it |
In reply to this post by Enrico Zimuel-2
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]>:
Gianluca Arbezzano aka GianArb
www.gianarb.it |
Hi Gianluca,
On Thu, Jun 18, 2015 at 8:28 PM, Gianluca Arbezzano <[hidden email]> wrote:
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.
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.
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 |
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, El vie, 19 de junio de 2015 07:51 AM, Enrico Zimuel <[hidden email]> escribió:
|
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:
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 |
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 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:
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 |
Free forum by Nabble | Edit this page |