Tracking down model calls

@mwhitney

Thank you for that reply. Your suggested usage of alias is a great idea and I will definitely be using that in the future. In fact after a quick google of the topic I couldn't believe i had overlooked that.

As for the why the model is changing, in this particular case, the site is nearly complete when lo and behold a request comes in for a functionality change, that completely alters the method I was using to achieve the initial goal. In this case it is a call handler that was intended for outbound calls only, and now has to cater for inbound calls too. In an attempt to not rewrite everything but adapt the system I had coded, I found myself having to rewrite the bit that initiates the call and change the model.

In previous cases it has always been the extension of functionality. Actually more accurately the changing of functionality, not just extending. I usually get away with adding on additional variables to the models, but not always. Hence the back tracking of model calls.

I did once try, every time I wrote a model call, updating the model comments. But that very quickly became impossible to maintain accurately. And mostly a waste of time too.

I have since discovered my editor does have a 'search all files' facility for local files but can't search the live site directories (not surprisingly). However have now downloaded the entire application folder and searched that and tracked down only five instances of the model call which are easy enough to fix now.

I love the alias idea though and will definitely be using that from now on where I can. Makes so much sense for code that is currently working but needs extending.

Thank you again,

Best wishes,

Paul.