Controllers and workflow February 13, 2014, 07:33:06 pm Okay, this is just one of my usual "destroy everything" things.A few days ago I started working on move the debugging to a static class (just bored and looking for something to do to clean up a bit):https://github.com/emanuele45/Dialogo/tree/debugIn the meantime, my brain was thinking that the dispatcher could do something more... or something different, but I was not sure how and what.This evening, I got an idea and I wrote down a couple of commits. In particular, the more relevant are:https://github.com/emanuele45/Dialogo/commit/fe52ee4699cfd74c61ea6c073f89f000636a11e5https://github.com/emanuele45/Dialogo/commit/5e45853b71d4e8a0826d7f18a4498883f0b04126just because they explain and demonstrate the general idea.What is the general idea?Well, each controller returns an object, it may be a "page" that should be rendered, it may be a "redirect", or a fatal error, or whatever, and index.php takes this object and execute a standard method (doExit in this case) and ends the script.https://github.com/emanuele45/Dialogo/blob/debug/index.php#L154The dispatcher returns the object,https://github.com/emanuele45/Dialogo/blob/debug/index.php#L161doExit is executed.For example if the dispatcher returns a page, this is the class that should be used:https://github.com/emanuele45/Dialogo/blob/debug/sources/Page.class.phpif it is what now is a redirectexit, instead it would be an object created from the class:https://github.com/emanuele45/Dialogo/blob/debug/sources/Redirect.class.phpAt the moment the branch is badly broken, I think it barely works on basic aspects, it still need a lot of refactoring and moving around things, though I'd like to hear some feedback from those with more knowledge of OOP.The main goal would be to reduce the number of exit points ideally to 1 (in index.php) compared to the ~50 obExit calls that are currently present in the code.Does it make sense?Am I on the good track? Or completely out of track?Comments/suggestions/critiques, everything is welcome!
Re: Controllers and workflow Reply #1 – February 13, 2014, 07:58:55 pm Yes! You're on the right track! That's what the controller should do. Calls the "action" and then the action returns the parameters to the main/front controller. The main controller then sends that to the view.Some links for ideas. You can even just use the httpfoundation component from Symfonyhttp://symfony.com/doc/current/components/http_foundation/introduction.htmlhttp://api.symfony.com/2.4/Symfony/Component/HttpFoundation/Response.htmlhttp://api.symfony.com/2.4/Symfony/Component/HttpFoundation/RedirectResponse.htmlhttp://api.symfony.com/2.4/Symfony/Component/HttpFoundation/JsonResponse.htmlZend has the same thinghttp://framework.zend.com/manual/2.2/en/modules/zend.mvc.intro.htmlI'm sure every framework does the same thing in a similar way.Side note - this is cool - http://framework.zend.com/manual/2.2/en/modules/zend.json.introduction.html
Re: Controllers and workflow Reply #2 – February 14, 2014, 05:54:24 am YAY!I got that one right! Then I'll continue with that branch, it will require quite a lot of work to finish, but I suppose it's well worth! I dunno (yet) what will be the final result, at the moment the way I chose is to "move things around" trying to make them look better (for example the debugging to a static class, that is a prelude for something more in the future), then when I notice something that can be overhauled[1] I change it.1 Remembering that 1.1 should be 1.0 compatible. And for example the debug class is not yet backward-compat, even though I feel this is not something so important since debug is usually present only in core, it's difficult that addons/mod would use the debug...I hope ↵
Re: Controllers and workflow Reply #3 – February 14, 2014, 07:52:23 am Don't put it in a static class. Pass it to the classes that will use it in the constructor. You should really take this opportunity to create a DIC. Even if it is just a simple array. Then use that to hold the instance of the debugger. You can make it a singleton, but I don't think it is good to make it static.Oh, and the debugger should be a separate thing from logging. Since everyone is moving this way, the debugger should implement PSR-3 so that you can change out the logging easily.The debugger collects a bunch of other data. I think the best way to implement that is by having each class have a custom "DataCollector" (as Symfony calls it - http://symfony.com/doc/current/cookbook/profiler/data_collector.html). Then classes would implement "DataCollectorInterface" when they can supply the debugger with some info. It can either register itself with the debug class or the debug class can iterate the DIC looking for instanceof DataCollectorInterface (or both?).
Re: Controllers and workflow Reply #4 – February 14, 2014, 07:54:59 am PPI (http://www.ppi.io/) pretty much takes what is the best of the major frameworks and creates his own framework. It's built by Paul Dragoonis.
Modern, Free, Powerful