dennis-fedco

Yes ... I am not entirely sure if the first approach will work since there are more than a few lines of code to figure the View Template out, and those lines of code include some "business logic" as well. For example part of $input is a boolean $isMotorPresent, and other engineering type values. Part of generated $output is "How many supporting stands does this product have" which take some hefty computation to figure out. "presence of motor" is not part of $output, although I suppose it could be.... That's kind of a judgement call. Both pieces (from $input & $output) are needed to pick the right View template. So a problem remains.. My particular View and the way my code is currently set up, my "View Factory" or my "Code that's close to the controller", needs to know $input as well. So, for example I would have to do this: $this->view = ClassThatCreatesViewsFromOutputData::factory($input, $output); Or I would have to copy certain values from $input to $output so I can do this: //whether $output is bloated I guess is relative, I can say it's not.. //But the bloated part (one copied over as pass-through from $input) will only used to compute the View template //and will not be used otherwise. $this->view = ClassThatCreatesViewsFromOutputData::factory($bloated_Output_That_Contains_A_Bit_Of_Input); And that was my problem .... i.e. I can either 1. put up with using both $input and $output in my code in my View Factory (or make the $output contain $input) 2. compute part of View (the template part) inside my ClassThatComputesData, probably breaking SRP, because ClassThatComputesData already contains $input and the view-template-required $output is being created as part of ClassThatComputesData 3. make View-template accept $input only and recompute the needed $output vars All of the above will work but I think is somehow breaking SRP or at least creating some bloat/rework........ #2 is how my legacy code was, and my current code is a little weird because I essentially do array merge .... which I see as a hack $this->view = ClassThatCreatesViewsFromOutputData::factory(array_merge($input, $output));

I have some code that takes "User Input", then does a series of computations and produces "Output Data" to be displayed on a PDF document. PDF document is a template that is subsequently displayed with data superimposed onto it in the appropriate places. One complication is that PDF document is a template, and template file name itself depends in part on data from the "User Input" and part from the computed "Output Data". In original (legacy) code, PDF template file name is embedded into "Output Data". So I could do $outputData = $this->computeOutput($userInput); $pdf = new Pdf(); //$outputData['template'] == 'computed_pdf_filename.pdf'; $pdf->setTemplate($outputData['template']); $pdf->superimposeData($outputData); My question is ... do I separate computation of the PDF template (which does not have much to do with outline data) from computation of the outline data? They both share a good chunk of transient variables to compute things. so in some ways it makes sense to keep "PDF template" as part of "Output Data". But on the other hand, what if I later decide to not use PDF at all but to use PNG Images? Or TIFF? Or some other format? Unlikely, but then I will need to rip out my PDF-Template computing code from "ComputeOutput" method. But the to compute Template Filename I will need to pass that function both the input and the output. Something like so $outputData = $this->computeOutput($userInput); //if I separate it out $template = TemplateService::computeOutput($userInput, $outputData); $pdf = new Pdf(); //$outputData['template'] == 'computed_pdf_filename.pdf'; $pdf->setTemplate($template); $pdf->superimposeData($outputData); Back to the question ... are there any pros or cons to separating data from the template?

If humans were capable of understanding most god-awful obfuscated computer code, whether it was binary, high level, or assembly, will there be a need for complex refactoring rituals, design patterns, frameworks, application stacks, and so on? I am wondering if the need to refactor code arose purely due to people not being able to comprehend, understand someone else's code. It is sometimes said that perfectly refactored code is easier to change, and maintain. While perhaps true in general, if humans were capable of comprehending code immediately upon access, no matter how horribly un-factored the code is, they will still be able to make changes to it. Even if changes in un-factored code takes 20 times as much effort (i.e pure textual code changes), it still won't take as much time as common humans take now to make changes to god-awful un-factored code. Are there any considerations that I have left out that will still make refactoring needed even if humans possessed super-human code-reading and comprehending abilities?

alright. I can use DIVs and not tables. Maybe even if I do that, my life will be easier (i.e. maybe I won't have to use tabindex and such to force table to behave my way), and maybe I can choose either row or column implementation this way. What you have is promising I am going to try a few more things to make sure. My goal is basically: keep HTML simple (right now my HTML is not simple, with tabindexes and all) keep logic simple (same -- right now I have to deal with a mess of indexes and mapping them to proper columns) a new one -- being able to save the form (via AJAX), and restore the form (say I have 10 data sets, I don't want to reenter them all if I need to make a change) One way to implement that I have seen is to use AJAX to add one row at a time. So at any one time you effectively have only one form-column to deal with and you generate that form in the back and load it via AJAX. ehh there's gotta be a library for this. I am more "back-end" PHP wiz ...

I want to create functionality where user can enter some data. Each data is a set of 6 variables. I want to make the number of columns dynamic and start off with a single column and make multiple columns via for example an "Add Column" button. I have started trying this concept with columns (https://jsfiddle.net/dennisfedco/vfhc1jma/5/) Or, if it makes things simpler, I can do rows. But initially, user sees 6 input boxes. Enters values. Then clicks "add new set" which shows 6 more input boxes (via column or row) and enters new values. Then user can select one of the column/row as "main" and submit. How can I do this with least amount of trouble? My goal is to make it solid and easy to debug if there is trouble, so I would like to avoid things like AJAX or making it too dynamic or too breakable. In short in my example there are 4 columns now. But I want to make it just one, and have user add more if needed.

I have been playing with this a lot recently. And I thought -- Why do I have to populate Product with a Motor? I do not have to! I guess if my business application needed a Product with a Motor, as a unit, then yes, that is one way to do it. But if my application matches various combinations of Products and Motors, then I can have them be loaded separately via DataMappers. Basically whatever suits my needs. This begs for a more general question -- If I say have an object that is comprised of smaller objects, when is it appropriate to load them all up and when is it appropriate to just load them on as-needed basis. //do I end up with this class BigProductMapper { public function loadEverythingUp() { //load all subproducts into BigProduct } } //or with this class BigProductMapper { public function loadJustTheBigProduct() {} } class SubProductMapper1 { public function loadSubProduct1() {} } class SubProductMapper2 { public function loadSubProduct2() {} } ... class SubProductMapperN { public function loadSubProductN() {} } //have production code load things up as part of bigger class as-needed

thanks I think I understand now and don't need any further help so far but I am curious -- what is it that's undesirable towards dependency in the current version of code that I have? namely, if I wish to change the underlying database, I do not really have to touch my object. so there is some decomposition there that works. I may not even have to change the MotorDAO or the MotorData class, and change just the db_query() function when I switch native functionality If structure of SQL changes, then I have to change MotorData. But other than that, my entitity remains intact. Or is it? What is bad about dependency in the code?

At first I thought it meant "We have 64Mb free, and we tried to allocate 36 bytes in that vast free space, but there was an error", which did not make sense to me. But then I realized it means "We have been allocating memory right and left for the stuff you do in your script and all entire memory limit of 64Mb has been used up and is full. Now when your rampant script tries to allocate 36 more bytes, we just can't take any more". So increase your memory limit, or find a bug in your script that caused this high memory usage.

I supose another question too is : Why use a Mapper pattern opposed to any other DB pattern available? And also I do plan to eventually (if time/resources allow) to migrate to Doctrine or similar layer

Thanks I understand that I went too far, but after that I am not sure I understand the points completely. Product and Motor are my business classes. The rest is various DB-functionality and computation and display. Are you saying that my bussiness class depends on DB? Where exactly is the dependency, because I don't think I am aware of it, or I don't see it. The way Product and Motor interact are not as clear cut as I've made it appear to be and their purpose currently is more messy. So I want to focus on overall theme and not on any specific usage of the clasess. But, for example, I load motors and products separately and then run varoius simulations. There is no direct motor-product connection. More like there are "motors" and "product" and then they interact. Can you also show an example of how to use the ProductMapper? Is it just //using the mapper $products = (new ProductMapper())->someBusinessIdentifiableMethod(); //calls DB-functions directly I do not see how it is different from this (what I have now) : //what I currently have - invoking DAO->Data->Db->MySQL $motors = $this->product->motor->loadMotors(); //calls a DAO class, which calls DB functions direclty They both provide me with the same stuff - product or motor objects that were loaded from DB in some way or another... my way takes a lot more calls (various object invocations) though.

I was doing various separation of concerns refactoring but I think I went too far. I think I have too many layers and want to do a reality check. Originally there was some code in the Product class that called native functionality directly. Now it's just too many layers, I think. So what I have now is: "real" business-layer code (calls) --> (i.e.) Motor class (which calls) --> DAO layer (that calls) --> Data layer (that calls) --> a global function that calls native MySql function Is there a healthier way to restructure this complexity without losing benefits of SOC and OO? class Product { ... { // business logic needs motors $this->product->motor->loadMotors(); } } //class to handle motor functions class Motor { public function loadMotors() { return $this->motorDao->loadMotors(); } } //layer to handle connection between "object" and "database result" class LoadMotorDao { public function loadMotors() { $motorDbResultObject = $this->motorData->giveMeMotors(); //some data-to-object handling code return $motorObject; } } //class that purely returns just data from DB as-is //typically a DB result set class LoadMotorData { public function giveMeMotors() { return db_query("SELECT ... "); } } //global function that calls native functionality function db_query($query, $database = "", $conn = "") { return ... mysql_db_query($database, $query, $conn); }

My question is about moving my codebase to modern DB practices (with least work possible). My codebase is currently using outdated MySQL extensions. Like so: <? $sql = " SELECT description, quantity FROM sales.item WHERE id = {$orderid} "; $result = db_query($sql); for ($i = 0; $i < db_num_rows($result); $i++) { $row = db_fetch_array($result); ?> <tr> <td><?=$row['description']?></td> <td><?=$row['quantity']?></td> </tr> <? } ?> I have 1140 such statements in "SELECT" statements alone and not counting any DELETE/UPDATE or other SQL statements. This means that updating and paying attention to each statement individually is going to be a huge effort. That effort is what I want to avoid, or automate as much as possible. Question: other than leaving the codebase as-is, are there any reasonable ways to move it or nudge it to the current latest PHP DB practices? (Be it, PDO, or mysqli, or Doctrine, or otherwise), without expending herculean amount of effort?

thanks.. ... in my case labels are only to be produced for certain product lines, so for example we have vetted lables for A and B only, but not C. my code (above) is placed into existing code that exposes my code to all product lines. In other words, my code sees all product lines but must only produce labels when it sees A or B (and new lines needing labels may be introduced later) So if my label-generating-code fails for reason of "no label defined for existing product line X", it is not big deal, meaning "all is well" and nothing should be looked into. Otherwise, for other errors it may be good to log a message. One thing exception handling does for me is it has a standard way to propagate the error message from a Leaf Function of the code, up the chain, to some parent function that has a catch block. Thereby saving me the work and saving me the cluttering up of my code with trying to pass such error message up the chain myself. I see your point about differentiating between Factory failing or my code failing, and I think I am going to keep the exception just becaues I already written it that way. But truly I do not think it is something that needs exception as somewhere I have read an advice that said Only use exceptions for exceptionary situation. I am tempted to say that in my case, my use case is not very exceptional. And still, despite this, using Exceptions makes my life easier in this case. If I remove exceptions, I lose the up-the-chain ability and will just end up with some logging messages. So in other words, I am still in "what am I doing" stage.

I have some code that is run for multiple product lines, A, B, C. I've coded up a factory that takes product line, some data, and produces a label for that product. Currently something like this: //pseudo-codish foreach(..) { try { $x->getLabel($productLine); } catch(Exception $e) { Log::write("can't create label"); } } getLabel() takes a $productLine, which is then sent to a factory class, and if it's a new product line, the factory throws an exception as it doesn't know how to handle that product line. I am thinking that why am I writing exception for this? Why not get rid of exception throwing and exception handling code just move that Log::write() line to the place where I am currently throwing the exception (not shown) My question is thus -- Do I need to use Exception Handling in this case or do I remove Exceptions from the code? The end result is kind of the same. Except, without exception, (without doing any extra coding work to return parameters), I will essentially be unable to direct the flow of code at the higher level (such as pictured above), based on whether the product line was known or unknown to the factory.

my answer .... 6 tables. Not that many. Why - to store data related to my application. I am not sure what you mean by my application already knowing the table structure. It is using the tables, so it is aware of them.