Introduction to the problem

When the HSlider is set up with two or more thumbs there’s a gap between them always. The problem is that you may want to put them on one single value of the slider, but it’s not possible.

First: hide your thumbs

The quick solution is to make custom skin for the thumbs, setup the height and width of the thumb to be 1px and make a transparent background image for skinning them. That of course does not solve the problem. There’s still gap of 1 value between the thumbs, and still you cannot select one single value with both of them. (more…)

In that case I need to scroll my page onclick event to show the fully loaded content in a <div>, which just loaded content.

That can be done with window.scrollBy(x, y). Where if you’d like to scroll vertically you’ve to change the y value.

Base64 and image files

For those who don’t know base64 it’s an encoding format for any data. In that case with the images we can simply say, that base64 equals to text (string) representation of the image itself. In most cases you’ve image tags with src attribute pointing to the http source of the image.

Overview of the problem

Let’s say we’ve a HTML document with 100 images into. That’s a rare case I agree, but sometimes it happens. You’ve to preload the thumbnails of an image gallery where only one image is displayed in a bigger size. As I mentioned before the progressive JPEG suits better for a large image but for the thumbnails you’ve to use baseline JPEGs.

Note: In fact the technique with base64 representation of the images is not well known. I think that’s because there are not so much examples with pages with more than 100 images.

But anyway. We’ve the HTML document with 100 images (100 <img> tags). That means directly 101 requests/responses from the server. In my tests on my localhost, which is supposed to be fast enough, that case loaded 2 MB with a simple small JPEG for the image, loaded 100 times, and approximately 3 seconds. Which yet again on the localhost is extreamly slow. The image is on my machine, the server is here… what else?

How to put the images inline?

The other way to do that is to put all you images in you HTML document. Than the first and more important rule for optimization (see more here), to make fewer requests is done. You now have only one request. And with the response you’ve all 100 images. That’s good when you’ve different images, cause every repeatable element in your CSS should be made with HTTP request once and than repeated with the CSS. In other way you risk the size of the document transfered in the web.

The results

The second case with the inline images and the only one request is giving me an average response time of 900ms. The size of the document is bigger, yes. I had 5KB for the HTML with no base64 images, and then the size increased to 45KB. That’s 9 times more. But however 45KB is nothing for the web, instead of all those 2 MB in the previous test.

How to make your images to strings?

Speaking in PHP terminology there is a function called base64_encode, which with a combination of file_get_contents(imagefile), make the files a base64 string.

Is there any issue?

Yes there is. First you cannot have your image files in a remote server, cause file_get_contents must read only from the local filesystem. Than if you process all those files before returning them to the client, where’s the point? You loose all that time you’ve spent with the technique.

The reasonable solution

I think this technique is good for cases like the one described at the beggining. You’ve a page with more than 100 images. Then you’ve the base64 representation already. Let say you have it in your database as string and don’t need to convert it everytime you return the image. That may happen on upload of the image and the image enters the database with its base64 representation, and it’s done.

What’s Zend Layout

Everybody knows that sometimes you need header and footer for almost every page. In Zend Framework you don’t need to include them in every template page, as it will be if you were using Smarty for instance. You just need to use Zend_Layout. It’s easy and it’s helpful.

What if you don’t need layout for a controller action?

Well if you have to have a given controller action with no use of Zend_Layout, you just need to disable it.

How …

… simply by placing this line in you controller action:

$this->_helper->layout->disableLayout();

The Problem

Well usually the URL is formed like so – http://example.com/index.php#anchor1, if you have anchors, of course. And the problems is simple to define. With PHP you cannot grab the anchor part of the link (that anchor1 in the example). That’s of course normal behaviour, the anchors are used by the client (your browser usually) to position the page at a specific location, and being a client side technique is simple to guess that PHP cannot access them.

Why We Need Such a Thing?

Today the web is more and more full of such an Ajax rich applications, almost every one of them don’t refresh the page and use anchors to save the path of the user, and that’s how they manage the bookmarks of a specific state in the page. We often need this technique, cause every other change in the URL, but the anchors, invoke a reload of the page, which is bad. But however why don’t we use directly this anchors from the Ajax application? That’s because we’d like to speed up things. We load the page with an anchor in the URL, like so:

http://example.com/index.php#load-me-first

but in that case the page should load, than the JavaScript should grab the anchor, and than to process via Ajax request the data from the server … and even that is not enough, cause than the data should be placed on the right place in the page.

Note: In fact, most of the fully flash based sites work on the same schema.

We need the initial load to happen directly with PHP which is much more faster. But the problem is that, as I said PHP cannot read the anchor of the link. If you have http://example.com/index.php#load-me-first, none of the _SERVER variables will return the anchor, because as I noticed that’s client side issue.

The Solution

Well we need to combine the client and server side techniques to solve the problem. There comes JavaScript combined with PHP and all this is made with the help of the Cookies.

Let see the situation. If we have an anchor in the URL we can easily grab this with JavaScript:

<script>

var query = location.href.split(‘#’);

</script>

Now the query[1] has the value of the anchor part of the URL. Now you can set this in a cookie.

<script>

var query = location.href.split(‘#’);

document.cookies = ‘anchor=’ + query[1];

<script>

Note: it’s important to setup the cookie to be persistent only for this session so next time you enter the site there should not be such an existent one.

So far so good, what we need more is just to read that cookie in PHP, so you can put this PHP code above.

<script>

var query = location.href.split(‘#’);

document.cookies = ‘anchor=’ + query[1];

<script>

<?php

echo $_COOKIE['anchor'];

?>

Of course, yes. This is not working correctly. In fact it’s working correctly from the second load on, but on the initial load of the page the _COOKIE array does not has any anchor key inside. That’s because this part of the code is executed before the browser setup the cookie on the client.

The Workaround

Well there is a workaround. You simply should wait for the cookie to come from the server. Like so:

<script>

var query = location.href.split(‘#’);

document.cookies = ‘anchor=’ + query[1];

<?php if (!$_COOKIE['anchor']) : ?>

window.location.reload();

<?php endif; ?>

<?php

echo $_COOKIE['anchor'];

?>

Now everything is OK. You can parse the _COOKIE['anchor'].

Important

It’s exteamly important to put the <script> tag as high as you can, so the browser will setup and check for the cookie before anything is rendered to the page. In that case the reload of the page is so quick so you will not experience any delay at all.