If you’re familiar with the new jQuery version 1.4. released recently, I’d suppose you’d like to get its fresh cheat sheet.
Such has been published on http://labs.impulsestudios.ca/jquery-cheat-sheet or you can find it here.
Although it may sound strange I’ll say why I’m using caching. Because it speeds up the site! Yeah there’s no other reason that may be so important as this is.
The caching is not a process invented in the last year, it’s useless to describe why do you need it, but however my intention is to describe how to make it work with Zend Framework.
The docs page of Zend_Cache is pretty clear about everything and I’ll describe the most important part of the cache setup.
First setup the cache back and frontend options. You need to decide where to save the cache files, how to cache them, and what lifetime do they need.
The most used cache configuration is, as you may guess, this one described into the doc page. Setup the front and backend options is just as simple as:
$frontendOptions = array(
'lifetime' => 7200, // cache lifetime of 2 hours
'automatic_serialization' => true
);
$backendOptions = array(
'cache_dir' => './tmp/'
// Directory where to put the cache files
);
// getting a Zend_Cache_Core object
$cache = Zend_Cache::factory('Core',
'File',
$frontendOptions,
$backendOptions);
Because all this is well described into the doc page, which you can found here I won’t talk about it. But I’ll talk only about one sole thing. How much the cache must live? What should be its lifetime.
The answer is simple. If you have some basic statistic of your site traffic and you don’t change much the data you can prefer longer cache period. But imagine the site’s making 1000 visits per minute! Than even if you cache every minute and the cache expires every minute will be a success and the user perception will be really great. From those 1000 visitors only few will wait until the cache’s built and the other hundreds will receive really fast response!
Be careful when you cache only because you can overflow the directory where you cache, which will be difficult though.
In other way many people are thinking about Zend Optimizer and its work with Zend_Cache. These are really different things. Zend Optimizer has nothing to do with your code it is a PHP caching tool. As you may know PHP interpreter mingles the code into “machine like” code, which in turn can be cached into the RAM with the help of Zend Optimizer. Checkout more here.
As the jquery14.com says: “jQuery 1.4.1 is now out! This is the first bug fix release on top of jQuery 1.4, fixing some outstanding bugs from the 1.4 release and touching up some gaps in the API.”
It’s good that the community responded so quickly to the new release!
I’m sure you know how to prevent the default action of a link when onclick event is attached to it. Yes, it is a common task and by simply adding a return false; at the end of the method called on click it simply doesn’t call the refresh the page. This is really an everyday task. To describe it first, let’s imagine there’s a link with # href value:
<a onclick="”myFunc()”" href="”#”">click here</a>
Than the definition of myFunc() is something like that:
function myFunc() {
...
return false;
}
If that “return false” part was missing you simply get additional # in the uri of the page and worse – you may be scrolled to the top of the page, because of the lack of an anchor with empty name.
OK, but we know how to deal it! But what happens when you don’t attach click event but mousedown/mouseup pair? It may seem the same thing but it is not!
When you place return false on both event handlers of the mousedown/up events nothing happens, there is a # on the end of the uri and yes the document is scrolled.
Simply by adding onclick event! We already know that this is working and prevents the default action. Just do the following:
$(‘#element_id’).mousedown(function(){
...
return false;
});
$(#element_id’).mouseup(function() {
...
return false;
});
// this doesn’t work like preventing the default refresh
// action until ....
$(‘#element_id’).click(function() {
return false;
});
// is added
When I say better documentation I don’t mean it was somehow bad before. The difference is that now the doc pages are version specific, and this is particularly good for those working with older versions of the framework.
In fact most of the cases are just like that, whether because it’s difficult to migrate some code that’s already too different from the original framework itself or because the new version is considered “not so stable”.
Whatever the reason is the version specific docs will be received very well from the community.