[eluser]mtbkrdave[/eluser]
Hi Y'all-
I'm working on a public-intent beta for my CI app, and I'm trying to use coding practices that reflect the way I'll approach my final version as much as possible.
I've finished mapping out my controllers and functions according to the site's features and pages, and I've got all the controllers stubbed out. That activity alone caught a lot of 'gotchas' in my planning! Now that I'm ready to write some actual code, I'm struggling with where to start. Here's the approach I've whomped up:
1) Write the views first. For all but the simplest controller<-->view relationships, hard-code the dynamic data right into the view, but clearly identify (using HTML comments) all the areas that depend on dynamic data.
2) Once I've got the views rendering right, write controllers that deliver the flagged data in the views, and modify the views to display what's passed instead of hard-coded values. In lieu of database queries, use statically-defined data in the controllers (or load from a constants file) to ring out the controller<-->view interface.
3) Write models to deliver the same static data to the controllers, building up the model<-->controller interface without worrying about what's going on under the hood of the models.
4) Finally, after the models and controllers are playing nice,
write the guts of the models and replace the static data with database queries.
Does this seem like a reasonable approach? Would you approach it differently?
A couple of resulting questions:
A) Is there any way for a model to echo out debug data? Can models write entries out through the CI logging system? Or could a model open up its own log file in an application-specific log directory somewhere on the path?
B) Without actually performing a database query, how can I mimic the behavior of the $this->query->result() function? I took a look into db_result.php but immediately soiled myself!
Thanks all!
[medic]Dave
