Jump to content

Muddy_Funster

Members
 View Profile  See their activity

  • Posts

    3,372

  • Joined

  • Last visited

  • Days Won

    18

 Content Type 

Everything posted by Muddy_Funster

  1. Muddy_Funster
    My Opinion:- menu items, and also form elements, should never have a fluid size, they should always be fixed dimensions. If you want to you can wrap them in a responsive container but the items themselves should be static. If you are having issues with CSS conflicts then I would say you need to either clearly define CSS by element using IDs rather than classes and assigning any questionable attributes fully to bypass inheritance or, preferably, map out your inheritance model and apply granular CSS attributes that are appropriate to the level of the elements in the DOM tree so that only relevant attributes are assigned at appropriate levels. Here's some links to help with what I'm talking about: https://www.w3.org/TR/CSS2/cascade.html https://www.smashingmagazine.com/2010/04/css-specificity-and-inheritance/
  2. Muddy_Funster
    The boards here allow you to edit as many times as you like, but only within a certain time limit. The issue isn't a Mac issue as far as I am aware - it's unlikely that the underlying OS would have much influence on the rendering of third party browser software. The issue is documented however, primarily with regards to IE7 and 8, and the Google Fonts Getting Started Page explains the following: So yeah, the actual fix is to link properly to the all the fonts, styles and weights that you intend to use.
  3. Muddy_Funster
    I've done a re-write on your code from the OP. Most significant change is swapping out the multiple if statements for a switch/case. This doesn't really change what the code was doing, both ways are equally acceptable, I just felt that this was a good example of when you could choose to use a switch over a bunch of ifs. Switch statements have the benefit of breaking out when the condition is met, so over larger checks it can save a bunch of processing by not parsing every value against every condition every time. Another change is that I have added the table rendering code within the initial while loop. Loops are right up there with the most performance draining aspects of any code and keeping them to a minimum is always a good idea. I don't honestly know if this will fix your issue, not do I expect this to just run. Read through the code and make sure you can understand it all then see what it does when you apply it to your setup. <?php session_start(); include("config.php"); function showColor($n){ switch ($n){ case 1: $code = array("color" => "red", "word" => "Low"); break; case 2: $code = array("color" => "green", "word" => "Medium"); break; case 3: $code = array("color" => "blue", "word" => "High"); break; case 4: $code = array("color" => "orange", "word" => "Very High"); break; case 5: $code = array("color" => "violet", "word" => "Extremely High!"); break; default: $code = array("color" => "black", "word" => "Standard"); } return $code; } $sql = "SELECT Scholarships AS colorCode FROM " . $SETTINGS["data_table"] . " WHERE id>0 LIMIT 10"; $sql_result = mysql_query($sql, $connection) or die('request "Could not execute SQL query" ' . $sql); $cTable = ""; if (mysql_num_rows($sql_result) > 0) { while ($row = mysql_fetch_assoc($sql_result)) { $thisColor = showColor($row["colorCode"]); $cTable .= "<tr><td style='color:{$thisColor['color']}>{$thisColor['word']}</td></tr>"; } } else { $cTable .= "<tr><td>No Results</td></tr>"; } $htmlHead = <<<HTML_HEADING <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>Show color</title> </head> <body> HTML_HEADING; $htmlBody = <<<HTML_BODY <div> <table style="width:191px;"> <tr><th>ColorKey</th></tr> HTML_BODY; $htmlBody .= $cTable; $htmlBody .= "</table></div></body></html>"; echo $htmlHead; echo $htmlBody; ?>
  4. Muddy_Funster
    No, I don't think you are, but what you are doing is coming across as though you are assuming that the style that fits your way of coding and your requirements is always going to be better than any other, regardless of the situation or individual. Which isn't really true. Sometimes, for example when information is sent by ajax request as @requenix already suggested, there may not be a requirement to check specific values in the $_POST array, but still having a requirement to check that the $_POST method was called and reacting appropriately. I personally check against field values - never buttons admittedly - to make sure they are valid (that they are not empty and contain appropriate data for the field context), but I can envisage scenarios that I don't currently program for where that wouldn't necessarily be the best way to handle things, particularly when consuming data from a mobile app for example. I would say it really depends on both how comfortable the coder is with the validity of the POST data before it gets to the script and the context of the interaction between client side and server side. That's just my opinion on the matter however, and I have been proven to be quite wrong with that on numerous occasions
  5. Muddy_Funster
    I personally would say "It depends". The complexity of validation is directly proportional to the paranoia of the writer sensitivity of the data. It depends on what you really want to validate: checking the method is quick and easy if you don't care about valid form field values being passed along with it. If you want to make sure that one or more fields have valid data, then you're just as well to check against relevant $_POST superglobal entry, since you are going to be running validation against the contents anyway as part of your existing validation. Just my opinion.
  6. Muddy_Funster
    Using SELECT * has a couple of issues - not as many as it used to, but it's still generally considered bad practice. When you use SELECT * relinquish a certain amount of control over the dataset that you get back from the server. This means that you always values for every column returned from the query. This means that - barring very limited exceptions - you are creating a result set that contains columns that you at best don't need and at worst can create a vulnerability in your process. There is rarely a need to include the UUID of a record in a reporting query, and I argue that there is never a use case for returning the contents of a password column. So SELECT * = inefficient for the vast majority of queries. This inefficiency grows any time there is a alteration to the table that increases the number of columns in the table. While functionality evolves and can cause core back-end data tables to require additional columns in order to facilitate new functionality, it is just as common that the initial functionality will still be used as is, but now the queries are pulling back even more redundant data. As well as this, when you start to build more complex queries you will find that using SELECT * is not only inefficient, but that it is counter intuitive to writing queries that are understandable. When you select the column names specifically you are able to apply aliases to them: this gives the potential to make the whole query more understandable. Another reason is readability. If you go back to code that you wrote 8 months or a year ago and you have listed all the columns that are being taken then you can work out rather quickly what you were doing with that query back when you wrote it. Then there's the fact that it makes it easier for others to read your code as well: large projects call for multiple pairs of hands or else by the time they are complete the program is either redundant or in need of immediate upgrade; sometimes you need to ask for help, and if the columns are listed in the query those looking that the query can identify better what they are dealing with. Not using SELECT * also makes consistency across your code much easier. If you use a specific naming convention in your scripting you can apply aliases to the column names that conform with this convention when you select each of them rather than having to count on the column names themselves matching - meaning that you can keep your actual column names relevant to the database, and the selected column names relevant to the script. One of the biggest issues with SELECT * used to be that it basically ignored indexed columns altogether, which was a huge performance issue - I'm pretty sure this was fixed a couple of years ago but, as I haven't used SELECT * on a table in a long, long while I can't say for sure. There are two occasions where using SELECT * is more or less acceptable : 1) Debugging a tables dataset and 2) When querying a View rather than a Table.
  7. Muddy_Funster
    for debugging try adding the following in where you are trying to echo out the $row[$programtype]: if(array_key_exists($programtype, $row)){ echo $row[$programtype]; } else{ echo $programtype." Was not found as an array key.<br>"; var_dump($programtype); echo"<br><pre>"; var_dump($row); echo"</pre>"; } This should show you the contents and overall string length of $programtype and also the key value pairs of $row array, letting you visually asses if there are any differences. Also note that, as you are working with a php array and not directly with the MySQL table reference, case sensitivity is in effect.
  8. Muddy_Funster
    I'm not sure what resource you are using to pick up php bit it looks to be painfully out of date. I read your last post and seen that you were planning to move to mysqli_ after getting the mysql_ code you were using working, but now you have shown that you're using quite a number of mysql_ requests. I'd like to say: please, stop now. You are just giving yourself a load of extra work writing new code that you know you are going to have to rewrite anyway. That out of the way - what do you mean "it never works"? what's your table structure? do you have a column name in your table that matches the value in $programtype?
  9. Muddy_Funster
    You would be better starting a new thread for this, but basically you're just using the $Scholerships array instead of the $row array - so for example, assuming you have column names "fistName, lastName, enroleDate, colorCode" you can do the following: foreach($Scholership as $record){ $tableRow = <<<TABLE_ROW <tr style="color:{$record['colorCode']}"><td>{$record['firstName']}</td><td>{$record['lastName']}</td><td>{$record['enroleDate']}</td></tr> TABLE_ROW; echo $tableRow; } This obviously doesn't connect with the code that @QuickOldCar has already provided and isn't meant as anything more than an example of how you can handle the information in the array. Also - I would like to take this chance to discourage you from using SELECT * for queries, name each column that you are retrieving from the table.
  10. Muddy_Funster
    If you are asking whether or not you can process different parts of the same form using different destination script pages by setting multiple destinations and allocating different form parts to them then yes, you can, but not without implementing some client side script such as javascript. If you have two different script pages designed to process different aspects of the form data and are loath to copy from one to another you can include the other script page in the destination script page and it will "technically" be that different php pages are processing different parts of the form. Although I'm completely with @gingerjm on this one - there is no obvious reason to split this across multiple scripts: it's a single, simple task.
  11. Muddy_Funster
    I presume this is for a personal / hobby based machine and not for a professional endeavour? Because if you are earning a wage while doing this it would very quickly become more cost effective to just buy a new box and use that than pay you an hourly to muddle through an age old system and create a redundant script just to utilise a near-death piece of hardware. Another option would be to curl a page on a newer server that can do the functions that you need and just manipulate the results provided by that, but then you would have to question why not just use the newer server for the whole process?
  12. Muddy_Funster
    Just some learning tips: It's quite common when people are starting up in ajax for them to get a bit confused about how and when to call aspects of the general page code. Because ajax works outside the normal code flow it can be easy to forget that anything and everything that you want to be performed as a direct result of the ajax call must be included within the callback. For learning purposes I personally found it quite helpful to name the anonymous callback function to help remind me of the fact and got into the habit of using names such as: $.ajax({ ... success: function everythingAfterDBSelect(data){ ... } }) It's also worth saying that you can call existing page functions from within the callback as well, this can help keep the page code be a bit more readable as you can still group formatting code in the same area of the document, just within a function, and then call that function from the ajax callback to apply the formatting.
  13. Muddy_Funster
    I didn't say JS was the best way to do it, I was just pointing out that PHP may not be be part of this exact problem. Without knowing the context of the issue experienced, or the reasons why it is an issue it the first place, it can't be discerned how stupid the fix really is. What if the form is loaded in through ajax from an external site that the OP does not administer? What if the page is part of an admin console that is designed to apply a standardised formatting to user created form elements? Again, not the best way to accomplish the latter, but certainly not a "stupid" one either. Besides, I thought the point was to help people, not judge them?
  14. Muddy_Funster
    Maybe it's a static HTML file, I didn't notice anything in the OP that said they were connecting to PHP. for jquery solution you will want to use the each() function. eg. <!-- HTML --> <select id="method"> <option value="option 1">Option one</option> <option value="option 2">Option two</option> <option value="option 3">Option three</option> </select> <!-- END HTML --> //JQuery JS $(document).ready(function () { $('#method > option').each(function(){ var str = $(this).attr("value"); str = str.replace(/\s+/g, "-"); $(this).attr("value",str); }); }); //END JQuery JS
  15. Muddy_Funster
    I'm still not 100% on what you're doing with this, but this bit: Sounds like you just want a JOIN in your UPDATE query. Something similar to this: UPDATE player_table LEFT JOIN deck_table ON (player_table.playerID = deck_table.playerID) SET (deck_table.col1 = ?)... WHERE player_table.playerID = ? I'm not convinced the two split arrays is the best way to maintain data integrity between sites, it would be much better if you could get it through as either a single associative array, a JSON object or as XML. This would help ensure that the relative deck ID has the correct card amount attached to it before it gets sent to the DB.
  16. Muddy_Funster
    I would expect that, as any given user ID can be associated with multiple comments, the answer would likely be no. This should probably be in the Other Libraries and Frameworks section as it would be better answered by someone with knowledge of that specific API rather than PHP in general.
  17. Muddy_Funster
    You don't have any loops to be getting stuck in. How about a better explanation of what's actually happening when you run it. On a side note: There is absolutely no point in checking all those isset()'s because you actually set every one of them 10 lines above where you are checking them. And you really should use a Regular Expression check to sense-check the email address. There are plenty of drop in code snips for this available online.
  18. Muddy_Funster
    Another option would be to use one of the miriad eCommerce programs that already exist and save yourself from reinventing the wheel. Writing an app that handles taking money from the public is not what anyone would grade as an Entry Point programming task. If you get it wrong you could be looking at some serious fallout and even, in extreme cases, criminal charges.
  19. Muddy_Funster
    Hi, could you please use code tags? Also, I'm guessing the js that applies your slider is in js/slider.js - the contents of which you haven't posted. What are you using to write your code in and what are you using to debug? P.S. DOM element tags are case sensitive so "Nav" is not the same as "nav"...
  20. Muddy_Funster
    It's not a menu element, but an adaptation on this may help you?
  21. Muddy_Funster
    could you post the results of doing a DESCRIBE on each table?
  22. Muddy_Funster
    Something like the following: <form id="myForm"> <input id="actualprice" type="number" placeholder="Actual Price"> <input id="discount" type="number" placeholder="Discount"> <input id="shipping" type="number" placeholder="Shipping"> <input id="total" type="text" name="totalamount" disabled="disabled" /> <input type="submit" value="Submit"> </form> <h3 id="result"></h3> <script> $('#myForm>input').on('keyup', function () { var actualprice = Number($("#actualprice").val().trim()); var discount = Number($("#discount").val().trim()); var shipping = Number($("#shipping").val().trim()); var discountRate = (100 - discount) / 100; var result = (actualprice * discountRate) + shipping; $("#total").val("Result :" + result.toFixed(2)); }); </script>
  23. Muddy_Funster
    seems some people don't really want help, just answers.
  24. Muddy_Funster
    You're coming at this all wrong. The scenario you described is fundamentally the wrong thing to do. Why don't you give us the information relating to what you're actually look to accomplish with this and maybe we can give you a better solution.
  25. Muddy_Funster
    You need to change the display on the child of the samples class - for both normal and hover display. See this fiddle for an example.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.