In my MVC3 Project I use some output caching with the OutputCache attribute set on the action. However there are certain sections on this page that I dont want to cache ever.
Is it possible to have some partials in my view that overrides the pages caching?
You can now get proper donut caching by downloading the MvcDonutCaching NuGet package. See http://mvcdonutcaching.codeplex.com/ and http://www.devtrends.co.uk/blog/donut-output-caching-in-asp.net-mvc-3 for more information.
Yes you are 'supposed' to be able to do this.
See:
Partial Views Caching in ASP.NET MVC 3
Also I use a method to disable caching for controllers here:
Disable browser cache for entire ASP.NET website
Seems like this is the answer: http://weblogs.asp.net/scottgu/archive/2006/11/28/tip-trick-implement-donut-caching-with-the-asp-net-2-0-output-cache-substitution-feature.aspx
You basically have two options:
Refactor the page so that rather than caching the entire page,
you identify all the specific pieces (controls, partials, etc) that
should be cached. (boo)
Use output substitution blocks as Scott
Guthrie describes in the link. (boo as well unless the replacement
is just simple text)
This is called donut caching and isn't supported out of the box in MVC3. Check out my similar question here. Specifically, Jan Jongboom's Moth library which he suggests can do this (though I cannot confirm or deny this)
Related
I am currently working on an ASP.NET MVC project and came upon an error that seemed peculiar.
In the ASP.NET MVC Templates forms always get an AntiForgeryToken (thus leading me to believe that this is a best practice). However AntiForgeryTokens don't seem to work well with caching.
For example when I open a site with a form including an AntiForgeryToken and I duplicate the browser window both windows have the exact same AntiForgeryToken leading to an exception when posting the form. This problem does not exist when caching is disabled (via ActionFilter NoCache, see Disable browser cache for entire ASP.NET website).
So I guess my question is: Is this supposed to be that way? Is there any other way besides disabling the cache to tackle the problem?
Especially the fact that the default ASP.NET MVC templates contain AntiForgeryTokens but don't disable the cache (and therefore are open to the error described above) makes me wonder.
Thanks in advance!
This is the expected behavior. Caching nicely caches the answer, including the value of the AntiForgeryToken. Disable caching on forms, and in particular on pages that use AntiForgeryToken. If you think about this further, if you're in a data-entry app, do you want to cache your data-entry forms? Probably not. However you do want to cache heavy reports -- even if it's just micro-caching -- a second or two.
We have web applications elgifto.com, roadbrake.com in which we used AJAX at many places, especially to update major portions of a page. All the important functionality of elgifto.com was implemented using AJAX. Now we realize a few issues due to AJAX implementation.
All the content implemented using
AJAX is not available to the SEO
bots and it is hurting the page rank
of our site.
Users will not be able to bookmark
some of the pages as they are always
available through AJAX.
When we want to direct the user from
one page through an anchor link to
another page having AJAX, we find it
difficult.
So now we are thinking of removing AJAX for these pages and use it only for small functionality such as something similar to marking a question as favorite in SO. So before going ahead and removing, we want to know expert's opinion on this. Thanks.
The problem is not "AJAX" per se, but your implementation of it. Just as a for instance, you can fix the 'bookmark' problem like google maps does it: provide a generated link for each state of your webapp.
SEO can befixed by supplying various of these state-links to the crawlers, either organically trough links in your site, or by supplying a list (sitemap).
If you implement 2, you can fix 1 and 3 with those links.
In the end you must figure out if the effort is worth it, and if you are not overusing AJAX ofcourse, but the statements you've made are not set in stone at all.
I'm costantly developing ajax based websites, with no problems for SEO at all. You just have to use it in the best possible way.
For example, I have a website with normal links pointing to normal webpages (PHP pages), this for normal navigation if a user doesn't have JS enabled. But if a user has JS enabled, a script will change the links behavior, only fetching the content of the page needed.
This way you still have phisycal separated webpages with all their content, which will be indexed as normal.
I'm writing an application in MVC3. it has features like login, a simple forum, news, and pages that get their main content from the db.
I'm looking into caching right now.
First I tried the simple [OutputCache] attribute but noticed that it caches the same content for every user. Normally it wouldn't be that much of a problem, but - for example - the login box is cached too and therefore it shows the same content for every user (and everybody will just see that they are logged in as admin). Even if I set Location=OutputCacheLocation.Client, after a logout the cached page still shows that I'm logged in.
No matter, I thought I can always try Response.WriteSubstitution, but for some reason it seems to be broken in MVC3.
I'm now reading about the "ASP.NET MVC Result Cache", and it seems interesting, but is it a proper way to handle caching?
Also am I able to cache childactions, or partial views in an otherwise very dynamic page?
There are so many options and I don't know what should I use and when.
Sorry that my question is so vague, but I don't even know what to ask in this case.
I think this post my solve your problem.
MVC3 custom outputcache
Good luck
ASP.NET MVC 3 (final) was released today. When this version was in its infancy I remember reading on codeplex that donut caching was being considered. Does anyone know if this made it into V3? I cannot seem to find any information so I can only (sadly) assume that it didn't happen.
Yes, it is. Scott Gu blogged about it:
In addition to supporting full page
output caching, ASP.NET MVC 3 also
supports partial-page caching – which
allows you to cache a region of output
and re-use it across multiple requests
or controllers. The [OutputCache]
behavior for partial-page caching was
updated with RC2 so that sub-content
cached entries are varied based on
input parameters as opposed to the URL
structure of the top-level request –
which makes caching scenarios both
easier and more powerful than the
behavior in the previous RC.
UPDATE:
Out of the box only donut hole caching is supported in ASP.NET MVC 3. This allows you to cache a small portion of the page by using the [OutputCache] attribute on a child action. Donut caching which allows for excluding portions of a page that has been cached is not supported. Response.WriteSubstitution doesn't work since ASP.NET MVC 2. Here is a good article which explains the different caching options available in ASP.NET MVC 3.
UPDATE 2:
Here's a great article which illustrates how donut caching could be enabled in ASP.NET MVC 3.
Here's a slightly more detailed example from Scott, using Razor syntax.
Donut Caching (yes, the real thing) is available as part of my 'speed-lib' for MVC: Moth. Works in both ASP.NET MVC 2 and MVC 3.
Docs are at the wiki, and examples are in the Mvc3.Demo folder
I found a NuGet package MvcDonutCaching mentioned by Denis Huvelle which solves the problem for 3 & 4 - but I haven't tested it.
My Question is: Why don't use more webpages AJAX to load the Webpage content?
Because of the fact that you can switch off JS or is there a thought about some security problem ?
Probably for two reasons:
Users with Javascript disabled won't see anything.
Pages loaded through AJAX aren't crawl-able by search engines. You want your content to be as accessible as possible so people searching the Web will find your application.
Because in most cases it doesn't make the site any more comfortable to use (often the effect would be the opposite). "Ajax" shouldn't be used to load entire pages unless you have a very good reason for it.
One word: SEO. Seach engines execute no javascript -> do not se the content -> do not index the page.