Note that there are some explanatory texts on larger screens.

plurals
  1. POBuilding complex conditional tables in object-orientated PHP
    primarykey
    data
    text
    <p>I am currently working on a Zend Framework project whereby the end result of the users journey through the application presents them with a large table containing their results. This table can contain varying numbers of rows, most of which are generated as the results of calculations. So far, so good.</p> <p>The first; albeit minor hurdle, is that the table needs to be presented horizontally. That is, the headings are in column 1 and each additional column represents a data entity item. For example:</p> <pre> Forename | James | Richard Surname | Jones | Mayfair </pre> <p>Again, this isn't an issue. The problem arises when I come to construct the table neatly. Using the builder pattern, I've got three classes: Table, Group and Row. They can be used like this:</p> <pre><code>$table = new Table($attribs); $group = new Group(); // Nothing special about groups, they're just there for helping with presentation $row = new Row(); $row-&gt;setTitle('Forename') -&gt;setData(array('item1' =&gt; 'James', 'item2' =&gt; 'Richard')) $row2 = new Row(); $row2-&gt;setTitle('Surname') -&gt;setData(array('item1' =&gt; 'Jones', 'item2' =&gt; 'Mayfair')) $group-&gt;addRow($row) -&gt;addRow($row2); $table-&gt;addGroup($group); </code></pre> <p>The above code snippet appears within a controllers' action. The table object is then passed to the view and I've got a view helper that outputs to the table to my own specification.</p> <p>The challenge that I'm facing however, is that I've ended up with a very messy 'Results' model. For example, I've got lots of:</p> <pre><code>$group-&gt;addRow($this-&gt;_resultsModel-&gt;getSurnameRow()); </code></pre> <p>The '_resultsModel' property is an object which contains a lot of methods that do:</p> <pre><code>public function getSurnameRow() { $row = new Row(); $row-&gt;setTitle('Surname'); $row-&gt;setData($this-&gt;_getAssociateArrayOfSurnames()); return $row; } </code></pre> <p>Furthermore, the results object extends a results abstract class which contains accessor, setter and calculation methods for the raw data. Each of these 'calculation' methods returns an associative array of data which can be assigned to a row object. Both the results object and the abstracted class are both long and just seem disjointed.</p> <p>So to summarise... I've ended up with one big results model that does all the calculations and returns all the row objects. Whilst it does work, I'm convinced there's a better way of doing things. Should I be building the rows in the controller? Should I only be calling the calculations from the models? Does anyone have any experience abstracting stuff like this?</p> <p>I apologise is this is a poor explanation. If anyone has any questions that I can field, let me know.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload