Doing a cache rebuild on each save has actually been discussed before, but there's a huge problem here. That means every page load all your directories need scanned, the file mtime pulled and that compared to a previous mtime. You got a site with a lot of bigger modules and the performance impact could end up being more severe than no cache at all. There is work to get something similar in Drupal 8 for javascript and css aggregation only. That issue is here:
https://drupal.org/node/678292
About the only viable option would be for Drupal to add a setting to clear certain cache items on each page. The reason for certain items is that it depends on what is being developed. 99% of the time theme developers just need to rebuild the theme and theme registry, while module builders also need to rebuild tons of other things, such as menus, hook registry, module.info, etc. That's why a tool like admin menu is so awesome. You can clear all the caches, or select what you want to clear right from the toolbar.
When I'm working on a big theme I usually end up putting this at the top of my template.php file:
system_rebuild_theme_data(); drupal_theme_rebuild();
That clears what I need on every page load until I get the theme done. Then I just comment them out (and don't forget to do that before going live. My scattered mine has been down that road before!). A lot of the bigger themes even have options to clear the cache on every page load. Zen is a good example that has this.
Honestly this is one of those things where there isn't a "one size fits all", so it's best just left up to the end user. One thing to keep in mind is that a vast majority of the Drupal installs out there never see any kind of customization. People install Drupal through a control panel script, like Fantastico, that their hosting provider supplies and that's it. Honestly things like I mentioned above would be good candidates as new features for the devel module.
(** One note of watching for file changes. I have actually been playing with a NodeJS script that does just that. It watches the directories I set for file updates and can trigger an action, such as drush cc all via the shell. Since NodeJS runs persistent and has greater access to OS tools, like inotify on Linux, the tool is ideal for it. Of course that means having NodeJS run on your development machine.)
Jamie Holly http://hollyit.net
On 10/11/2013 8:07 PM, Roger wrote:
The caching is all tied to performance. Without it Drupal becomes a huge anchor.
Jamie thank you for an excellent description.
You raise an interesting point. Wouldn't you agree that, as this is a well documented flaw during development, Drupal could better handle cache instead of passing it off to the developer who in my experience, doesn't need caching until final testing. Surely it could be a simple core process to empty cache on each save, an automated housekeeping matter? Roger