| SitePoint Sponsor |
Well ... how often do you actually need that ?Originally Posted by Overunner
Anyway - The individual Action could create other Action's and execute them. Like ;
action/multi.php
PHP Code:require_once('action/one.php');
require_once('action/two.php');
class multi
{
function execute(&$request, &$response) {
$one =& new one();
$two =& new two();
$one->execute($request, $response);
$two->execute($request, $response);
}
}
Maybe you're right, I can't actually of too many cases where this would be needed, but I like the idea
Yes, but then you would have to create a new action for every combination of actions you want to execute. If the actions were instead pushed into some kind of an ActionChain and get executed one by one...
Just a thought.PHP Code:class ActionChain
{
var $actions = array();
function register(&$actionInstance)
{
$this->actions[] = $actionInstance;
}
function execute()
{
for ($i = 0; $i = count($this->actions); $i++)
$this->actions[$i]->execute();
}
Anyhow, regarding your code, it doesn't seem good to have markup in the actions. Instead, I think each action should import a template and assign variables to it, thus letting each action be a mini-controller. It would also be an appropriate place to put formvalidation. For instance:
PHP Code:class FooAction extends Action
{
function execute(&$request, &$response)
{
if (isFormValid())
{
$template = new Template('valid.tpl');
$template->assign('result', 'The form has been successfully posted');
$response->setContent($template->getContent());
}
else
{
$template = new Template('invalid.tpl');
$template->assign('result', 'Something bad happened');
$response->setContent($template->getContent());
}
}
}
I recognize that you could find a use for this, but I don't think it would be very common. Anyway - if you should need it, it would be a matter of writing a different RequestMapper, which recognized multiple actions in the request, and then return a Dispatcher like the one you outlined in the above post. You're free to do that.Maybe you're right, I can't actually of too many cases where this would be needed, but I like the idea
Yes, but then you would have to create a new action for every combination of actions you want to execute. If the actions were instead pushed into some kind of an ActionChain and get executed one by one...
Of course. I copied the code from arborint, and I'm sure that the reason why he made it that way, was to focus on the FrontController. Exactly how the Dispatcher (Action) works was irellevant for that matter.
You basically have two choices for how the Dispacther should render a view. Either it uses a Template which it pushes data onto - Just like the example you've shown. This is the TemplateView.
The other way is to simply include a php-file (which is a mix of html and php). This is a DispactherView (aka. ServerPage).
If you look at the first version of the code (in CVS at sf), you can see how I have suggested a simple ServerPage-Dispatcher.
Why have cotten, when you can (just as easily) have silk huh?
Why? Why not just go the whole way, and settle for a controller, whereby that given controller (one of many possible controllers) can have it's own action? In that regard, a given controller in it's self can have one or more actions as well, still.Instead, I think each action should import a template and assign variables to it, thus letting each action be a mini-controller.
I think I had made a comment on this earlier. Think of a dynamically generated Form as you enquire yes?
If you have one or more controllers, you could assign that given controllers (multiple) actions to each part of the Form in question. You may well ask, why would I want to do that? Well, not on every request, for every given visitor who is going to complete that form, well may not need to complete the entire Form, only given parts of it (and I'm not referring to a wizard, step 1.. step 2.. etc type form eitherIt would also be an appropriate place to put formvalidation.).
Hope that makes sense, as there is definitely a need for this. It was a requirement in fact for this framework I'm working on at the moment, why I can't post any script you see, based on this framework.
But at the moment, the implementation is still shaky
Really excellent. I have done a few more little changes. Here are my comments.I don't think it makes it less flexible because the Front Controller implements the Command pattern rather than an interface. All an action object needs to support is the 'execute' method.I agree. It is cleaner and easier to understand without it.Actually no, this is not why I implemented it. I added the Lazy Include when there was a CoR so every dispatcher did not need to be loaded. It is no longer necessary.I don't distinguish for simplicity, but also because don't think it is necessary. The Front Controller dispatches a Commmand, that's all. That Command can be whatever you want. In most cases I think it should be an Application Controller. So I just want to push the dispatcher type decision off onto the Application Controller. I think an Application Controller should do some of the things that your various 'dispatchers' do.Excellent. You have cleaned up the dependency correctly.I agree. It would be easy enough to add. Another option is to implement the Intercepting Filter outside the Front Controller and pass the front controller to it. That would probably be a better choice.I just don't think it is necessary in a Front Controller. As I said above if you want to add an Intercepting Filter do it outside the Front Controller. If you want to do more dispatching then have the Front Controller dispatch an Input/Application Controller.I think things like configuration data and URL generation are better left to some kind of Dependency Injection. We could do a simple Locator class, but something like phemto would be a better solution in the long term.
I did another pass over kyberfabrikken's last code. I made the DefaultMapper work with his changes, I added back he ability to have an external map rather than generated file and class names (thie example_action_map.php file show actions foo and bar reversed) as I think that is important.
You can download the code here skeleton2.3.zip.
Christopher
But how do you 'push' data into the page? Or should the DispatchView be used to render static pages?
I'm not sure if I follow you, but do you suggest that each Action should be a fully fledged controller? And that it too can have 'subactions'?
Sorry but I don't see any reason for this. The actions doesn't need to be that complicated.
I think you are spot on there. This is just the Front Controller. It solves cadmiumgreen's problem by centralizing the running of PHP files based on an action parameter using the DefaultMapper. It will also execute objects as Commands. These objects can be anything you want (so long as they have an 'execute' method) and should be the controllers that actually do the real work of building the response.
It is a "fully fledged controller", whether you like it or not, because that is actually what it does. This point of the code we are building here is to formalize the common parts to you don't have to rewrite them for each page but just focus on the code specific to that page.
Obviously the next step in this process is to do an Input/Application Controller (I have some code that may be a starting place for that). But we should not continue until we agree that this code is OK. I would like people to take a look at the last code I posted, try it out, and say whether it is actually usable (which DougBTX right said should be a more important requirement than simplicity
Christopher
Out of the last 3 code refactorings, I've only looked at the first two, and the second of the two looks in better shape in my view, if that's any help?I would like people to take a look at the last code I posted, try it out,
Downloaded the 3rd refactoring a moment ago, but I'll not be able to take a look at it at the moment.
Yes, exactly what I was suggestingbut do you suggest that each Action should be a fully fledged controller? And that it too can have 'subactions'?You may (think you may) not have a need for this functionality, but trust me, you will at some point in time. Out of all the work I've done with PHP this last 4 months I questioned why?
Why this and why do I -BEEP- need to go and script that... Why? Apart from doing what is asked, I do manage to pick up a few things from the various conversations I've had
Overrunner,
On the point of that example Form I gave yes? It isn't a Wizard style form because (for one example) the various parts involved are not sequencial, but are dependent on the visitor or user.Sorry but I don't see any reason for this. The actions doesn't need to be that complicated.
Now... There coule be any number or types of user, so you now see where I was going with this yes? User A may need parts 1 through to 8, and part 12 and part 13, but user K only needs to complete parts 3, 4 and 5, and depending on a given variable for that given application, they may or may not need to complete part 9 as well
Now mate, that is complexity, and it's a -BEEP- nightmare. This stuff keeps me awake at night
Will this skeleton web controller save development time for the person posting in this thread?
That seems like an important test for any code we write here, imo a typical request that a controller for a web app should be able to help with.
Douglas
Hello World
Actually the skeleton Front Controller will currently dispatch "www.my.com/index.php/foo/" or "www.my.com/foo/" (with mod_rewrite), so yes. All these this are configurable. Just use 'PATH_INFO' as the action parameter like this:I think this URL:PHP Code:$mapper =& new ActionMapper('actions/', 'default', 'PATH_INFO');
$controller =& new FrontController($mapper);
$controller->execute(new Request());
is a very good reason to have a Request class. It would be trivial to parse the raw command line and add values to the request in any scheme you wanted. Your program would work with regular URLs and custom ones without modification. I could easily add support for this if people thought it was a good idea. Perhaps we should to add an optional Decorator to the Request that could be used for this?Code:http://foo.com/samepath/myapp/name1/val1/name2/val2/namen/valn
Christopher
aaah, 2K posts. I think I'll leave you guys to it for a bit, you are scaring me
I'll pop back once I have a couple of projects out of the way: one of which might even be an MVC PHP app; if so, I'll tell you how it went
Douglas
Hello World
I agree! Another reason for having a request class is for re-using a certain application or action as a sub-action where the $_REQUEST variable is not present. If you wanted to re-use a menu application on a certain page but force it to a certain state and it was checking $_GET, than you'd be screwed, but with a request/input class that had a set() method, you could change that parameter and customize. Actually, I think that the class should be called Input and not Request, but that's just me. I know that you could set variables in $_GET (maybe?) but that seems like hacking to me.
- matt
I can't wait for 2001, A Douglas Odysseyaaah, 2K posts. I think I'll leave you guys to it for a bit, you are scaring me
I'll pop back once I have a couple of projects out of the way: one of which might even be an MVC PHP app; if so, I'll tell you how it went
Douglas
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
I think it might take us another 2000 posts to get an Application Controller done! This is already the 5th longest thread ever in this forum and all we have is a tiny Front Controller and a simple Mapper!aaah, 2K posts. I think I'll leave you guys to it for a bit, you are scaring me
I'll pop back once I have a couple of projects out of the way: one of which might even be an MVC PHP app; if so, I'll tell you how it went
Douglas
Christopher
Ah - The point exactly!
TemplateView uses a Controller to push data from the Model, onto the View.
ServerPages pull data directly from the Model. This is why the ServerPage is also called DispatcherView - It combines Dispatcher (~Controller) with View, in one object.
This ofcourse is a violation of the notorious MVC-paradigm, but that's a different story.
Yes, and that's probably why we keep mocking eachother about if we should call the object a Handle, Command, ApplicationController, Action or Dispatcher. I'm quite sure that at least from the FrontController's point of view, we mean the same thing.
Really good point. Though an intercepting filter could serve the same purpose.
Why settle for less than perfection - I expect us to make it to the top.
I'll have a look at the latest iteration, and post back by then. The time-zones mean that this will likely happen before you come back to this forum.
DefaultMapper
I have renamed the DefaultMapper to ServerPageMapper, since this is what it does. Also - I don't like the way you were having the mapper returning itself. It is clearly two different roles, which are mingled into one class. You made a note on this yourself a couple of posts back. I have taken the consequence and seperated them into two different classes.
Error-supression
It is evil. Please.
FrontController
Have a look at the FrontController class. In the line "if (method_exists($dispatcher, 'execute')) {", what you really are doing here, is to check if the returned object has a certain feature. The proper, object-oriented way to do this, is to use an interface, and check if the object implements it. Eg: (pseudo PHP5)
Since we don't have interfaces in php4, we could use an abstract class instead. That's what I did in the first version.PHP Code:interface IDispatcher
{
public function execute(&$request, &$response);
}
class FrontController
{
(...)
function execute(&$request) {
(...)
if ($dispatcher instanceof IDispatcher) {
(...)
}
}
}
A thing that has had me thinking a bit is, that the FrontController gets the Request object passed on, but it creates the Response. This makes it different from all the other controllers, which get's both objects passed. That makes me think that the Response should probably be passed on aswell, or the opposite - that the FrontController should create the Request. What do you think about this ?
ActionMapper
The implementation, you have made gives the ActionMapper two different operation-modes. It may use a dictionary or it may not. I think that this is clearly two different concerns, and that they should therefore be two seperate objects. I know that you are concerned with the number of classes, but I prefer more classes with less responsibility each, than few classes, with two many responsibilities. If I were in a bad mood, I might even use the word bloat.
The mere fact that you have presented two different example-scripts for the two uses, clearly supports my claim.
I have therefore seperated the class ActionMapper into two different classes now. The ActionMapper and the ActionLookupMapper. I suggest that we dispose of the latter, if the need to reduce the number of classes should show ?
I agree with all that kyberfabrikken has said (particullary interfaces in PHP5, it just makes more sense). However, should ActionLookupMapper look more like:
In plain-words, why set all those properties when we inherit them, anyway?PHP Code:<?php
require_once('ActionMapper.php');
class ActionLookupMapper extends ActionMapper
{
var $map = NULL;
function ActionLookupMapper(&$map, $base_path='', $default_action='', $action_param='action') {
parent::ActionMapper($base_path, $default_action, $action_param);
$this->setMap($map);
}
function setMap(&$map) {
$this->map =& $map;
}
function doMapping($action) {
$this->file_name = $this->base_path . $this->map[$action]['file'];
$this->class_name = $this->map[$action]['class'];
$this->data = (isset($this->map[$action]['data'])) ? $this->map[$action]['data'] : NULL;
}
} // end class ActionLookupMapper
?>
You guys are doing great work!
You're completely right. It's just a typo (or rather cut©-o). There's no sinister plan hidden behind it.
Yeah, I assumed as much. :P
But the separation issue between the Model and View could perhaps be solved with a ViewHelper? I've actually no idea how the pattern works
Could you give an example when I would (should?) need the dictionary to dispatch the request?
Also I was thinking if we shouldn't add some kind of errorcheck in the ActionMapper if the requested action does actually exist. Something like this:
PHP Code:class ActionMapper
{
function actionExists($actionName)
{
$file = 'actions/' . $actionName . '.php';
return is_readable($file);
}
}
I need to take a look at the code but all you changes sound fine. Perhaps we should do PHP4 and PHP5 versions of the code? I was going for the minimum files because the interfaces confused people before.
I like the ActionLookupMapper inheriting the ActionMapper. I may tweek that code so ActionLookupMapper can do both dictionary lookups and fall back to regular mapping. I have found partial remapping very useful in real projects.
I think we should discuss whether we implement pre and post filter chains in the Front Controller to make it an Intercepting Filter. If we pass both in both Request and Response objects in, and return the Response object, then you could pre filter the Request and post filter the Response outside the Front Controller. That keeps it small and focused.A thing that has had me thinking a bit is, that the FrontController gets the Request object passed on, but it creates the Response. This makes it different from all the other controllers, which get's both objects passed. That makes me think that the Response should probably be passed on aswell, or the opposite - that the FrontController should create the Request. What do you think about this ?
Perhaps we should implement an additional InterceptingFilter type class that creates the Request and Response internally plus contains pre and post filter chains AND the Front Controller inside. Then you could use the simple FrontController or the all-in-one InterceptingFilter?
Centralized access control is a very practical case that we should be able to support. For example, if the dictionary map contained access control information then an access control pre filter could get data from the map and compare it to data in the session to do the access check. We should be able to support this (though not necessarily actually provide code to implement it). What do you think?
Christopher
You know why ?I think it might take us another 2000 posts to get an Application Controller done! This is already the 5th longest thread ever in this forum and all we have is a tiny Front Controller and a simple Mapper!
My little finger tells me it's because you're trying to perfect things, which are abstracted from a real application. It's called Premature Optimisation[1].
Altrough I have many ideas to contribute, but I think that the approach should be changed. You should better try to build a real-world application and then extract the framework. That's how Rails[2] was built and I think it's pretty successful.
Cheers,
... zimba
[1] http://c2.com/cgi/wiki?PrematureOptimization
[2] http://www.rubyonrails.com
You are, of course, absolutely right and absolutely wrong.You know why ?
My little finger tells me it's because you're trying to perfect things, which are abstracted from a real application. It's called Premature Optimisation[1].
You are correct is that we really should have use cases that we must be able to implement. We do have the original cadmiumgreen's (Byron did you spontaneously combust?!?) switch statement and DougBTX (Mr. 2000 woo hoo!) has thrown a few at us. But we really need use cases and more importantly test cases.
Where you are incorrect is that both kyberfabrikken and I have written frameworks and plenty of production code, so have been through the practical aspects of this already. That is what makes this interesting to me is that we are contributing our code and blending it.If you don't get involved you can't effect what is happening. We are open to ideas. You could make a difference I think. Give us specific comments about the code. Contribute code. Give use cases. Challenge the ideas presented. We are trying to build a simple but useful system that answers with code many of the MVC questions asked.Altrough I have many ideas to contribute, but I think that the approach should be changed. You should better try to build a real-world application and then extract the framework. That's how Rails[2] was built and I think it's pretty successful.
If you are interested in Rails then hopefully soon we will get started on an Application Controller which is what Rails' Action Pack is. Rails apps extend the ApplicationController and I think that is the way we are headed as well. I think Rails was built by people who maintained their focus and stuck to "Don't Repeat Yourself". Hopefully you will be able to build a Rails like system out the the code we create here.
Christopher
Posting Permissions
Bookmarks