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.