There normally should be no reason to not allow any character in a password, since you're going to be hashing it anyway, right? And you'll be using prepared statements, DB abstraction layer, or simply applying the appropriate SQL escape mechanism to avoid SQL injection, right? (I might disallow newlines, carriage returns, and a few other non-printing characters that a normal user should not be able to enter via a password field anyway, but wouldn't loose sleep over it if I didn't.)
For #3, you could make a callback function that would validate against your white list of allowed country names, and use that in the CI Form Validation library
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Ugh, I haven't slept well in days and I'm so tired its hard to think. I'm here, so I can borrow some of you guy's brain power.
Is there anything inherently wrong with this code? It accepts a multidimensional array that is a simple array with arrays in it, each subarray has the keys "option" and "value". At least I think that's what's going on. I'm so tired
PHP Code:
public function implode_options($main_array) { $acceptable = array();
foreach ($main_array as $sub_array) { foreach ($sub_array as $value) { //print $value['field_name'].' '.$value['option'].'<br />';
Why are you doing that kind of regular expression in a password? The only time regexp in passwords is usefull is when you're enforcing password strength.. ie; atleast 1 uppercase, atleast 1 letter, atleast 1 symbol and so on.. That check is just pointless
You can allow whatever you want in a password, because it SHOULD BE encoded/hashed before it even hits the database.
With forms you just check if it's a remote request, or add in session checks on forms. If it's remote you can do basic checks like if ! in_array ($this->user->post("country"), $country_array) ) nogood..
having data in a xml file dealing with php is just added work it doesn't have to do, php and xml parsing is terrible, if you control it theres no reason to store data in xml that you will be querying. Store those in arrays in a file or serialized arrays in a database
libraries are standalone, they shouldnt depend on models, controllers, etc. models/controllers depend on libraries though... so yes you can put database calls in libraries
Ugh, I haven't slept well in days and I'm so tired its hard to think. I'm here, so I can borrow some of you guy's brain power.
Is there anything inherently wrong with this code? It accepts a multidimensional array that is a simple array with arrays in it, each subarray has the keys "option" and "value". At least I think that's what's going on. I'm so tired
...
I'm not sure what the correct answer is since I neither know for sure what the source array is nor what exactly you want to do with it. However, I will point out one foreach() "trick": if you use this format...
PHP Code:
foreach($arrayName as $key => $value) { ... }
...you now have access to both the array key and array value being processed in each iteration of that loop, which might help you out.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Is it possible to create an entirely new helper in CodeIgniter, you know, without "extending" an existing one? I've tried to make an entirely new helper in the file MY_message_helper.php, but when I try to load it into a script with $this->load->helper('MY_message_helper'), or $this->load->helper('message_helper'), I get an error like this:
Unable to load the requested file: helpers/my_message_helper.php
I have the file in application/helpers so I don't know why CI can't find it.
The better I get at programming, the more I appreciate arrays. Handy dandy things they are.
I'm pretty sure it's possible, but don't recall how off the top of my head, though I suspect you may have to lose the "MY_" part of the file name, as I think that's telling CI that you are extending a "Message" helper in this case.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Helpers are just functions, IIRC, so it would not make sense to use $this within the actual function definitions. Also, in general they should probably be application agnostic (my obfuscated way of saying "re-usable"), so they should not even "know" what view any given app might want to use in any given situation. It may be that you want to invoke that function from within your view, perhaps, in which case there would be no need to invoke a view?
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Hmm, how do you think I should go about designing the code to display the box for my messages to appear in? My general idea is it would be something I could include and feed a variable or two into, like with that HTML table I posted in my last reply.
The better I get at programming, the more I appreciate arrays. Handy dandy things they are.
If it only applies to one view, then I would just code it in that view (using data sent to it by the controller). If the same thing needs to be done in multiple views, then I would create a helper function which accepts the data as one of its parameters, then call that function from within each applicable view. In this case the helper function might actually generate the HTML (so it would not be out of place if you wanted to add it to the HTML helper).
<?php
if(isset($someVar) and is_array($someVar)) {
echo example($someVar);
}
?>
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Hey guys, I wanted to know how you would personally handle the following things:
#1 My signup form has three <select> fields for entering your birth date. One where you enter your birth month, one for birth day, and the other for birth year. Currently it is the controller that puts this together into one YYYY-MM-DD string. I was wondering, though, if this would be better done in the model?
#2 I'm wondering if I can delete uneeded data from the database to increase performance.
Great example: My "user_accounts" table has a column for the activation code. After an account is activated, the activation code is no longer needed. At such time, if I deleted the activation code by changing it to NULL, would performance be increased?
Or would it not matter because the activation code column is still present?
#3 I wonder if I could improve database performance by splitting tables into frequently and infrequently accessed information.
Good example: My "user_accounts" table. You see, only a bit of a user's information is accessed frequently, like their display name and staff ranking--to elaborate on the latter, many places in the site will see if a user is on the staff, because if they are, it will show moderation tools. The default staff ranking is 0.
Anyway, what if I had a user table with just the user ID, display name, staff ranking, and a couple other things in it, and then had another table for less frequently accessed things like password (only used during login), country (only displayed on profile or forum posts), gender (ditto), age (only displayed on profile), etc.
Do you think is a good idea?
Last edited by evenstar7139; 09-01-2012 at 07:00 PM.
The better I get at programming, the more I appreciate arrays. Handy dandy things they are.
#1: Probably makes sense in the controller, as it helps keep the view separated from the business logic in the model.
#2 and #3: If (a) your tables columns which need indexing are properly indexed and (b) your SELECT clauses do not include any columns you don't actually need, then I doubt you would find any noticeable (if at all) performance enhancements. (Modern RDBMS's, contrary to what some people seem to think, are really quite efficient and fast -- as long as you use them correctly. )
Now, I suppose if some varchar field's data is no longer needed and you change it to null, you'll (possibly) save a few bytes of disk space per affected row; but disk space is so darned cheap today that you probably don't even need to think about that except in extreme cases.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
#1 So then, it's okay to have the controller do some data manipulation? BTW here is the code that makes the one sting out of the three birth date inputs:
#2 & 3 So then, the way one decides what columns to put in a table should be by thinking about what should logically be included? What if, logically, it made sense to have over 100 columns in my "user_accounts" table? Wouldn't it still be better to find a way to divide the columns up? I'm just pulling the following out of my head but maybe I could do kind of like this: "users_main" for general user information, "users_home" to store information about the user's house in the game, "users_preferences" for site prefs, etc.
Last edited by evenstar7139; 09-01-2012 at 08:01 PM.
The better I get at programming, the more I appreciate arrays. Handy dandy things they are.
Bookmarks