Jump to content

maxxd

Gurus
  • Posts

    1,661
  • Joined

  • Last visited

  • Days Won

    52

Posts posted by maxxd

  1. Things like database connections, configuration files, and ... well, honestly any functionality file, be it a class or function sheet, should be exactly where you put it. The idea of a database connection file being in one of two places is a bit scary - that means it could be within the webroot, where it's viewable under the right circumstances, or it could be above the webroot, where it's not. And - most importantly - your application doesn't know which it is. Needless to say, above the webroot is better.

     

    How it's accessed from there depends on your system - if you're using a front controller pattern with a routing system, for instance, everything is going through a single entry point - index.php in the main webroot. From there, you always know where your includes directory is ('../includes/'). If you're using separate files for each page and serving them from within separate directories, then you'll have to do a bit more calculation to get it. However, if you're still using this style, you're probably duplicating a bit of code and content already, so it shouldn't add too much to your current overhead.

  2. The logic flow of your script is correct.

     

    However, right now it's wide-open to several different types of attack. You're using MySQLi, which is a good start - look into using prepared statements. I'm also questioning your logic on the connection script include - at what point would it not be where you expect it to be (one directory up), and if it's not, how do you know it's in the current directory?

  3. Start here.

     

    Basically, you write your php script that validates and sanitizes user-supplied data, runs an update on the database with that data, then prints a JSON-encoded result string - this script is a separate file on the web server from the file you're using to display the task list. On the task list display, you'll set up a .click() event on the completed button that will create the AJAX request, gather the record ID to be updated from the displayed page (usually a data-* attribute on the button), send the data to the php script, then read and parse the return string to see if the process was successful or not.

  4. @greenace92 - that's just my own personal preference (and bias, quite honestly). One of the things I like about OOP is the ability to black-box functionality. A class's public property can be changed from anywhere, whereas a private property can only be modified from within it's own class. So, if I write this:

    /**
     *    @var    string|null        description
     */
    public $myInteger;
    
    /**
     *    class constructor
     */
        public function __construct(){
            $this->myInteger = 2;
        }
    
    /**
     *    yadda yadda
     */
        public function multiplyIt($yourInteger){
            return $yourInteger * $myInteger;
        }
    

    and call

    echo $myClass->multiplyIt(4);
    

    I get 8. If I do this, on the other hand

    $myClass->myInteger = 'This is a test';
    echo $myClass->multiplyIt(4);
    

    I get an error. And if the reassignment of $myInteger happens in a section of code nowhere near the call to multiplyIt(), the actual source of that bug takes forever to track down. However, if $myInteger is private, any attempt to directly reassign it will throw an error at the reassignment attempt, and you know exactly where the bug is. Taking it a step further, if I create a setter method, I can then test the input value and reject or modify it if it's not an integer, thereby avoiding the whole issue.

  5. @ginerjm - this is probably a bit off-topic, but do you typically write OOP or procedural code? I ask only because I find it interesting that you use a leading cap on functions, while I use leading caps for class names only. No big deal, just interested.

  6. My tastes run to a combination of modern "best practices" and old-school practices that I got used to while learning to code php many, many, many years ago.

    namespace Example;
    /**
     *	Description.
     *	Further description
     *	@param		string		$varName		Description
     *	@return		void|boolean				Description
     */
    class ExampleClass{
    /**
     *	@var	string|null		description
     */
    	private	$_myVar;
    /**
     *	@var	string|null		description
     */
    	public $notAGoodIdea;
    
    /**
     *	Description.
     *	Further description
     *	@param		string		$varName		Description
     *	@return		void|boolean				Description
     */
    	public function __construct(MyOtherClass $class){
    		$this->_myVar = $class;
    	}
    
    /**
     *	Description.
     *	Further description
     *	@param		string		$varName		Description
     *	@param		MyOtherClass	$varName
     *	@return		void|boolean				Description
     */
    	public function exampleOutput(array $test, \StdClass $class){
    		$test['newInput'] = 'This is an input';
    		foreach($test as $t){
    			$loop = $this->doIt($t, $this->_myVar->aMethod($class));
    		}
    		return $class;
    	}
    }
    

    I indent using tabs and keep the opening brace of methods and classes on the same line as the definition statement, and use camel case for method and property definitions. I also still use an underscore on my private variables, a practice ingrained in me during php4 programming. Admittedly, it's gotten me into some trouble as I'm now working mainly with WordPress, and this isn't at all the style they recommend and code to.

     

    Also, I tend to think getters and setters are the way to go, so my name for the public variable - while showing the style I would use - might be a bit biased.

     

    In my experience, potential employers can and usually will overlook things like opening brace placement, white space within parentheses, and private property naming quirks as long as the code is readable, variable names make logical sense, indenting is logical (as ginerjm mentioned, anything within curly braces should be indented one additional level from the parent code) and consistent, and the code is documented. Unfortunately, this last one is not as important to some as I believe it should be...

  7. Two options:

    $file = 'otoole.desmond.caferoyal.pdf';
    $fileNameArray = explode('.',$file);
    
    $idx = count($fileNameArray) - 1;
    print("<p>Count:</p><p>".$fileNameArray[$idx]."</p>"); //a little wordier, but possibly easier to read
    
    print("<p>End:</p><p>".end($fileNameArray)."</p>");    //quicker, with less typing
    

    This will return the file extension, assuming no one adds another dot and characters after the .pdf in the file listing.

  8. You're trying to grab the data-id attribute from a div that doesn't have that attribute. Try changing

    dataId: $('#myModal').attr('data-id')
    

    to

    dataId: $('#myButton').attr('data-id')
    

    I'd also recommend printing the dataId value to console in Javascript before you submit the AJAX request, then again in PHP to make sure the data you're getting is the data you're expecting. Beyond that, mysql_* is deprecated and removed from PHP 7, which should be released soon. You need to be using PDO or MySQLi as a DAL nowadays.

  9. What theme are you using? Looks like it may be reading the class name to replace an input type. For instance, the classes you listed are 'ab-select'mobile' and 'ab-select-services'. Notice that both have '-select-' in them - maybe that's what the theme is reading?

     

    Without knowing the theme, that's only a theory. It may be a bad one, but it's a theory.

  10. Is there a reason you're doing it this way and not just JSON encoding the entire multi-dimensional array? Seems like it'd be easier on both the encode and decode phases if there's not a specific need for this format (I'm assuming you're going to explode the arrays later for use somewhere...).

  11. If the project is still early in it's development, I'd highly recommend switching to PDO (my choice) or MySQLi, because (as already pointed out), the mysql_* functions are deprecated and removed in version 7, coming out sometime in the near-ish future. You'll find plenty of documentation on both classes in the manual, including come ideas about best practices.

  12. The problem with that is that you said all the database connection details are in header.php, so you're not going to be able to run the query before you include the header, which is where you define the database connection. You're going to need to do some refactoring. What does the file header.php look like?

  13. scootstah's right - there's no need to use sessions here. In fact, if the session value is going to be set when the user selects an option from the drop-down, using a session is going to make it more difficult on you. Simply change

    while ($row = mysql_fetch_assoc($result)) {
        $dropdown .= "\r\n<option value='{$row['type']}'>{$row['type']}</option>";
    }
    

    to

    while ($row = mysql_fetch_assoc($result)) {
        $dropdown .= "\r\n<option value='{$row['type']}'>{$row['name']} :: {$row['address']}</option>";
    }
    

    Then, on page report.php, use

    $selectedID = $_POST['items']
    

    as suggested.

     

    Note that this ($selectedID) will then contain the 'value' attribute of the option item (in this case, your desired 'id' from the database), not what the user sees in the drop-down itself.

     

    It goes without saying that you need to sanitize any data before doing anything with it in relation to a database, and that you are going to have to move to PDO or MySQLi soon - the msql_* functions are deprecated and will be removed in the next version of php.

  14. I would agree that if you have the order_item_id then you do not need order id. However, in the case of toppings it could be that item X has a choice of toppings and you want the choice applicable to the particular ordered item. Though I am guessing here about the actual relationship, without knowing the full schema.

     

    Good point. Even then, wouldn't you need an intermediary table for multiple toppings per item, which would negate the need to have the field in the toppings table, right?

  15. This is untested, but you should get the idea. Basically, you have to join each table individually on the foreign keys.

    $sql = "
    SELECT	o.id,
    	o.grand_total,
    	o.cust_name,
    	o.cust_surname,
    	o.cust_address,
    	o_i.name,
    	o_i.quantity,
    	o_i.unit_price,
    	o_i.total,
    	i.name,
    	i.price,
    	i.description,
    	i_t.topping_name,
    	i_t,topping_price
    FROM order AS o
    LEFT JOIN order_items as o_i
    	ON o.id = o_i.order_id
    LEFT JOIN items as i
    	ON o_i.items_id = i.id
    LEFT JOIN items_toppings as i_t
    	ON i_t.items_id = i.id
    ORDER BY o.id DESC $limit
    ";
    

    I don't think it's necessary to include the order id or order items id in your toppings table, because the toppings aren't related to the order, but the item. The item is related to the order through order_items, so you've got your through-line there.

×
×
  • 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.