|
12
|
Hi all,
i just pushed a proposal for a PSR-7 middleware skeleton application using zend-stratigility:
I used zend-stratigility-dispatch as dispatcher, that is another proposal, available here:
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:
Let me know what do you think about this skeleton proposal. Thanks!
Regards, Enrico Zimuel
|
|
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
|
|
And: Please forget about my diactoros question, it's in the public/index.php of course ! Me, stupid, lol
Best Sascha
|
|
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
|
|
In reply to this post by Sascha-Oliver Prolic
Hi Sascha,
thanks for your comments, I reply inline.
|
|
Hi Ralf,
thanks for your comments, I reply inline.
|
|
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
Hi Ralf,
thanks for your comments, I reply inline.
|
|
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?
Gianluca Arbezzano aka GianArb
www.gianarb.it
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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 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
|
|
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
|
|
Superb!
I didn't realise I could add routes within middleware, thanks Enrico. G 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
|
|
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
|
|
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.
|
12
|