Sanity check: My development workflow

[eluser]mtbkrdave[/eluser]
Hi Guys - Thank You for the feedback!

I guess the view-->controller-->model approach made the most sense to me initially because I'm not quite sure which models I'm going to need yet (though I do have the database schema designed) but I do know what each rendered page should look like. Kind of like Doug Bowman's take on CSS implementation: design your page first, even if it's just with pencil and paper, and only start implementing once you know what you're trying to achieve (i.e. if you try to do visual design by writing CSS, you'll tear your hair out).

I can, however, see the value in going model-->controller-->view, too - especially with a clear idea of what the data objects will look like. Given that the model is typically going to return array data keyed by the column names within each table, using the wrong name [in my suggested workflow] at the view level could propagate all the way back through the controller to the model before the error is discovered.

As for the questions...

A) I'd like to be able to get raw debug info out of the model functions because some of my models will need to do some geospatial calculations before they hit the database, and others will rely on calls to remote geocoding/reverse-geocoding services. Getting a look at the inner workings of the model (while it's being debugged) would be useful without having to alter the organization of the returned data and how the controller handles it.

B) I think I messed up my question. I guess what I should have said was: if I wanted to build myself a $query object without using the active record class (i.e. to hold the static stub data), how would I craft the return() function within that object so that it plays nice with foreach()? Should I just quit making this so bloody complicated and scaffold up some database rows??

Thanks,
[medic]Dave