Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by DeX

  1. Well today is the day I actually start implementing this change in the code and I'm scanning which items I can apply this to and which I can't. I keep focusing on the ones that check to see if the item (door or window) is customer supplied or not and how that would translate. You mentioned above that I could use a multiplier of 1 or 0 to accomplish this but would this be better than separating the customer supplied doors and non-customer supplied doors into 2 separate items? Here is one I'm specifically dealing with right now: case (self::sideWallBeam) : for ($i = 0; $i < count(json_decode($this->overheadQuantities, true)); $i++) if (strtolower($this->getOverheadDoorLocations($i)) == strtolower("Side Wall")) $quantities[] = $this->getOverheadDoorQuantities($i); for ($i = 0; $i < count(json_decode($this->slidingQuantities, true)); $i++) if (strtolower($this->getSlidingDoorLocations($i)) == strtolower("Side Wall")) $quantities[] = $this->getSlidingDoorQuantities($i); break; The salesman enters two 10x12 overhead doors, another 3 10x10 overhead doors and finally a single 10x12 sliding door when doing the quote. For each group of overhead doors, I check to see if that door location is side-wall or end-wall (chosen by salesman) and then add side-wall beams accordingly. My main confusion here resides with the number of options available when adding these doors. They can be customer supplied, end-wall, side-wall and also insulated / non-insulated. Various items depend on each of these attributes when determining if they are required for building the building. Thanks again.
  2. When adding doors, it is always a set number of inputs and they're always the same. The same options are available for every door. Then there are different input options for windows but they're always the same for each window. Then the same for a few other items with a total of about 10 different items like this.
  3. I have a quoting system that some of you may be familiar with from my previous questions, this is another piece of it I'm trying to clean up. The user can add a door or window to the quote and can also associate options with the item. For example, they can add the door, then supply the type of opening mechanism (chain, motor....), then how many windows are in the door, then which storey the door will be installed on. Then they can add another door if they wish. Currently I'm using a jQuery popup like a lightbox (Bootstrap modal dialog) to ask the user all of the proper questions about the door, then when they click the button to save the door, I'm serializing all of the inputs from that lightbox and assigning them to a hidden variable farther down the page. No matter how many doors they add, it all gets serialized into a JSON array into that hidden variable and that variable is submitted to the next page to be saved to the database when the user saves the quote. I know of no other way of transferring all of this data to the next page other than collecting, serializing and submitting as a JSON array. Am I doing it correctly? Thanks.
  4. Actually that code should be this. <div class="row paginate"> <div class="col-12"> <nav> <?php // loop through 5 page numbers for ($i = 1; $i < 6; $i++) { // output initial links and set the page number in a URI variable echo '<a href ="index.php?page=' . $i . '"'; // check URI variable to see if it iss equal to our current iteration count if ($_GET['page'] == $i) echo ' class = "active" '; // output end of link echo '>' . $i . '</a>'; } ?> </nav> </div> </div>
  5. <div class="row paginate"> <div class="col-12"> <nav> <?php // loop through 5 page numbers for ($i = 1; $i < 6; $i++) { // output initial links and set the page number in a URI variable echo '<a href ="index.php?page=' . $i . '"; // check URI variable to see if it iss equal to our current iteration count if ($_GET['page'] == $i) echo ' class = "active" '; // output end of link echo '>' . $i . '</a>'; } ?> </nav> </div> </div> Untested but here is how you would build the pages dynamically. Eventually I would have the photo links in a database and I would look into using mod_rewrite with a .htaccess file so you can have the following: .../photos/2 instead of: .../index.php?page=2
  6. case (self::whiteCaulking) : $unit_rules = array(); // note: this example is for categories, not individual items, though you could mix them easily by adding an indicator to the defining array if the $key it a category or an item and call the appropriate method to get the correct quantity $unit_rules['ManDoors'] = array('mult'=>.75,'offset'=>0); $unit_rules['Windows'] = array('mult'=>.75,'offset'=>0); $group_rules = array(); $group_rules[] = array('operation'=>'function','name'=>'ceil'); $quantity = 0; // apply any unit rules foreach($unit_rules as $key->$rule) { $quanity += ($this->getTotalQuantityByCategory($key) * $rule['mult']) + $rule['offset']; } // apply any group rules foreach($group_rules as $rule) { switch($rule['operation']) { case 'function': $quantity = $rule['name']($quantity); break; } } $quantities[] = $quantity; break; Now that I have a chance to go through this very slowly and understand it I have a few questions about the flow of the logic. 1. The switch statement checks if we're looking for caulking and then enters into this logic to get the quantity. 2. What do you mean about this example being for categories and not for items? It seems like it would work for white caulking as it is. 3. I see you've added a multiplier and an offset for 2 other items (doors / windows), I understand that. 4. I see you add a group rule of rounding up on the screws to be used later, I get that. 5. Then you execute the unit rules, this part I kind of understand. You're passing in 'ManDoors' as the key for the calculation, would it be correct to assume I should pass in the database ID of the product instead? Is that better practice? 6. In the same section, you're adding the offset, should you be multiplying by it instead? Is this a typo? 7. If I want to apply the calculation only if the door is insulated, would I just use a second offset? Would I just keep adding offsets for any additional attributes I wanted to check for like this? For example, a height labour charge is added if the building is over 16 feet high because the crew has to rent a scissor lift to do the work and that cost has to get passed to the customer. So I'm assuming I would have an offset for whether or not the building is over 16 feet. 8. Do I hard code what these offsets are or can the client add an additional offset for a new attribute when adding items? This is great, thank you. If I can allow customers to add their own products I can set this up as a portal where clients can sign themselves up without any involvement from me and I can charge them a monthly fee for access so if you would prefer to speak on the phone and I pay you for an hour of your time, that would be fine by me. It would be nice to have it here for others to see too though.
  7. The quantity of screws is based on the width of the sliding doors though, because there is a screw every so many square feet I believe. And then another set around the edge, something along those lines, I know the calculation I posted is the calculation we're using in production right now.
  8. Very cool, thank you! When the user is adding the new item and trying to input how the quantity calculation will work, how could the interface work for that? How could the specify that 3/4 of a tube of this new product needs to be added any time another product (doors / windows) is added? And to make it more complicated, what about all the confusion for how the user would enter the calculation for the Sliding Tec Screws? Would I just ask them for the multiplier, offset and rules for each product?
  9. I currently have a rather large PHP system where salesmen enter building details into a form and it builds a bill of materials (BOM) based on their inputs. Currently if they want to add any new materials into the system I have to do it because the calculations for getting the quantities of each item often depend on the attributes of other items in the system and I don't know how to give this control to the user. For example, when the quote is generated to calculate the BOM, it iterates over each material in the database and fetches the quantity calculation based on the ID. The quantity calculation is hard coded into the PHP and could be something like this: case (self::slidingTecScrews) : $quantity = 0; $buffer = 1.03; $screwsPerBox = 500; for ($i = 0; $i < count(json_decode($this->slidingQuantities, true)); $i++) $quantity += ($this->getSlidingDoorWidths($i) / 2 + 1) * $this->getSlidingDoorQuantities($i) * 5 * ceil($this->getSlidingDoorWidths($i) / 3) * $this->getSlidingDoorQuantities($i); // for all doors $quantity *= $buffer; // add buffer for extra screws if ($quantity > 0) $quantity += $screwsPerBox - ($quantity % $screwsPerBox); // round up to nearest full box $quantities[] = floor($quantity); break; In this example I get the quantity of Sliding Door Tec Screws and I run a calculation of how many I need per sliding door, then multiply it by the quantity of sliding doors to get the total. Then I add in a buffer because the crew is always dropping some on the ground, then I round it up to a full box. I have absolutely no idea how I would build an interface to allow one of the users to add in a product and assign this calculation for the quantity. For good measure here's another random quantity calculation: case (self::whiteCaulking) : $quantity = ceil(( $this->getTotalQuantityManDoors(true) + $this->getTotalQuantityWindows(true)) * .75 ); $quantities[] = $quantity; break; This one passes a variable into the quantity of doors / windows to specify whether or not it should include customer supplied doors into the calculation. Sometimes the door is added to the quote but the customer may want to supply it themselves and therefore we need to order the extra trims (and white caulk) but don't want to factor the door into the total material pricing. Here we use 3/4 of a tube of caulking per door / window. Sometimes it will use the quantity of doors in the calculation but only if they are insulated, or only if they're more than 12 feet high. Sometimes it'll add a product based on every 10 square feet of wall light in a building, it could be based on almost anything. Getting the quantity and per-item cost of everything in the BOM allows me to show the actual build cost for the structure and then apply a markup to get the selling price. Thanks a lot.
  10. Thank you. One more question, if I'm getting the price of the quote, how do I know if that's already in the model object or if I need to get it from the database? For example, the first time I need to fetch the price, I would go to the database, get it, then set it in the quote model. The next 10 times I need to get that price while displaying the same page (in various places), I don't want to keep going back to the database for the price, how do I know if I can retrieve it from the model object using the getter? Do I have a piece of code in the getter that checks to see if the local variable is set and return if so?
  11. No not at all, I very much appreciate the guidance. If using an ORM library is the proper way to go for medium scaled PHP implementations, then that's what I will use. Just as long as it's better long term and not just short term. I want the best long term solution.
  12. I wasn't necessarily going to build setters and getters for every single database column. For example, if I have a quote I need to display on the page, I would build a customer object and set all the customer details in that so the getters can retrieve it to display on the page, it's only name, address and phone number. Then I would have a quote object which would set things like the quote price, the quote expiry date and a list of all the upgrade options to show on the quote, along with their attributes like width, height and quantity. Then when doing purchase orders, I would build a bill of materials (BOM) object that would contain all individual building products and their attributes. Is this wrong? I'm mostly wondering how to separate the model into multiple models because I mainly just have one right now with all the methods in it.
  13. I've been working with what I thought was MVC for quite a while but now after researching it some more, it appears I may have been wrong all along. I think I have been using the model incorrectly. Is my new way of thinking now correct? Model: These are like objects that hold data during the session (page load). It can also dump the data to the database but is mainly used to hold data related to a specific object for use throughout the current page load. Controller: There will usually only be one as it is like a gatekeeper that directs requests to the proper model. View: These will usually be the .php pages themselves but for views that are reused, it can be an isolated class which generates HTML code (like loading a select element with user names). I have built a program where a quote is requested by the user and the program has to go to the database in order to get the details of the quote to display them on screen. Right now my view is making the request through the controller to the model and the model is fetching each piece of requested information from the database, then passing it back through to the view as needed. Because the page can show the same information in various places, the same database call by the model can be made more than once for that specific information. Should I be making a request for the entire quote, building a quote object with the model and then passing that entire object back to the view to be used instead? This will introduce a lot of getter/setts methods of which I currently have none. I'm assuming I would have a customer model which would build a customer object and return that. Then a quote model would build a quote object and return that. Same for purchase orders and users, all which will have information appearing on the quote or purchase order. Thanks a lot, I'm really trying to research this as much as I can and get it correct.
  • 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.