Welcome Guest, Not a member yet? Register   Sign In
Writing Admin/User/Public controllers to insure authentication
#11

A perfect example, in my case, would be the splitting up of the controller files since I first created my site. If I had an include statement in each controller, I would have had to change the include statements in all of my controllers to reflect the new locations of those classes. Since I did not have the include statements in the first place, I did not need to change anything to reflect the new locations of the classes.

For some people, this isn't a big deal. Personally, I have a lot of controllers, and I don't want to have to change every file which extends Admin_Controller or Front_Controller just because the file containing that class moves to a new location or the name of the file changes for some reason.
Reply
#12

(01-02-2015, 01:39 PM)mwhitney Wrote: For some people, this isn't a big deal. Personally, I have a lot of controllers, and I don't want to have to change every file which extends Admin_Controller or Front_Controller just because the file containing that class moves to a new location or the name of the file changes for some reason.

That is why constants were invented! Wink
Reply
#13

(This post was last modified: 01-02-2015, 11:20 PM by ivantcholakov. Edit Reason: Clarification )

@includebeer

"That is why constants were invented!"

Code will become less portable, other people will be forced to use your set of constants, they might have already invented their own set (if they use the same approach too). Second, it is useless work to document these constants. Also, you will think "this constant has a ugly name, let me deprecate it in favor of that one" - useless work.

Edit: I am writing about constants for directory locations, not for constants in general.
Reply
#14

(01-02-2015, 11:17 PM)ivantcholakov Wrote: Code will become less portable, other people will be forced to use your set of constants, they might have already invented their own set (if they use the same approach too). Second, it is useless work to document these constants.

Less portable? A constant allows you to define a path and a filename in a single place. How can this be less portable than hard-coding everywhere?


Quote:Also, you will think "this constant has a ugly name, let me deprecate it in favor of that one" - useless work.

It's the same with everything: function, class name, configuration item...
Reply
#15

"How can this be less portable than hard-coding everywhere?" - For autoloading it is not hard-coding everywhere, it is hard-coding within one single place: https://github.com/ivantcholakov/starter...toload.php It is a manageable way. Even, if you must place a specific class within a weird directory due to an external reason, you may use a map within a configuration file.

"It's the same with everything: function, class name, configuration item..." - For the specific task of loading classes I can avoid bothering about this aspect, so I do it.
Reply
#16

Including a constant is better than including the file path/name in each controller. However, if the loader/autoloader can find your class in the first place, you don't need to do either.

A great deal of code in CI's core is dedicated to loading classes, whether autoloading them or using $this->load->xxx(). From what I've seen, adding some more code to handle it in a manner which makes sense for your project, or including the use of Composer or some other autoload mechanism, is only going to have a negative impact on the project in the most extreme cases.
Reply
#17

(12-31-2014, 11:38 PM)bclinton Wrote: What's so horrible about an include_once statement above your controller class declaration that indicates the location of the custom controller class you are extending?
What's horrible about it is that one line here and one line there means more lines all around and in many cases, it's not one line but many includes/requires and one must also fret in some cases over the sequence of these includes/requires, etc., et. al. Every line of code you add contributes to the burden of maintaining your code project. Each bug due to a missing include could mean a few minutes of logging into the server, digging around to find the problem, possibly more if the problem happens sometimes but not others.

It adds up in a complex project.
Reply
#18

(01-02-2015, 06:44 PM)includebeer Wrote: That is why constants were invented! Wink
Not exactly. Constants were invented to contain constant values. Like pi (3.14159265358979323846) or e (2.71828182845904523536). If your directory location changes then it's not exactly constant, is it? I think what ivantcholakov and mwhitney (and I) are saying deserves consideration. Maintaining a project in many cases means moving from one server to another or bringing on more developers, each with their own workstation. It also means putting the code into a repository without one person's constant values over-writing another person's different constant values. If you don't use namespaces (which CI doesn't), every constant risks having a name collision with some other library you want to use. Every constant that might differ between machines or developers must be put into a configuration file that is somehow included in the project but excluded from the repository (so that users' differing values are not in conflict). All of this takes time, which costs money, which adds up in a complex project.

Constants were not invented to solve the problem of annoying thickets of include and require statements. Autoloaders were.
Reply
#19

(01-05-2015, 01:50 PM)sneakyimp Wrote:
(01-02-2015, 06:44 PM)includebeer Wrote: That is why constants were invented! Wink
Not exactly. Constants were invented to contain constant values. Like pi (3.14159265358979323846) or e (2.71828182845904523536).

Constants were invented to contain a value that doesn't change during the execution. It doesn't need to be something like PI ! Anyway all projects are different and not all projects are super complex with tons of other developers.

Also, the argument was:

Quote:Personally, I have a lot of controllers, and I don't want to have to change every file which extends Admin_Controller or Front_Controller just because the file containing that class moves to a new location or the name of the file changes for some reason.
...that's why I talked about constants. I never said constants were better than autoloaders!
Reply
#20

Hello,

Just to add to the possibilities of including more controllers, I would like to ask you to visit an updated version of the link in question: http://avenir.ro/codeigniter-tutorials/n...ontroller/

I added two more ways...
Reply




Theme © iAndrew 2016 - Forum software by © MyBB