Codeigniter development (v3.0)

[eluser]wiredesignz[/eluser]
I have noticed a few changes to the framework which seem to be frilly and cute but really unnecessary complications to the simplicity of CodeIgniter.

For instance:

in system/Router.php

@jdfm, What is the purpose of a php parser on the routes array. 99% of users won't use or get any benefit from this. It is just adding more bloat to the codebase.

@Narf, Why are there additional checks for dashes ('-') in the controller and method segments of the URL. Routing already allows these to be detected and managed by the route regex.

If anyone else has noticed anything pointlessly added to the v3.0 codebase don't hesitate to post.

[eluser]Aken[/eluser]
I wouldn't consider these simply frilly and pointless. The dash check allows users to automatically map a controller URI segment such as "manage-users" to the actual controller "Manage_users", without the need to add routes for every instance. Since dashes are typically more ideal for URLs and SEO, this is an extremely useful feature.

Route callbacks are a little less useful in the broad spectrum of things, but still offers more flexibility to the routes system. I'd hardly consider ~40 lines of additional code as bloating the core. It also does not impact the standard route functionality. I think that the feature adds more flexibility to CodeIgniter without being complicated or changing core functionality, so why not?

[eluser]wiredesignz[/eluser]
@Aken, I know what the code does.

So what prevents a creative developer from using simple routing like so:

Code:

$route['(.*)-(.*)'] = '$1_$2';

It seems pointless hacking something into the codebase that can be solved with a little thought on the user's part.

Your idea of flexibility is only valid if the changes are easily understandable and will be implemented by a decent percentage of users. I do not see this happening here. Bloat occurs if code, which is never going to be used, is added to any software.

In fact adding reverse routing to CI would be much more beneficial to the majority of developers than both of these hacks.

EDIT:
I am concerned also, from looking at the examples posted for the processed routes, that they are attempting to set the base business logic for an application inside the routes closures. Thus if the controller or model doesn't also enforce business logic then altering routing will cause the application to fail. Routes should not do this, they should direct traffic not establish rules.

Reference: https://github.com/EllisLab/CodeIgniter/pull/1636

Default page numbers and other values should be set in the page controller, not in the routing.

Copying Laravel routing methodology might be cute, but they're missing the point entirely.

[eluser]Aken[/eluser]
[quote author="wiredesignz" date="1352352468"]@Aken, I know what the code does.

So what prevents a creative developer from using simple routing like so:

Code:

$route['(.*)-(.*)'] = '$1_$2';

It seems pointless hacking something into the codebase that can be solved with a little thought on the user's part.[/quote]

This would affect every instance of a dash, which is not what the mentioned functionality does. A creative developer would need to come up with a more complicated route scheme in order to achieve what literally ONE line of code does in the back-end. I don't see how anyone can argue with that one, frankly.

Your idea of flexibility is only valid if the changes are easily understandable and will be implemented by a decent percentage of users. I do not see this happening here. Bloat occurs if code, which is never going to be used, is added to any software.

My idea of flexibility is the literal meaning of the word, which is not conditional on how a user interacts with the framework. I agree that thorough documentation is a priority, so that people will be able to understand and implement it (which I still think you should help contribute to). Who knows how often a feature like this may be used, though. Don't let your own views of a feature completely negate its potential.

I'm personally intrigued to see if anyone comes up with an unintended-but-useful feature when it comes to the route closures. Why impede progress? The worst that I can see happening is the feature is removed, and CI developers will have a better understanding of what's expected from the framework.

In fact adding reverse routing to CI would be much more beneficial to the majority of developers than both of these hacks.

I can't comment on that; I've never had the need for reverse routes.

I am concerned also, from looking at the examples posted for the processed routes, that they are attempting to set the base business logic for an application inside the routes closures. Thus if the controller or model doesn't also enforce business logic then altering routing will cause the application to fail. Routes should not do this, they should direct traffic not establish rules.

Reference: https://github.com/EllisLab/CodeIgniter/pull/1636

Default page numbers and other values should be set in the page controller, not in the routing.

Why can't they be done in the routing? I guarantee you a lot of people have added a default page number to their routes. I've seen it done in people's examples when dealing with the Pagination library, and other situations.

Copying Laravel routing methodology might be cute, but they're missing the point entirely.

Copying Laravel was never the intention, as the author has stated in the pull request.

I can understand why you have the point of view that you do, but the impression I have is that you're looking down at anyone with a differing opinion as flat wrong. The Reactor team has already stated their intentions to retain the feature, so rather than arguing with it, why not help make it as useful as possible? Refine the functionality, make the user guide easy to understand, etc. Help prevent the things you're concerned about. That's what this community is for.

[eluser]wiredesignz[/eluser]
@Aken, I think you're a bit confused, that regex only returns the first ($1) and second ($2) matches from the beginning of the URL. Modifying this basic regex or adding additional routing before this would be needed to manage other segments.

If you are also using routing to establish application business logic then there is nothing further to discuss. We are obviously at different places in our understanding of application development and maintenance.

[eluser]Aken[/eluser]
[quote author="wiredesignz" date="1352445903"]@Aken, I think you're a bit confused, that regex only returns the first ($1) and second ($2) matches from the beginning of the URL. Modifying this basic regex or adding additional routing before this would be needed to manage other segments.[/quote]

I am partially mistaken (not "confused"...) in that it does not affect every dash. However, it has nothing specifying the beginning of the URI. In fact, adding this in as-is, the last dash is replaced with an underscore. And that dash can be anywhere in the URI, including far down the segments. Like you said yourself, you need more complicated regex or additional routes in order to achieve the same functionality is one single str_replace().

If you are also using routing to establish application business logic then there is nothing further to discuss. We are obviously at different places in our understanding of application development and maintenance.

I obviously don't use application logic in routes with CI, because it didn't exist until now. And like the person who proposed this change in the first place, I don't really see myself using it for anything beyond some simple string manipulation, or perhaps throwing an error like show_404(). But that's my scope. Someone else may find a new, interesting use, and I'd like to see that. Because maybe I could learn something.

By all means, show us what kind of awful business logic you might expect people to use in the closures. It's difficult for me to think of these things because it's not my coding style. I'm all ears.

[eluser]wiredesignz[/eluser]
@Aken, The Regex start (^) and end ($) characters are hardcoded into the CI_Router::_parse_routes method.

Why can't they be done in the routing? ...

Because routing manages 'traffic', it should not establish business rules.
Controllers and/or Models should not be made dependent on the Router.

[eluser]Florian Müller[/eluser]
As I heard here, the new CodeIgniter-Version may also contain a switchable Session class which allows the user to determine wether to use cookies or native PHP sessions. How will this be done?

Another thing I found quite hard in CodeIgniter is handling statuses. CodeIgniter does expect to return a method true on success or false on failure. If I want to return a status, I actually only can return a string or a number. I solved this with Pseudo-Enums, e.g. the following:

Code:

<?php
class StatusEnum {
    const FAILED_NORIGHTS = 1;
    const FAILED_UNKNOWN  = 2;
    const SUCCESS         = 3;
}
?>
...
<?php
$res = $class->myFunction();
if ($res == StatusEnum::FAILED_NORIGHTS) {
    echo "no rights";
}
?>

I don't know if this is common, but it's a very nice way to handle statuses in frameworks where even the exceptions are not thought of this (exceptions in CodeIgniter are meant to display a page or something, but only used if a real error happened).

What do you think of this last proposal? I think it would be worth an analysis

And, my last question: Is there somewhere an assessment when CodeIgniter v3.0 will be available?

Regards, Florian

[eluser]Aken[/eluser]
[quote author="wiredesignz" date="1352457451"]@Aken, The Regex start (^) and end ($) characters are hardcoded into the CI_Router::_parse_routes method.[/quote]
I'm aware of that, but what's your point? Im saying that your regex route example:

Code:

$route['(.*)-(.*)'] = '$1_$2';

... will affect more than just a single segment URI, and is not a suitable substitute for the str_replace() feature that has been added.

[eluser]wiredesignz[/eluser]
@Aken, I guess I should have been more thorough with my example for you. As I mentioned before, modifying the routes or adding additional routes would cope with both the first and second segments of the url. ie: controller/method.

Code:

$route['(.*)-(.*)/(.*)-(.*)'] = '$1_$2/$3_$4';
$route['(.*)/(.*)-(.*)'] = '$1/$2_$3';
$route['(.*)-(.*)'] = '$1_$2';