Hi Stef,
No, of course I change it all the time without going to source view. I admit when I initially created it, it required using source view and if I wanted to change the layout it would require it again but it does not require source view to edit the text content.
To me this is the opportunity that you and others have to add value for your customers besides just installing and skinning. The content template system is designed for much more than just the javascript widgets we have, it can be used to create layouts that can empower users and supplementing the system with some layouts beyond what is included is a way to solve some common goals for your customers. Perhaps at some point I will implement more included templates to demonstrate this.
As far as caching, thats a complex topic that many people misunderstand. Caching uses server memory and in the vast majority of hosting situations thats the most scarce resource of all. I have seen inappropriate use of cache be a big performance killer. Yes database access is a precious resource but unless you are on a dedicated server with gobs of RAM server memory is much more precious. Shared hosting is usually a very memory constrained environment and using too much cache when your memory allocation is low is a sure way to cause your app to continuously recycle the app pool and kill performance because in most hosting in order to prevent rogue apps from running away with server memory they app pool is configured to recycle when a certain amount of memory is used and this frees up the cache. So if you try to cache too agressivley it can really hurt performance unless you have gobs of ram to hold all that stuff you are caching. As it is the runtime caches certain things and you have no choice like sitemaps, themes etc get cached heavily by the runtime and for very large sites the sitemap can be a fairly large thing to cache, and we do cache more complex and frequently used objects like SiteSettings. So cache is something to use very judiciously and can easily be misused to disadvantage.
Not all database hits are the same in terms of expense. If there is sufficient ram expensive things should be cached. But cache is rarely a cure all for too many db hits. db hits are neccessary, but its best to optimise and reduce the number of them as much as possible without having to cache to make up for too many.
mojoPortal does support caching in some features including the html module but it is disabled by default for this reason and people should think very carefully before enabling it. Even on a dedicated server, unless you are trying to solve an actual rather than theoretical performance problem I would not enable it. I'm not using it on this site and I'm on a dedicated server with 1 GB of ram. Its a good environement but its not a high end environment. I think part of the reason some other well known .NET apps don't work well in budget hosting is because they cache too agressively and consume too much server resources and this forces the app pool to recycle frequently killing real performance.
If you want to cache things you can add this to Web.config/user.config:
<add key="DisableContentCache" value="false" />
then you will see in module settings where you can specify the cache duration for features that do support caching. Note however that features that use ajax postbacks or that personalize content are not good candidates for caching.
Hope this explanation helps.
Best,
Joe