Skip to main content ↑ ↓
Topic: Sub action dispatching (Read 4113 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Sub action dispatching

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:
Code: [Select]
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:
Code: [Select]
?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[1], and no need to have hooks.

If you see any hole, or problem... well, it's a forum, let's discuss! :P
1 yes, there are permissions, but that's not too difficult to deal with since it's done during the initialization of the class anyway, it could just be a constant or a method, or it could just be moved back to the subaction (it's just one line anyway)↵
Bugs creator.
Features destroyer.
Template killer.

Re: Sub action dispatching

Reply #1 –

I don't think having several files is better than an array at the top of one file.  I think that's actually messier.

Re: Sub action dispatching

Reply #2 –

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.
Bugs creator.
Features destroyer.
Template killer.

Re: Sub action dispatching

Reply #3 –

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?

Re: Sub action dispatching

Reply #4 –

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?
Bugs creator.
Features destroyer.
Template killer.

Re: Sub action dispatching

Reply #5 –

Create my own action.

Re: Sub action dispatching

Reply #6 –

Then you will create your sub actions as methods of the controller:
Code: [Select]
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. :)
Bugs creator.
Features destroyer.
Template killer.

Re: Sub action dispatching

Reply #7 –

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.
Last Edit: August 01, 2014, 11:31:06 am by Spuds

Re: Sub action dispatching

Reply #8 –

Quote from: Spuds – 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
Bugs creator.
Features destroyer.
Template killer.

Re: Sub action dispatching

Reply #9 –

Well, now that I have finished messing with the cache, it may be worth a shot put together some code. :D
Bugs creator.
Features destroyer.
Template killer.

Re: Sub action dispatching

Reply #10 –

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).
Bugs creator.
Features destroyer.
Template killer.
 

Re: Sub action dispatching

Reply #11 –

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.