DASPRiD / Dash

Flexible PSR-7 compliant HTTP router
BSD 2-Clause "Simplified" License
29 stars 9 forks source link

Change ordering of numbered parameters #27

Closed GeeH closed 10 years ago

GeeH commented 10 years ago

Hello,

This will probably go down very badly, but I'd like to propose we change the ordering of the numerical indexed shortcut parameters from path, controller, action, methods to path, action, controller, methods. "Why?" I hear you ask. "This is madness!" I hear you jeer, but please, hear me out.

Firstly, let's make something plain. Flipping the order of controller and action is counter-intuitive. I understand that. But I feel that the new order will make hierarchical routes easier to define.

Take the following route declaration:

'profile' => ['/profile', 'profile', 'index', 'children' => [
    'messages' => ['/messages', null, 'messages''],
    'details' => ['/details', null, 'details'],
    'view_message' => ['/message/:id', null, 'view-message', 'constraints' => ['id' => '\d+']], 
]],

See all those horrible nulls you have to pass so that the route inherits it's parents controller? Using my method, they can safely be avoided thus:

'profile' => ['/profile', 'index', 'profile', 'children' => [
    'messages' => ['/messages', 'messages''],
    'details' => ['/details', 'details'],
    'view_message' => ['/message/:id', 'view-message', 'constraints' => ['id' => '\d+']], 
]],

Is this enough of a win to justify doing something people won't expect? I'll let you decide.

Thanks for reading.

DASPRiD commented 10 years ago

I agree with both of your points. Yes, it may look counter-intuitive, as you'd expect the higher-level value (the controller) to come first first. But the short-hand parameters were actually introduced to make people write less, so your argument is completely valid.

From my side, this gets a :+1:, but I'd like to hear the opinion of other people first. If enough people agree, can you make a pull request for this?

bakura10 commented 10 years ago

I think it justify enough. The idea of this notation, if I understand it correctly, is to make route writing faster. To this extent it makes sense. Any people that want to be more explicit will use keys anyway.

juriansluiman commented 10 years ago

:+1:

It's not that counter intuitive if you think about it ;)

manuakasam commented 10 years ago

:+1: for the initial idea.

However it is 100% certain that this change will confuse people. For ages we've always talked about routes that follow from a given controller to a certain action. With the above change it means people have to re-think.

My requirement for the above change would be that all documentation examples (as well as future talks / hangout examples) will always be appended with *Controller. Use examples that really indicate that a key is a controller. So the above example would become this:

'profile' => ['/profile', 'index', 'profileController', 'children' => [
    'messages' => ['/messages', 'messages'],
    'details' => ['/details', 'details'],
    'view_message' => ['/message/:id', 'view-message', 'constraints' => ['id' => '\d+']], 
]],

Alternatively, examples should follow the "ZF-Standard" of fully prefixing things. So instead of profileController examples may even better contain MyNamespace\Controller\Profile.

'profile' => ['/profile', 'index', 'MyNamespace\Controller\Profile', 'children' => [
    'messages' => ['/messages', 'messages'],
    'details' => ['/details', 'details'],
    'view_message' => ['/message/:id', 'view-message', 'constraints' => ['id' => '\d+']], 
]],

For whatever the decision would fall, if this order will be changed, it's really important to me that future examples become clearer by making this one part a little more verbose.

DASPRiD commented 10 years ago

Well, that's all I need to hear, guess you can go ahead with it, @Spabby :)

GeeH commented 10 years ago

Before we close this, can this be taken a step further. I am proposing that the parameters (for want of a better term) be ordered in the order that they will most often be overridden from their parents. For me, you will overwrite the methods more often than you will overwrite the controller, so arguably this could be extended to path, action, methods, controller. This may be a step too far.

manuakasam commented 10 years ago

@Spabby :-1: for the very reason that we made ['*'] the standard method, so i would argue that Methods won't be overwritten normally by any "normal" user. By specifying ['*'] as default we practically reduced this parameter to power-users that really want to have full control over their application.

Furthermore I am one of those guys who have very slim controllers. Practically one controller matches one action. So even on children I'd be overwriting the controller fairly often. Much more often than i would be overwriting the methods

juriansluiman commented 10 years ago

I'd also keep action + controller as a pair together, don't split them apart as it makes understanding the short syntax more difficult.

GeeH commented 10 years ago

I agree, I was just trying to check we hadn't missed anything - incoming PR if I don't cough all over my screen again.