Welcome Guest, Not a member yet? Register   Sign In
Poll: Improved routing?
You do not have permission to vote in this poll.
yes
82.98%
39 82.98%
no
8.51%
4 8.51%
maybe
8.51%
4 8.51%
Total 47 vote(s) 100%
* You voted for this item. [Show Results]

Magic Routing toggle
#11

(This post was last modified: 04-13-2015, 01:13 AM by sv3tli0.)

(04-12-2015, 08:44 AM)includebeer Wrote:
(04-12-2015, 04:26 AM)sv3tli0 Wrote: With my personal experience I vote for full remove-al of auto route matching /controller/method

Why does it bother you if it's still available but can be turned off?

I don't like this default behaviour of most of the frameworks .. 
Developers have to named their Controllers and Methods exactly as they will be accessible. 
And if for example the method is with different name you have to make a Custom route which will duplicate the default route to display it..
This thing I don't like a lot.

Router paths should't be auto generated by the framework. Its developers task to set-up them not framework..

But you are right it will be good to have option for that , the same way as it will be good to have option to create resource(RESTful) routes related to some new REST_Controller (this is idea from other thread).
Best VPS Hosting : Digital Ocean
Reply
#12

(04-09-2015, 01:04 PM)Hobbes Wrote: i am not against it, and fine with the feature supported. So long as i am not forced to use it.

+1

I Agree 100%
Reply
#13

As I thought more about this today and how it would effect my applications, I guess if we add packages with controllers (different thread) and at the same time you only use routes.php (no magic autoloading controllers) then the router will also need to merge all of the routes.php files together before determining the route to the correct controller. I assume we would also want to cache that as well to keep the speed up.

Thoughts?

DMyers
Reply
#14

If we're going to have things "magically" happen, I would argue that the magic should be OFF by default and require the developer to turn it on.

Of course, some are going to just turn it on and move on and <deity> help them when it all blows up (and it will). If it's OFF by default, then at least maybe some of them will learn what's going on behind the scenes before they go all nuts with automagical events.

One of the things I dislike about Laravel is the huge amount of automagic that is incredibly difficult to debug when the previous programmer was doing resume-driven development.
Reply
#15

(04-13-2015, 03:14 PM)albert.freeman Wrote: If we're going to have things "magically" happen, I would argue that the magic should be OFF by default and require the developer to turn it on.

Of course, some are going to just turn it on and move on and <deity> help them when it all blows up (and it will). If it's OFF by default, then at least maybe some of them will learn what's going on behind the scenes before they go all nuts with automagical events.

One of the things I dislike about Laravel is the huge amount of automagic that is incredibly difficult to debug when the previous programmer was doing resume-driven development.

While I agree that having automagic off would be best, it should default to ON so it doesn't break backwards compatibility from the get go.

As for laravel, they do a lot of magic, but you still have to declare your routes with them. Their routing system is fantastic.
Reply
#16

(This post was last modified: 04-13-2015, 11:57 PM by sv3tli0.)

Backwards Compatibility is pointless thing to watch on..
We are discussing namespaces, need of rebuilding the core of CI, and Backwards Compatibility will be not possible at all..

If we are going to keep this it should be 1 Line inside routes configuration.
It can be commented or not doesn't matter..
Any developer which is upgrading to CI 4 will have a lot of work and if he has to uncomment this line this will be the smallest thing to do..

All routes even this default Controller/Method should be listed inside the routes configuration file so you know how it looks like and what its doing .. and to be able to disable it with 1 comment..
Best VPS Hosting : Digital Ocean
Reply
#17

(04-13-2015, 11:55 PM)sv3tli0 Wrote: Backwards Compatibility is pointless thing to watch on..
We are discussing namespaces, need of rebuilding the core of CI, and Backwards Compatibility will be not possible at all..

Backward compatibility is never pointless. It doesn't matter if the core is completely rewritten from scratch. It can still be somewhat compatible without requiring us to rewrite our applications. Your quest for the bleeding edge PHP programming is not worth the time it will all takes us to rewrite everything. What's the point in using a framework if it can back-stab me anytime and render all my previous work worthless. Maybe Laravel is better for you. Dodgy
CodeIgniter 4 tutorials (EN/FR) - https://includebeer.com
/*** NO support in private message - Use the forum! ***/
Reply
#18

(04-15-2015, 04:30 PM)includebeer Wrote:
(04-13-2015, 11:55 PM)sv3tli0 Wrote: Backwards Compatibility is pointless thing to watch on..
We are discussing namespaces, need of rebuilding the core of CI, and Backwards Compatibility will be not possible at all..

Backward compatibility is never pointless. It doesn't matter if the core is completely rewritten from scratch. It can still be somewhat compatible without requiring us to rewrite our applications. Your quest for the bleeding edge PHP programming is not worth the time it will all takes us to rewrite everything. What's the point in using a framework if it can back-stab me anytime and render all my previous work worthless. Maybe Laravel is better for you. Dodgy

Exactly. Whenever you can maintain backwards compatibility, you should. In this case when BC is a simple as having a toggle default to ON instead of OFF, it's a no brainer.
Reply
#19

(04-13-2015, 11:55 PM)sv3tli0 Wrote: Backwards Compatibility is pointless thing to watch on..
We are discussing namespaces, need of rebuilding the core of CI, and Backwards Compatibility will be not possible at all..

If we are going to keep this it should be 1 Line inside routes configuration.
It can be commented or not doesn't matter..
Any developer which is upgrading to CI 4 will have a lot of work and if he has to uncomment this line this will be the smallest thing to do..

All routes even this default Controller/Method should be listed inside the routes configuration file so you know how it looks like and what its doing .. and to be able to disable it with 1 comment..

I agree with not being concerned with backwards compatibility in CI4. If CI4 will be concerned with backward compatibility, tell me now so I can move on.
Reply
#20

(04-15-2015, 04:30 PM)includebeer Wrote:
(04-13-2015, 11:55 PM)sv3tli0 Wrote: Backwards Compatibility is pointless thing to watch on..
We are discussing namespaces, need of rebuilding the core of CI, and Backwards Compatibility will be not possible at all..

Backward compatibility is never pointless. It doesn't matter if the core is completely rewritten from scratch. It can still be somewhat compatible without requiring us to rewrite our applications. Your quest for the bleeding edge PHP programming is not worth the time it will all takes us to rewrite everything. What's the point in using a framework if it can back-stab me anytime and render all my previous work worthless. Maybe Laravel is better for you. Dodgy

I don't say that ci4 should have no BC.. But CI needs some power. If we focus on keeping maximum BC you will have result as IE 10 .. New which is already old ..

This is major release until it there will be CI 3 versions perhaps 3.1 /  3.2 ..
You are can to keep your apps on CI 3 no body is forcing anyone to upgrade..

BTW I am using CI, Laravel and Symfony and I will be very happy if CI 4 will be the one in my future projects as its hard to know all small tricks and details of 3 frameworks at once.. 
Best VPS Hosting : Digital Ocean
Reply




Theme © iAndrew 2016 - Forum software by © MyBB