I was thinking... hey where did everybody go? :P
I know you love when I think, don't be shy and hide yourself behind the curtains. 8)
Okay, now back to the serious stuff.
We have a dispatcher for the controllers that relies (mostly) on find by itself the files and classes to load based on naming patterns.
For sub-actions, instead, we still rely on (ugly) arrays.
So, I was thinking: could we use naming pattern for sub-actions too?
I think so, let's see if you like that.
The sub-actions methods all start with "action_", so for "internal" methods we should be fine:
if (method_exists($this, 'action_' . $sub_action))
// use it
Now, the funny part comes with "external" methods, so addons and few odd controllers. Obviously they are controller, so the "_Controller" part of the name is there, and the first part could be the name of the sub-action, so, let's say:
?action=post;sa=myaction
could require_once the CONTROLLERSDIR/MyactionSub.controller.php (or ADMINDIR/MyactionSub.controller.php), load the class "MyactionSub_Controller" and call the method: action_myaction (the "Sub" bit is to avoid conflicts).
That way there would be no need to have the arrays of sub-actions, and no need to have hooks.
If you see any hole, or problem... well, it's a forum, let's discuss! :P
I don't think having several files is better than an array at the top of one file. I think that's actually messier.
Not several files.
The number of files would not change from what it is now. Internal methods will be "detected" based on name pattern instead of the array (action_*), the first code block above.
The "several" (or better additional) files are just for addons, like it is even now, just recognized by naming pattern instead of having to use hooks and add a new entry to the array.
Yes I'm talking add ons. Or mods. Basically all the controllers I've written would now have to be several files instead of one right?
It depends.
What kind of controllers did you write?
A controller to extend for example BoardIndex.controller.php?
Or a controller to create your own action?
Create my own action.
Then you will create your sub actions as methods of the controller:
class MyAction extends Action_Controller
{
public function action_asubaction() {}
public function action_bsub() {}
public function action_csub() {}
etc.
}
The case you have to have a new file is when you want to extend an existing controller, you already have to do it now, adding a new file and using the hook to add the subaction (unless you want to edit the core file, of course), in my proposal you wouldn't have to add the hook, but just a file with the proper name. :)
Would we still handle pre_dispatch actions which we kind of use as constructors? Guess it could still check if that exits then call it, then if the action exists call it, otherwise action_index?
Some of those actions get complicated as they call can call actions in other controllers with the file-> controller-> action-> in the array, and of course show/not show items and permissions, admin tabs, etc ... I like the idea, just trying to wrap my head around how much would have to be done to implement.
That's why I posted as well. lol
I'm sure it will be messy and not so easy at the beginning (and that's also the reason I didn't put up any code yet), there are a lot of inconsistencies all over the place.
And actually, while thinking about it I realised there could be odd situations as well, though they may be actually helpful: if done "right", the same (sub-)controller could be shared across different actions. For example, now we have the Groups_Controller that is used in few places (I think at least 2, maybe 3) to show different things (to admin, moderators and I think users), this could become a good candidate for a sub-action shared across the three "main" controllers.
We do it now explicitly instantiating the controller from the sub actions array, with that schema it could become automatic from any controller needing a "groups" sub-action.
Now, writing it, I have the doubt that maybe the groups could be better exist as a model rather than a controller, so more to think about... lol
Well, now that I have finished messing with the cache, it may be worth a shot put together some code. :D
Here it is an example:
https://github.com/emanuele45/Dialogo/compare/elkarte:development...emanuele45:dispatch?expand=1
I feel I pick the wrong example, because in that case I couldn't completely remove the current dispatching because of the "activities", but it's just an example... :P
But anyway if it has to be integrated in 1.1 it has to keep a similar structure to maintain backward compatibility, so it's not that bad either.
Actually, the biggest obstacle would be the "tab_data" block that couldn't be replaced and would be expanded anyway in order to add new entries... I think there is a better way to do it (starting with moving all the menus to the database and add a menus editor).
I like that you're trying to simplify it, but I think it is going to make it more complex for developers.
What a lot of software does is use a file which defines all of the routes. They also define them in a RESTful way, so you don't have to check in each file.
What if you want to change the route and you have subrouting/forwarding? With named routes, all you need to do is change it at the name.