SitePoint Sponsor

User Tag List

Results 1 to 20 of 20
  1. #1
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Whether to use CONSTANTS...

    Recently, I started using CONSTANTS in my website, and so far they have been a welcome addition.

    But now I am seeing one downside which I'll describe in a minute...


    In my "change-details.php" script, I have one constant called BIO_MAX which defines the number of characters Users can use to describe themselves...
    PHP Code:
        if ($bioLength <= BIO_MAX){
            
    // Valid Bio.
            // Continue processing...

        
    }else{
            
    // Invalid Bio.
            
    $errors['bio'] = "Your Bio cannot exceed " BIO_MAX " characters. &nbsp; &nbsp;"
                                
    "Your answer is " number_format($bioLength) . " characters.";
        }

    I was thinking of using this same coding style for the rest of my "User Profile" form, however, here is a "catch" that makes me wonder if Constants are such a good idea in a place like this after all...


    In my database, I defined "user-bio" as VARCHAR(1024), so, if I only ever want to make this field *smaller*, then only having to update ONE CONSTANT is great.

    However, the minute I forget about the Database, and accidentally give my long-winded Users 2,048 Characters - via BIO_MAX - to describe themselves, then all of that extra text will be lost?!


    Some of you will say, "Well, Debbie, just don't forget!!" To which I'd say, "Program so you don't have to remember!"


    My thinking is this...

    Constants are great, but to assign a Field-Length Constant to every field in my "User Details" page might cause more headaches than just hard-coding field lengths.

    There are Pros and Cons to each approach.


    What do you think about the scenario I just described?

    Sincerely,


    Debbie

  2. #2
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,149
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    What do you think about the scenario I just described?
    That it has nothing to do with Constants... You could hard code the value of it and you have the same problem, but in all reality, it isn't really a problem. If you open up the limit without altering the database, you'll get a truncation error when you try to insert a value that exceeds the column size.

    If you test each change (like you should), you'll discover this issue and fix it before it goes live. Even if you don't get a truncation error, if you test (like you should), you should see the truncation occurring. Either way, this isn't an issue with how you coded things, it is an issue if you fail to test your changes properly.

  3. #3
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Perhaps the question is "how can I link my PHP code restraint (string length) dynamically to my database schema so that it only exists in one place?".

  4. #4
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    Perhaps the question is "how can I link my PHP code restraint (string length) dynamically to my database schema so that it only exists in one place?".
    I dunno.

    Sounds like you have an idea...


    Debbie

  5. #5
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,149
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    I dunno.

    Sounds like you have an idea...


    Debbie
    Not one that I would ever take seriously! That seems like a lot of overhead to me, I just don't buy that as a good solution. I don't know though, maybe there are people out there that do this, I for one wouldn't.

  6. #6
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    That it has nothing to do with Constants... You could hard code the value of it and you have the same problem, but in all reality, it isn't really a problem. If you open up the limit without altering the database, you'll get a truncation error when you try to insert a value that exceeds the column size.

    If you test each change (like you should), you'll discover this issue and fix it before it goes live. Even if you don't get a truncation error, if you test (like you should), you should see the truncation occurring. Either way, this isn't an issue with how you coded things, it is an issue if you fail to test your changes properly.
    Seems like a rather harsh response.

    When I remove the restrictions from my Form and enter a value which is too big, I get a success message, butt hings get truncated off. (No INSERT errors.)

    One main reason for "config.php" script is that it allows me to tweak things "on-the-fly". So while I *do* test things, the very nature of my "config.php" script kind of goes against formal testing.

    (I suppose down the road I could build a "Preferences Form" which takes my Constants and reconciles them against my Database, but that won't happen this go round...)


    Also, my bigger point was, "Is there a benefit to associating a Constant with tons of Field Lengths, versus just a few obvious ones (e.g. "Bio Length", "Private Message Length", etc.)??"

    Sincerely,


    Debbie

  7. #7
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,149
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    Seems like a rather harsh response.
    Do you disagree that it is a lack of testing issue?

    Quote Originally Posted by DoubleDee View Post
    When I remove the restrictions from my Form and enter a value which is too big, I get a success message, butt hings get truncated off. (No INSERT errors.)
    You likely don't have a few settings enabled that would offer this functionality.
    http://stackoverflow.com/questions/1...-error-setting

    Quote Originally Posted by DoubleDee View Post
    One main reason for "config.php" script is that it allows me to tweak things "on-the-fly". So while I *do* test things, the very nature of my "config.php" script kind of goes against formal testing.
    No it doesn't... That's an excuse for not wanting to test you alteration properly. From what I recall, I thought you used to be in QA? If a dev altered a configuration that was used in 6 parts of an application, would you not test all 6 parts and a few outside of those? You would. How is your own personal app any different?

    I make many changes each and every day, I also look at what my changes will likely impact, what they shouldn't impact, and I hand that information off to our BA so she can ensure that what I think will be affected agree with what the requirements show or if there are things I found that they didn't know about, they can react to those accordingly.

    Quote Originally Posted by DoubleDee View Post
    Also, my bigger point was, "Is there a benefit to associating a Constant with tons of Field Lengths, versus just a few obvious ones (e.g. "Bio Length", "Private Message Length", etc.)??"
    Since you are working in a procedural format, constants are one of your best answers. What are you alternatives? Hard Code it (reusability sucks, and you can't easily search for all places to change it), don't validate it, enable truncation errors (catch the error, process accordingly).

  8. #8
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    Do you disagree that it is a lack of testing issue?
    Yes, BUT like I said above... I think well-designed systems help you to not hang yourself.


    Quote Originally Posted by cpradio View Post
    You likely don't have a few settings enabled that would offer this functionality.
    http://stackoverflow.com/questions/1...-error-setting
    That looks like another v3.0 task...


    Quote Originally Posted by cpradio View Post
    No it doesn't... That's an excuse for not wanting to test you alteration properly.

    From what I recall, I thought you used to be in QA? If a dev altered a configuration that was used in 6 parts of an application, would you not test all 6 parts and a few outside of those? You would. How is your own personal app any different?
    No, actually I'm a BSA by day...

    I *do* try and test things. Heck, insane testing has added a YEAR onto my website. If anything, I test too much?!


    While I see (and agree) with your point, you are leaving out the fact that...

    1.) Sometimes Changes don't get QA'd in every place they need to be, thus things slip through. (That's the "Human Factor" and a big reality!)

    2.) If you make it *too easy* to change things without any safe guards, sometimes humans forget to QA or QA the right things. (It is why God created "Referential Integrity"! If you would just "test" everything, you'd never need Foreign Key constraints my friend...)


    Quote Originally Posted by cpradio View Post
    Since you are working in a procedural format, constants are one of your best answers. What are you alternatives? Hard Code it (reusability sucks, and you can't easily search for all places to change it), don't validate it, enable truncation errors (catch the error, process accordingly).
    Here are my thoughts for v2.0...

    Constants are beautiful, but like anything, should be used sparingly.

    My "private_message" table defines the PM Body as "Text", so creating a Constant called "PM_MAX" makes sense, and I don't have to QA anything, because I would choose some insanely large value for the length...


    By contract, my "member" table has a Profile field called "occupation" which is 40 characters. A Constant might be okay, BUT I have to remember if I change it from "40" to "60" to change the Database from VARCHAR(40) to VARCHAR(60)...


    I cannot stress enough that I am the "Queen of Testing" my own code.

    But I am also human, and humans make mistakes, and for me, I can possibly see myself changing "OCCUPATION_MAX" from "40" to "60" and forgetting to update the Database Table because *most* of my Constants do not touch the Database...

    (If I leave things hard-coded for "Occupation", then I won't have to worry about said mistake, because if I change *actual code* then I ALWAYS test the heck out of things!!!)

    Sounds lame, I'm sure. But just sayin...

    Sincerely,


    Debbie

  9. #9
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,149
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    No, actually I'm a BSA by day...
    Oops, my bad

    Quote Originally Posted by DoubleDee View Post
    While I see (and agree) with your point, you are leaving out the fact that...

    1.) Sometimes Changes don't get QA'd in every place they need to be, thus things slip through. (That's the "Human Factor" and a big reality!)
    Sure, but then you fix them, test them, and deploy them. You can always look at integration tests too that run continuously so as changes are made, if it negatively impacts an existing test, that test will break.

    Quote Originally Posted by DoubleDee View Post
    2.) If you make it *too easy* to change things without any safe guards, sometimes humans forget to QA or QA the right things. (It is why God created "Referential Integrity"! If you would just "test" everything, you'd never need Foreign Key constraints my friend...)
    No, that comparison is flawed. Referential Integrity is a validation technique, not a QA technique. It simply validates what is provided is valid. It doesn't prove that part of the system works as designed.

    Quote Originally Posted by DoubleDee View Post
    Constants are beautiful, but like anything, should be used sparingly.
    I can agree with this.

    Quote Originally Posted by DoubleDee View Post
    My "private_message" table defines the PM Body as "Text", so creating a Constant called "PM_MAX" makes sense, and I don't have to QA anything, because I would choose some insanely large value for the length...
    I adamantly disagree with this. You should test everything! No matter how obscure the value is, it should be tested against.

    Quote Originally Posted by DoubleDee View Post
    By contract, my "member" table has a Profile field called "occupation" which is 40 characters. A Constant might be okay, BUT I have to remember if I change it from "40" to "60" to change the Database from VARCHAR(40) to VARCHAR(60)...
    Create documentation of the requirements so when you do make the change, go to your documentation, see that it affects a table as well, and ta da! Or test it... (or both)

    Quote Originally Posted by DoubleDee View Post
    But I am also human, and humans make mistakes, and for me, I can possibly see myself changing "OCCUPATION_MAX" from "40" to "60" and forgetting to update the Database Table because *most* of my Constants do not touch the Database...
    Of course, which is why you should test your changes. If you are going to edit anything, be sure you know what it affects before doing so. Otherwise, you'll be bug ridden in no time. Do a search for OCCUPATION_MAX throughout your project and be sure to hit all of those scenarios.

    Quote Originally Posted by DoubleDee View Post
    (If I leave things hard-coded for "Occupation", then I won't have to worry about said mistake, because if I change *actual code* then I ALWAYS test the heck out of things!!!)
    Not really, you just might forget to update one of the hard-coded locations. Try searching for 40 throughout your code and see how many false positives you might get. Or you may update the wrong location or not all locations. Plus hard coding still doesn't ensure you'll remember to update the column size...

  10. #10
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    cpradio to DoubleDee...

    1.) Always test your code and code changes.
    2.) Don't make any mistakes, or forget anything.
    3.) Problems solved!


    Gee, that was easy!!

    Sincerely,


    Debbie

  11. #11
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,149
    Mentioned
    152 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    cpradio to DoubleDee...

    1.) Always test your code and code changes.
    2.) Don't make any mistakes, or forget anything.
    3.) Problems solved!


    Gee, that was easy!!
    , You'll make mistakes, heck I still make a few (and QA has been good to catch a few of them; and others not so well -- but they were complicated edge cases). Simply put, there isn't a right or wrong to your question, but keep in mind, running a test against code you are altering is always to your benefit regardless of how simple the change was to make.

  12. #12
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    but keep in mind, running a test against code you are altering is always to your benefit regardless of how simple the change was to make.
    A good reminder, even for me!!

    Thanks,


    Debbie

  13. #13
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    17,185
    Mentioned
    191 Post(s)
    Tagged
    2 Thread(s)
    When something is fresh in my mind I tend to tell myself "I'll remember that". But I have learned that after I'm away from it for a while I can easily forget.

    That's why I have learned to use /*comments*/

    Nothing like seeing

    /* if this value is increased, ALTER the table */
    define("OCCUPATION_MAX", 40);

    to jog my memory.

  14. #14
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Mittineague View Post
    When something is fresh in my mind I tend to tell myself "I'll remember that". But I have learned that after I'm away from it for a while I can easily forget.

    That's why I have learned to use /*comments*/

    Nothing like seeing

    /* if this value is increased, ALTER the table */
    define("OCCUPATION_MAX", 40);

    to jog my memory.
    Another good idea.

    Thanks,


    Debbie

  15. #15
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,151
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Not to mention in the real world there are going to be multiple hands on a project. No one is going to know what you know unless they have some sort of documention or comments as already described. One of the worse things in programming is to inherit some project from an incompetent developer who didn't know how to comment or write documentation or at the worse code / normalize a db. I know that is not relevant in your case but it is a real problem when dealing with projects that have hit multiple hands. In the real world of clients (besides yourself) it is not unordinary to come across project that have had over ten or twenty different developers. Each one one with a different skill level… which is why testing/QA is important. You never know what you might run into with others poor decisions/lack or foresight. Which is why it is important to test and have proper QA procedures set-up. Just saying… I know you are a one women army but that is not how it works in the real world.
    The only code I hate more than my own is everyone else's.

  16. #16
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    Which is why it is important to test and have proper QA procedures set-up. Just saying… I know you are a one women army but that is not how it works in the real world.
    Sir, yes Sir!!

    Getting to work on the Constant Comments and updated Documentation immediately, Sir!!


    (All of this advice and wisdom everyone at SitePoint has been subjecting me to over the last 3 years will either make me one hell of a Developer with one hell of an impressive website, OR kill me!!)

    Thanks,


    Debbie

  17. #17
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    I dunno.

    Sounds like you have an idea...


    Debbie
    I might have an idea, but I was actually just paraphrasing your original question, and no, I do not have the answer to that question by the way.

    So this might then be viewed as a question on how to manage that part of your Model code which talks directly to your database.

    AFAICT, most popular Frameworks data access is governed by config files, ini files and the like.

    In one direction they are picked up and used by the Model, but in the other direction they could be used by the View.

    this is a snippet from an ini file from a framework wot I made myself a few years ago...

    It matches one ini file to one table.

    Code:
    ; Bootstrap file for simple models
    ; Options for PDO are : INT STR NULL BOOL LOB
    ; params : PDO - field_type - size - HTML_Label
    
    [attributes]
    	
    id				= INT
    title		 		= STR-text-40-Title 
    
    // loads redacted here
    
    descrip		 	= STR-textarea-2000-Description
    These values are extracted for data verification in one way (Model-ish), and for HTML form generation in the other (View)

    In light of the above conversation about testing, I don't suppose it would be impossible to check the value in a config file against the db schema when a test suite is run.

    Whether it would be worth the sweat is of course as said, debatable.

    In light of the example I posted I suppose a lower level question really ought to be, "how is it that my view is able to send data to my database that has not passed some kind of verification?"

    The example illustrated still does not do away with a hardcoded value for the length of the description, but at least sticks it in one place so you could reasonably check it vs your db schema on demand.

    Maybe this is by the by -- and only relevant if your question was mainly concerned with the development stage -- but I found this SP article on Redbean fascinating and though I leafed through the Redbean docs at the time and saw no mention of its power when matched with Unit Testing, it would seem a good match.

  18. #18
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,838
    Mentioned
    73 Post(s)
    Tagged
    6 Thread(s)
    Debbie, try using a MVC approach where the raw View data is passed to a Model.

    The Model is best thought of as a third-party external process with no access to the code and either saves or returns messages relating to invalid data.
    Learn how to be ready for The New Move to Discourse

    How to make Make Money Now with a *NEW* look

    Be sure to congratulate Patche on earning Member of the Month for July 2014

  19. #19
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by John_Betong View Post
    Debbie, try using a MVC approach where the raw View data is passed to a Model.

    The Model is best thought of as a third-party external process with no access to the code and either saves or returns messages relating to invalid data.
    Sorry, but you and Cups are way out of my league on the last two posts.

    Maybe someday I will learn OOP and MVC anc can d such things, but for now - and this thread - I am leaving my code as-is!!

    Constants for things like PM Length or Bio Length where the DB Field is Text and I can tweak the length without having to touch the database, and hard-coded - for now - for fields like "PM Subject" where I really have no business changing that after it is built.

    Sincerely,


    Debbie

  20. #20
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,838
    Mentioned
    73 Post(s)
    Tagged
    6 Thread(s)
    OK if the MVC approach is too daunting then consider sending your raw user input data to a catch-all function that either returns TRUE on success or a text message detailing why the data could not be saved.
    Learn how to be ready for The New Move to Discourse

    How to make Make Money Now with a *NEW* look

    Be sure to congratulate Patche on earning Member of the Month for July 2014


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •