Hi...

Quote Originally Posted by josheli
at any rate, the churn rate on the reports and the applications is pretty low. once they're working, they're not altered that often.
In that case I would let them go their own way and only backport ifyou feel a compelling desire to do so.

Quote Originally Posted by josheli
i've read about it, seen it discussed, possibly even used it unknowingly.
It's an invisible wrapper...
PHP Code:
class WithProductitivityCalculation {
    var 
$_table;

    function 
WithProductitivityCalculation(&$table) {
        
$this->_table = &$table;
    }

    function 
nextRow() {
        
$row $this->_table->nextRow();
        
$interval $row['start']->calculateInterval($row['end']);
        
$productivity = (float)$row['number']->getValue() / (float)$interval;
        
$row['productivity'] = new DecimalField($productivity);
        return 
$row;
    }

Usage is something like...
PHP Code:
$report = &new Report('Employee Productivity');
$report->addTable(new WithProductitivityCalculation(
              new 
Employee Productivity($startDate$endDate$issue)));
$report->generate(new ExcelWriter()); 
Now the extra calculation decision is explicit in the application and we have managed to keep the data fetch small. It also means that the data fetching code can be used again.

Quote Originally Posted by josheli
sure, when you have a stab at it, Bob's your uncle, but when i get a couple of iterations in, i can't see the forrest for the trees.
The main thing is to do just one at a time. We all get stuck about the third iteration in, but the result is usually greater insight into the problem long term.

Quote Originally Posted by josheli
so, as devil's advocate, assuming i go down this OO route, what will it buy me that some glue code, some functions and a few classes won't?
Because of the extra syntax it will grease the wheels in the following areas...
1) Clarity of the application code.
2) Being able to work on one extremely small piece at a time and know taht you are doing that.
3) Isolation of the application code. You should be able to add and remove parts of reports without major rewrites.
4) Ease of making changes once your core interfaces are correct. Making them a good fit is itself an iterative process. Things will be a bit wrong on the first attempt.
5) Ease of testing. Classes are way easier to test than bare scripts.

The real advantage is long term. You are enabling an evolutionary process by unlocking a feedback loop. As your understanding deepens you will come up with a more incisive solution than my off the cuff effort I'm sure. And you walk away with this knowledge onto future projects. It will be slow going, but the only way is up.

yours, Marcus