| Helpers and Other Conventions |
(06-30-2016, 11:28 AM)ciadmin Wrote: @ivantcholakov: I jumped the gun here, with my point #2. Narf was kind enough to point out that the style guide, with no namespaces and with snake case for functions, was indeed purposeful and appropriate,. It looks like the decisions revolve around which helpers are useful, and how they should be built into the framework.
James Parry
Project Lead (07-01-2016, 03:16 PM)prezire Wrote: Just see other frameworks' helper functions list: Thank you for these links ... interesting. Laravel does have helpers, similar to CI3's. Theirs seem to be defined in a single file, Illumindate/Foundation/helpers.php, which is different from what we have done. Theirs also appear to be automatically loaded, and universally available. I had trouble wrapping my head around a direct comparison between CI and the Ruby helpers, though theirs seem similar in intent to ours. Symfony & Cake have "helpers", yes, but they are classes with the word Helper as part of their name. They seem to serve the same intent as our helpers, but they are classes, with non-static methods. Hmmm.
James Parry
Project Lead
Further to the helper discussion, CI4 already has some helpers built in: system/Common.php
These include cache, csrf_hash, csrf_token, esc, force_https, helper (!), and so on. They are mentioned in the "overview/services" page in the user guide, and in the "general topics/helpers" page.
James Parry
Project Lead
Speaking for myself, I would really miss the CodeIgniter helpers. The way they are in CodeIgniter 3 looks good to me - not empty and not "fat". Just to help me with basic common things. And yes, I am using them in every of my projects (I mean helpers that PaulID mentioned in post #41 of this topic).
@Muzikant Good to know having a second opinion about old helpers being useful, and still will be in the future.
@jlp Laravel's single file helper scares me. CI3 helper structure is good. The way they're loaded manually via singleton helps me sleep at night  I believe Rails loads all helpers automatically but I don't know how they're organized underneath.Helpers as classes with non-static methods, I'd vote for it as a big no-no. As for the camelCase vs snake_case, I just gave it a shot and hoped you guys would find it interesting Although snake_case does make templating look fancy. Something like: {{ base_url() }} instead of {{ baseUrl() }}.Going back to Laravel, version 5.2 implements Form + HTML helpers as a separate project (to which again, I wouldn't prefer) https://laravelcollective.com/docs/5.2/html. Try Googling "laravel 5.2 form and html helper" and you'll soon see that non-out-of-the-box package implementation comes with a lot of complaints in it. If CI4 relies heavily on Composer on its features, it's going to look like a mashu-up of things.
Long live CodeIgniter!
This is just my input on the matter. Overall, I feel like some need to be re-evaluated and I think it would be preferable to have libraries instead of helpers in cases where helpers define a large number of functions.
I use the following helpers: Cookie Helper: - I probably use all of the functions in this helper in a small number of files within my site, and could probably use local methods or a small library instead. Date Helper: - I use timezone_menu(), but it probably doesn't belong in the date helper (given that it's generating an HTML select element). - Almost any other function in this helper has been targeted for removal in my site because they tend to be more difficult to use than DateTime Directory Helper: - directory_map() is extremely limited in its usefulness, but is very useful in those instances. On the other hand, I haven't gotten around to fixing any of the methods which used to CI2 version of this function, so everything in my site that uses this helper is using an extended version of the helper with a second function to provide the CI2 version. Download Helper: - I've used force_download() on a couple of occasions, but it's amazing how often people post questions here which are solved by using this function... File Helper: - I find this pretty useful, but I think it could be combined with the Directory Helper, possibly into a library, to give us a better way to handle files and directories Form Helper: - I primarily use form_open(), the set_* functions, form_error(), and validation_errors() - I go back and forth on using form_close(), since I have no reason to use it other than aesthetics/balancing the use of form_open() - most of the other functions are too problematic Language Helper: - I use this all the time, but did find, in one particularly unusual case, that it was more efficient to use $this->lang->line(). - I don't think my site includes any instances of using the 2nd/3rd arguments to the lang() function, as I would generally pass the output of lang() to my label (in rare cases using form_label()), and I don't really see a good reason for the language helper to generate labels, anyway. Number Helper: - Though I've used byte_format(), it has pretty limited use, and I've worked with plenty of people who would scream over using 1024 bytes per kilobyte vs. 1000, and I wonder whether there is some circumstance in which tacking the units onto the end creates an internationalization issue. URL Helper: - I use site_url(), current_url(), and redirect() a lot, url_title() and prep_url() somewhat less - I use the anchor() and mailto() functions more than I probably should Some notes on others: Array Helper: - two of the three functions are one-liners Email Helper: - a deprecated valid_email() function which is less robust than Form_validation->valid_email() - a deprecated send_email() function which calls mail() with the same arguments in the same order... - clearly, if there's a use for an Email Helper, this one missed the mark HTML Helper: - Once upon a time I used meta(), and doctype() could have been useful in the pre-HTML5 days, but I don't find any of these useful in their current form. - I actually like the idea of generating HTML from PHP, but I don't have any good ideas about how to do this in a useful way. Inflector Helper: - This is actually tremendously useful when you need it, but the usefulness is limited, especially as it's currently limited primarily to English Path Helper: - I don't know if I've ever had a use for this in which I wasn't also using the Directory or File Helper. - The function name (set_realpath) doesn't make any sense to me. Security Helper: - This could probably be very useful with some cleanup and some evaluation of possible additions. String/Text/Typography Helpers: - I usually have to look up the functions in each of these to determine which one I actually need, and sometimes end up having to use a combination of them. - I probably use the Text Helper the most, in part because the more useful String Helper functions don't come to mind when I might have a use for them. XML Helper: - If this is kept, it should probably just call htmlentities() with ENT_XML1 (and the other relevant flags).
@mwhitney Thank you for the comprehensive list
 Thank you all, for input on the topic of helpers! Helpers that are not planned to migrate from CI3 to CI4: captcha, email, smiley The other helpers should find their way into CI4, over time, starting with the url_helper. We will raise an issue on github for each of the helpers, with an indication of what is planned, as we are ready to implement them. There may be further discussion on the forum, in the "feature requests" section, for some of these.
James Parry
Project Lead
IMO valid_email() should not be deprecated, I doubt that filter_var($address, FILTER_VALIDATE_EMAIL) covers possible valid values like these that include international domain names.
(07-11-2016, 02:05 PM)mwhitney Wrote: This is just my input on the matter. Overall, I feel like some need to be re-evaluated and I think it would be preferable to have libraries instead of helpers in cases where helpers define a large number of functions. Cool. If there's any way Carbon could be integrated to CI4 as a replacement for the Date Helper, it would be nice. IMO most of the existing helpers are good. And could be better if we add more.
Long live CodeIgniter!
|
| Welcome Guest, Not a member yet? Register Sign In |
