Welcome Guest, Not a member yet? Register   Sign In
Helpers and Other Conventions
#41

I know this probably does not help much, but personally all these could be dropped and I would not miss them at all:
Array Helper
CAPTCHA Helper
Date Helper
Email Helper
Form Helper (except form_open)
HTML Helper
Inflector Helper
Number Helper
Path Helper
Smiley Helper
String Helper
Typography Helper
XML Helper
Security Helper

And most of form_helper (apart from form_open for CSRF reasons, that is really helpful).

I think a good case can be made to get rid of helpers altogether.
Reply
#42

(This post was last modified: 07-01-2016, 08:17 AM by prezire.)

I wouldn't recommend it. I personally benefited a lot from helpers especially on projects that needed to get done really quickly. A quick glance to CI3's doc and I could easily get things like plural(), humanize(), unix_to_human(), nice_date(), form_open_multipart() without creating my own or moving to different frameworks (like Moment.js for date formats) all the time just to get the same output. Creating <select><option> inside a PHP loop really looks ugly. It even gets uglier if your team can't even decide whether to use curly braces VS colon-endifs as a convention for loops in a view file, which leads to more denied Git pull requests. A simple <?= form_dropdown(...) ?> and everything is accepted beautifully.

CI4 is going to get a massive blow from other frameworks that have tons of helpers in their arsenal. I'd advise re-evaluating the functions/methods instead of removing the helpers themselves.
Long live CodeIgniter!
Reply
#43

Fair enough points. As for your plural example, I just took a look at the function and actually someone has spent alot of time creating that. I wanted to say 'look it doesn't work for blah blah' but I could not find a common example that didn't work. And if you are going to have helpers I suppose lots is better than a few, after all I suppose it makes no difference if you do not use them, it is not exactly overhead. So even if I do not personally use them, others might, so I appreciate what you are saying.
Reply
#44

(07-01-2016, 05:42 AM)PaulD Wrote: I know this probably does not help much, but personally all these could be dropped and I would not miss them at all:
Array Helper
CAPTCHA Helper
Date Helper
Email Helper
Form Helper (except form_open)
HTML Helper
Inflector Helper
Number Helper
Path Helper
Smiley Helper
String Helper
Typography Helper
XML Helper
Security Helper

And most of form_helper (apart from form_open for CSRF reasons, that is really helpful).

I think a good case can be made to get rid of helpers altogether.

I'd support this. There are numerous composer packages to achieve the same thing if you need it in your project.
Reply
#45

(This post was last modified: 07-01-2016, 05:12 PM by prezire.)

If you decide to rely everything on Composer, the final outcome of CI in the future will degrade like 10% (MVC with just namespaces + some request filtering) and 90% Composer (Libraries, Helpers) including ORMs and View Formats. Don't rely too much on Composer, which the CI team has no full control off.

If a company employs 10 PHP/CI developers abroad, you can bet each one would use 10 different plugins from Composer, each with 10 different method signatures/syntax/docs for as simple as formatting dates or template engine! Speaking of template engine, I believe a lot of previous requests are valid. Due to CI's lack of template engine support, my company uses third-party plugins like jQuery template engine, another plugin for sanitizing outputs, and even deciding to use ReactJS just to see how things would work out for the views. It's a mashup of plugins because of the different developers. This move is a prelude to get out of CI because it has no template engine. It's good to see CI4 implementing its own template engine because the 10 PHP developers would converge and use conventions that's native to the framework itself and not use third-party plugins that are scattered all over the web. The same goes for helpers.

Sooner or later Composer is going to fade like PEAR and the CI team would end up with a framework that's going to be very small and impractical to use because it relied too much on third-party dependency managers. The Laravel team was able to pull off the Composer mechanism because they've placed a lot of native tools in the framework including helpers. Have you seen their massive Services? Meaning to say, they'd still survive even if Composer disappears. PHP is getting better and faster, so I'd recommend adding more functions to the list instead of removing the helpers. But keep the structure similar to the old CI to prevent it from becoming tricky/tedious to implement like Zend or Symphony.

Just see other frameworks' helper functions list:
https://laravel.com/docs/5.1/helpers
http://archive.oreilly.com/pub/a/ruby/ex...thods.html
http://symfony.com/doc/current/component...elper.html
http://book.cakephp.org/2.0/en/views/helpers.html
Long live CodeIgniter!
Reply
#46

Helpers is not core of framework, it just addon and most of CI helper is good, hope some of it will not deprecated. CI4 is moving forward as php getting better and provide some funtionality like other framework offered is really nice thing. IMO, the real problem of dependency manager is when the package is abandoned or stop provide support/patch/security fixed. If the helper/package is officialy from CI, which is the CI team has full control, it is promised for long term of support/patch/security fixed.
KeepĀ calm.
Reply
#47

(This post was last modified: 07-01-2016, 06:08 PM by prezire.)

Quote:Libraries != helpers.
Static classes != OOP.
Static functions are NOT extendable or overridable.

Helpers are only useful for their short names. You'd use a full-featured library if you didn't mind writing more code, and there's nothing wrong with that, just don't call that "helpers".

@Narf Can you explain further about static functions (or methods) not extendable http://icecream.me/4a78eefd13585dbb3f65478752f1933d?
Long live CodeIgniter!
Reply
#48

http://php.net/manual/en/language.oop5.l...ndings.php
KeepĀ calm.
Reply
#49

(07-01-2016, 06:03 PM)prezire Wrote:
Quote:Libraries != helpers.
Static classes != OOP.
Static functions are NOT extendable or overridable.

Helpers are only useful for their short names. You'd use a full-featured library if you didn't mind writing more code, and there's nothing wrong with that, just don't call that "helpers".

@Narf Can you explain further about static functions (or methods) not extendable http://icecream.me/4a78eefd13585dbb3f65478752f1933d?

You now have to call B:ConfusedomeFunction() instead of A:ConfusedomeFunction() - that's not extending.
Reply
#50

Thanks @Narf @arma7x. Hope this thread is enough to help CI4 to have better features.
Long live CodeIgniter!
Reply




Theme © iAndrew 2016 - Forum software by © MyBB