Hot on the heels of Yahoo’s Yslow, Google have published Page Speed, a tool they have been using to optimize their own web pages. Now you can use it too.
Page Speed is similar to Yslow in several respects: it’s an add-on to Firebug; it analyses your pages according to a set of performance rules; it draws attention to rules that you score badly on; and it also provides a page activity monitor.
For each rule, Page Speed gives you a general indication of how well you’re doing, in the form of a green tick (good), red circle (bad), or amber triangle (indifferent). You can also hover over a rule to see your percentage score. Page Speed does not provide an overall percentage score, but it does arrange the results in order of importance.
Since my previous article about Yslow 1.0, Yslow 2.0 has been released; this includes a further 9 rules. Let’s now take a look at all these rules—both Page Speed and Yslow.
Page Speed rules shared with Yslow 1.0
These rules are the same as those I previously discussed, although their organisation is different. I’m not going to cover these rules again, but you may still find some of Page Speed’s documentation details interesting.
- Avoid CSS expressions
- Combine external CSS
- Combine external javascript
- Enable gzip compression
- Leverage browser caching
- Minify javascript
- Minimize DNS lookups
- Minimize redirects
- Parallelize downloads across multiple hostnames
- Put CSS in the document head
Page Speed may sometimes advise you to do stupid things. For example, under the “Leverage browser caching” rule, Page Speed suggested that I make __utm.gif cacheable. This tiny gif is used by Google Analytics to help compile your statistics; if you make it cacheable, Analytics will fail to track visitors who retrieved it from a cache. Leave it alone!
Page Speed rules shared with Yslow 2.0
I haven’t yet discussed these rules, so let’s look at them now:
- Minimize cookie size
- Serve static content from a cookie-less domain
- Specify image dimensions
Minimize cookie size
Google’s advice here is more specific than Yslow’s: keep the average cookie size below 400 bytes. I get perfect marks on this from both tools, so I haven’t investigated further.
Serve static content from a cookie-less domain
I score badly on this one, and I expect many other sites will too. Surprisingly, requests for components such as images also include cookies, and these are generally just useless network traffic. The best way to fix this is to use a CDN; obviously, this will also cause you to score well on Yslow’s “Use a CDN” rule.
And yes, this means I’ve changed my mind about CDN’s. Some good, cheap CDN’s are now available, such as SimpleCDN or Amazon Cloudfront. I use SimpleCDN, and have found them to be okay; but I’m not happy with their changing their service offering at short notice, and their Lightning service is currently not working for me—hence my poor score on this rule!
Specify image dimensions
Lazy designers often take a large image and use HTML to squash it down; consequently, the file size can be much larger than is necessary.
Don’t use HTML to resize images; use a graphics program. The width and height attributes in your HTML tag should exactly match the size of the image. Doing so will also give the best appearance, as the browser does not need to scale the image.
I get a perfect score on this, and there’s no excuse for anything less.
Rules unique to Page Speed
In some cases, Yslow’s guidelines may include these topics, but not in the form of an automated check on your web page.
- Defer loading of javascript
- Optimize images
- Optimize the order of styles and scripts
- Remove unused CSS
- Serve resources from a consistent URL
- Leverage proxy caching
- Use efficient CSS selectors
Defer loading of javascript
Before you can test your website against this rule, you must enable “Profile Deferrable Javascript” in the options. You may want to disable it again when you’re done, as it can slow down Firefox. Moreover, this profiling is only accurate on your first visit: to get an accurate result, you must start a new browser session and run Page Speed directly you load your website (before loading a second page).
The idea behind this rule is that javascript slows down your pages even when it’s not actually being used. Even if the script is cached, the browser must load it from disk and execute it. Some javascript functions need to be available before the onLoad event; others don’t. This rule proposes that you split off these latter functions into a separate file. You can then use some trickery to “lazy-load” this javascript after the document has finished loading.
It’s unclear to me whether this lazy-loading is better than simply putting your script at the bottom of the page. If your script is at the bottom, then it will still need to be downloaded and evaluated before the onLoad event is fired (I think), and lazy-loading will bypass this limitation; but what if you’re using a framework such as jQuery, which has the more sophisticated onDomReady event? To be honest, I don’t yet know enough about this issue to make simple recommendations. I suspect, however, that lazy-loading is even faster than simply putting javascript at the bottom of the page.
The good news is that Google Page Speed will identify these uncalled functions for you. Ironically, although I had plenty of uncalled functions, they all came from Google’s own ga.js; I’m not sure I want to mess with that, as it may screw up my Google Analytics stats.
Optimise images
Page Speed automatically creates optimised versions of your images, and offers a link to them. This is similar to running your images through Smush.it.
Optimise the order of styles and scripts
Ideally, you wouldn’t include any javascript in the
, as this violates Yslow’s rule, “Put javascript at the bottom.” If you need to include scripts in the , however, try to get the order right. External scripts should come after all the external stylesheets, and inline scripts should come last of all.Why does the order matter? Because javascript blocks subsequent downloads. While your javascript is downloading and being evaluated, the stylesheet that comes after it can’t be downloaded. Check out the documentation for more details.
Remove unused CSS
I score 100% on this one, which is surprising given that my CSS is an overgrown, tangled thicket of complexity that desperately needs pruning.
Every CSS rule adds bytes to be downloaded, and also requires parsing by the browser. Obviously it’s good to remove dusty old rules that you never use, but even after doing so you may still have a single monolithic CSS file that styles a diverse range of pages. As a result, every page gets a large amount of CSS that’s not needed; if your site is like this, it may be more efficient to split your CSS across multiple modules (although this increases HTTP requests).
Clearly a trade-off is necessary here. I recommend keeping a consistent style as much as possible; apart from the speed benefits, consistency helps visitors and generally looks more professional than constantly changing styles. For large sites with many different types of pages (such as Yahoo), however, it’s often better to split CSS into modules.
Even if your site only needs one stylesheet, it’s a good idea to start thinking in terms of object-oriented CSS, because this makes your CSS simpler, shorter, and more flexible; for an expert explanation of the topic, see Nicole Sullivan’s presentation.
Serve resources from a consistent URL
This one is fairly obvious. To benefit from caching, we need to keep the URL consistent. For example, if on different pages you serve the same image, but from two different domains, then it will get downloaded twice instead of being read from cache.
For most people this shouldn’t be issue; it’s most likely to apply if you’re doing something fancy and automated to split your content across multiple hostnames.
Leverage proxy caching
Now this one is clever. When people visit your website, its resources can be cached not only by them but also by their ISP. Then when another visitor comes via the same ISP, he can download a copy from the ISP’s cache—which will be faster, because it’s closer to him than your server. Page Speed’s documentation recommends that, with a few exceptions, you set a Cache-control: public header for static resources (such as images).
Be careful not to do this for resources that have cookies attached, as you may end up allowing proxies to cache information that should be kept private to a visitor; the best solution is to serve these resources from a cookie-less domain. Also be careful with gzipping: some proxies will send gzipped content to browsers that can’t read it.
I’m not sure how this rule interacts with the use of CDN. Again, this is one I don’t understand well, and I’d welcome discussion on it.
Use efficient CSS selectors
This rule is controversial. The idea is that some CSS selectors are much harder for the browser to parse than others; the most efficient are ID and Class selectors, because these do not require the browser to look higher up the document tree to determine a match.
With this rule, Google is recommending a radical change in the way we write CSS. Specifically, they are suggesting that we add otherwise unnecessary ID’s and classes to the markup, in return for a speed advantage. As an example, they consider the situation where you want different colours on ordered and unordered list items:
ul li {color: blue;}
ol li {color: red;}
That would be the usual way to do it; instead, Google recommends adding a class to each
.unordered-list-item {color: blue;}
.ordered-list-item {color: red;}
No doubt this is faster, but it also takes longer to write and imposes a maintainance burden in your markup. If there were tools that would automatically generate such optimised CSS and the accompanying markup, then it might be worth doing. I suppose you could use server-side coding to generate the markup—for example, using the HTML helper from CakePHP—but this seems a heavy-handed approach.
My scepticism over this rule was initially quashed by the towering authority of Google, but then I looked around to see whether there was any research on the subject. The most respectable tests I could find came from Steve Souders himself, in his post about the performance impact of CSS selectors. Steve found that, in real-world conditions, the maximum possible benefit of optimising CSS is 50 ms; and for 70% of users (i.e. those running IE7 or FF3), it’s only 20 ms. These numbers were obtained with 6000 DOM elements and 2000 extremely inefficient CSS rules. This is pretty much a worst-case scenario; most sites, even complex ones, will have far fewer DOM elements and CSS rules, and their CSS will also be much simpler.
Steve concludes that the potential performance benefits are small, and not worth the cost. I’m inclined to agree, but I’d welcome more information.
Nevertheless, there’s no harm in getting into good habits: some of Google’s recommendations for CSS selectors are quite reasonable, such as not over-qualifying ID and class selectors with an antecedent tag selector (so .errorMessage is better than p.errorMessage). Such coding habits also sit harmoniously with object-oriented CSS.
If you read Steve’s post, be sure to check out Nicole Sullivan’s comment: “Micro-optimization of selectors is going a bit off track in a performance analysis of CSS. The focus should be on scalable CSS.” To me, this seems a much more sensible and maintainable approach than the monomaniacal one recommended by Google.
I do extremely badly on this rule (0%). Although I consider the recommendations to be unrealistic, my terrible score does reflect the excessive complexity and lack of modularity within my CSS.
Rules unique to Yslow 2.0
In some cases, Page Speed’s guidelines may include these topics, but not in the form of an automated check on your web page.
Note that Yahoo’s documentation includes other recommendations that are not checked by Yslow (because they haven’t discovered a sensible way to automate the test). Yslow has 22 rules, but Yahoo lists 34 best practices in total.
- Reduce the number of DOM elements
- Make favicon small and cacheable
- Avoid HTTP 404 (Not Found) errors
- Avoid AlphaImageLoader filter
- Make AJAX cacheable
- Use GET for AJAX requests
Reduce the number of DOM elements
The more DOM elements you have, the longer it takes to download your page, to render it, and to play with the DOM via javascript.
Essentially, this rule asks you to avoid large amounts of unnecessary markup, including markup added by javascript. As an example, yahoo.com has about 700 DOM nodes, despite being a busy page. My home page has 267 DOM nodes, and that could be reduced a lot. You can check how many nodes your page has, by entering the following into Firebug’s console:
document.getElementsByTagName('*').length
Blindly applying this rule can be dangerous (and that’s true of many performance rules). Don’t cut off your nose to spite your face! Markup purists will take this rule as a vindication for using the absolute minimum of markup, and in particular for avoiding the use of container
By all means remove extraneous markup, and also try to limit the complexity of DOM access in your javascript (for example, avoid using javascript to fix layout issues—here I have sinned). But never be afraid to throw in an extra container
Make favicon.ico small and cacheable
You might think that a favicon is not even worth the HTTP request, but you don’t get a say in the matter: the browser is going to request it anyway. Make one, make it small, and put it in the root directory of your website (where the browser will look for it).
Because you can’t change the name of this file—it must be called favicon.ico, or it won’t work—you should be moderate in setting its expiry date. It’s hardly essential that your visitors immediately get your latest favicon, but equally you wouldn’t want it to be cached for 10 years! I give mine a two-month shelf-life.
Avoid HTTP 404 (Not Found) errors
This one is obvious. If your document has broken links, fix them.
Avoid AlphaImageLoader filter
Ah, good old alpha-transparent PNG’s; how we love them! What web designer hasn’t flirted with multi-layer scrolling transparencies at some point? And who has not felt a sense of satisfied mastery, upon forcing IE6 to eat them via a clever hack?
The sobering reality is that, although you can make alpha-transparency work in IE6, you pay a heavy price for doing so. All the hacks rely on Microsoft’s AlphaImageLoader filter. Not only does this filter block rendering and freeze the browser while it’s being calculated, but it also increases memory consumption. To make matters worse, the performance penalty is incurred for each element, not for each image. For example, let’s say you have a fancy alpha-transparent bullet point image for your unordered list items; on a page with 20 bullets, you get the penalty 20 times over.
Use PNG-8 transparency instead, if you can. Incidentally, creating a web page from multiple layers of transparency is probably a bad idea anyway: even in good browsers, these kinds of pages are sluggish to scroll; find a better medium for expressing latent op art.
Make AJAX cacheable, and use GET for AJAX requests
I can’t pretend to understand these rules properly, having never used AJAX. Nevertheless, the ideas are straightforward.
If a resource has not changed since it was fetched, we want to read it from cache rather than getting a new copy; this applies just as much to something requested via AJAX. Steve summarises it thus:
Even though your Ajax responses are created dynamically, and might only be applicable to a single user, they can still be cached. Doing so will make your Web 2.0 apps faster.
Apparently, GET is more efficient than POST, because it can send data in a single packet, whereas POST takes two steps: first send the headers, then send the data. Providing your data is less than 2 kB (a limit on the URL length in IE), you should be able to use GET for AJAX requests.
Conclusions
Google Page Speed is a useful new tool for optimising your websites’ performance. However, some of its advice can be misleading—in particular, CSS selector efficiency is a red herring that distracts you from the more useful goal of building object-oriented CSS.
Yslow is the more mature tool, and I recommend you give it priority. After you’ve finished with Yslow, you may be interested in what Page Speed has to say.
Learning Javascript or Simply the JS Frameworks?
With such libraries as jQuery existing for us as web designers to utilise, is there actually any point in learning the language jQuery runs on? And by learn I don’t mean the very basics, I mean be able to use the underlying language (in this case javascript) to a degree of which you could recreate effects achieved with your framework.
It seems to depend on the language which we are talking about – personally I’ve got experience mostly with jQuery as a Javascript framework, but also popular are PHP frameworks. However it is much harder to work with a PHP framework without a good understanding of PHP, so this article will mainly focus on Javascript and the many popular libraries that exist for it, the most popular being jQuery as I earlier mentioned. In this article we’ll discuss the pros and cons of learning the base language and hopefully try to come to a rounded conclusion. Feel free to add your comments and opinions; it would be great to do a follow up article in a few weeks with your opinions.
Why you should learn the base language?
1. Frameworks don’t do it all.
Whereas frameworks and code libraries often take a lot of the heavy lifting when coding up sites, they can’t do it all. If you come along and think “I need to do this” and your framework does not provide such a function, you’re stuck up a creek without one very handy paddle. Yet if you spend time learning the base language, you can dive back into it and achieve the additional effect your library does not cater for.
2. Employment
Taking Javascript once again as my example, imagine you’ve spent 9 years working with jQuery but never took the time, for whatever reason, to fully learn Javascript. Then you see the perfect job vacancy, javascript developer at a well respected company with very good pay. You’re thinking to yourself that they HAVE to pick you, you’ve worked with javascript for so long, but when you arrive and they ask you about your knowledge of javascript, you’re in trouble. Because unless the company is happy for you to use jQuery, once again you find yourself stuck up that creek without the essential paddle. Ok so this might be a slightly exaggerated example, but hopefully it gets the point across. Even if you know that in every day design you will use a framework, taking a few weeks to learn the base language can pay its dividends in the end.
3. Easier to pick up the framework
If you didn’t understand what a virus was, you would be running into lots of problems trying to configure your virus software would you not? It’s the same with frameworks to a certain extent, if you’ve spent a period of time with javascript, the syntax that jQuery (and most other javascript frameworks) uses is going to be a lot easier to pick up and a lot easier to master.
4. Edit the Source and Plug In!
It’s always great fun to dive into the code and edit the library to suit yourself, you can add your own functions when you find a gap in the library – or if modifying source code does not suit you, most frameworks make it very easy to make additional functionality in the form of plugins, just follow the guidelines, and now you have your very own plugin. Now, if you had little understanding of javascript, this would be a lot harder (but arguably possible, especially in the case of jQuery).
Rounding it all up
So we’ve now looked at why you should, lets see why perhaps you shouldn’t.
1. Why reinvent the wheel?
If my library does this and it does that, why do I need to know what happens behind the scenes? Probably the most popular argument towards not learning the base language. If we should all learn javascript, why bother with libraries?
2. Time = Money
Also a popular and very understandable point to raise, libraries are often very easy to understand and are substantially quicker to pick up and utilise efficiently.
3. It’s Nicer Code
This is my favourite. Libraries produce nicer code then plain old base language (this is very noticeable in the case of javascript/jquery). For instance, take a look at a code for a basic image gallery, first in javascript, and then jquery:
java script:
function showPic(whichPic) {
var source = whichPic.getAttribute(”href”);
var placeholder = document.getElementbyId(”placeholder”);
placeholder.setAttribute(”src”, source);
var text = whichPic.getAttribute(”title”);
var description = document.getElementById(”desc”);
description.firstChild.nodeValue = text;
}
We would then have to interact further with our link items. This code is also less easy to skim through and quickly see what is going on, whereas I think you will agree jQuery simplifies the process:
$(”#imagegallery a”).click(function(event) {
event.preventDefault();
var image = $(this).attr(”href”);
$(”img#placeholder”).attr(”src”, image);
var description = $(this).attr(”title”);
$(”#desc”).empty();
$(”#desc”).text(description);
});
Even if the code does not seem much different, it is nicer. Granted, for such a simple example as this, the code is not going to differ, but get into more complex problems/solutions and it becomes much more clear. The best example in those code blocks is putting some text into an element with an id of “desc”. This is the javascript way:
var description = document.getElementById(”desc”); description.firstChild.nodeValue = text;
Uhh! Yucky nodeValues and all this messing around with children. The jQuery way:
$(”#desc”).text(description)
Much nicer! In one line we have selected our element, and change the contents of the element to the contents of the variable description. It’s an easier, more elegant way of writing things, and this is one of the main pluses for using jQuery.
Conclusion
I said at the beginning that I wanted to come to a rounded conclusion, so now it’s time to live up to expectations! From a personal point of view, I jumped straight into jQuery with a very, very limited knowledge of javascript and never really regretted it. Not until I came to want to do something, searched “jquery function do something” and found nothing. I realised my huge assumption – jquery cannot do everything. jQuery is not a language, jQuery is an add-on that is built on top of the javascript programming language. Metaphorically, you wouldn’t build a house without foundations. The same can be said here. My opinion is that it is by no means a necessity to learn Javascript before jQuery, but it certainly will pay off in the future. I’m not suggesting you should go out there and learn javascript through and through, from beginning to end. But just a little basic knowledge can get you a long way. There are those of you who will argue it is a necessity, those that will argue it’s not really needed. It’s down to personal opinion, I’ve told you mine and it would be great if you could let me and other readers know yours. I hope this article is of interest, please do share your thoughts and leave a comment, it’s always great to see what other people think.
Using Prado – A PHP Framework
Introduction
Recently, I was thinking about a new website idea. This website should be based around word games and let users buy the words used in the games for advertising. The website would be written using the PHP and MySQL. One thing I knew from the beginning, there would be lots of programming involved. Usually I am a person who likes to do everything himself. If I have to develop a non-standard web application I would often decide to write the whole thing myself instead of using an existing CMS or such and writing a plugin.
But this project was going to be slightly larger, and writing everything myself from scratch would have taken far too long. So I decided to use a PHP framework. PHP frameworks are a collection of code, meant to make your life easier and to aid you in the rapid development of dynamic websites. My choice fell on the Prado framework (see www.pradosoft.com).
Although the learning curve for using frameworks can be quite steep at times, the choice to use a framework paid off very quickly. I was able to implement the website which I had in mind in a fraction of the time that it would have taken me to write the whole thing from scratch. You can see the result at www.planetofwords.co.uk
Why I chose Prado
There are a multitude of PHP frameworks out there, and I had to make a decision about which one I wanted to use. I found a nice site comparing lots of different frameworks at phpframeworks.com and what intrigued me was that there were two frameworks following the Event Driven Programming (EVP) paradigm. Being used to developing software with Java and C++, an event driven architecture seemed quite natural to me. I will explain later on what EVP exactly means. One of the frameworks was Prado which I finally decided was going to be the framework of my choice.
Prado, like many other frameworks, supports the Model View Controller (MVC) design. This is neat, because the code is nicely separated from the design. In fact, in Prado, your design goes into special template files. These files don’t usually contain any PHP code. Instead they extend HTML with a number of XML tags and dynamic content tags. The XML tags represent components, such as buttons and hyperlinks, but also more complex components such as wizard interfaces of date pickers. There is no limit to the number of components, as you can easily extend Prado by writing your own components. As the name suggests, the dynamic content tags on the other hand can be used to put dynamic content onto your page. In most circumstances this means that the tag is replaced with the value of some PHP property. Finally, I found Prado to have a very extensive online documentation. They have the compulsory API docs, a forum that is very alive and a very comprehensive QuickStart Tutorial.
Of course I could now say that Prado is the best framework around but that would not be honest since I have not really tried other frameworks. I do think that Prado is definitely one of the better frameworks out there.
That said, it would not be fair to keep quiet about some negative issues that I came across. First of all, I found the configuration files a bit intimidating at first. Until I got to grips with the application configuration, I managed by copying and modifying the configuration files of one of the examples. Also, when I started using the Ajax features I found that the QuickStart Tutorial hadn’t been completed. So I had to bite my way through the API documentation to try to figure out how the Ajax controls work.
Maybe the largest disadvantage of Prado is that it needs PHP 5 to run. So you must make sure that your server not only supports PHP 5, but also handles .php file with PHP 5. Often the server default is to handle .php files with PHP 4, and if you want to make use of PHP 5, the files have to have the .php5 extension. In this case it might still be possible to use Prado, by adding the following lines to your .htaccess file.
AddType x-mapp-php5 .php AddHandler x-mapp-php5 .php
This will map the .php file extension to PHP 5.
Finally, a very important point to consider when using a framework is the speed. While Prado is certainly not lightweight, it does support caching. I really can’t comment on how fast Prado is in comparison with other frameworks, since I have not tested that, but Prado applications can be run in a number of settings such as debug, normal and performance. These settings represent different levels of caching.
A First Example
OK, let’s look at the basics of how to create a page. I will not go into the details of setting up and configuring Prado. This would not fit into the scope of this article. The output of a Prado application is based on page templates. Usually, you will only need to define a single page template for your application. A vary simple page template could look like this:
File: Layout.tpl
<html> <com:THead Title=<%$ SiteTitle %> > <com:TStyleSheet StyleSheetUrl="screen.css" /> </com:THead> <body> <com:TContentPlaceHolder ID="Main" /> </body> </html>
You can see some special tags. The part of the HTML page. The
Basically, a page consists of two files. The first file has the ending .page and contains the HTML code that defines the layout of the page. The second file is a .php file containing a PHP class that controls the page. Apart from the endings, both files have to have the same filename. The PHP class also has to have the same name as the filename.
So let’s look at the .page file first. This looks similar to the layout template above. Here is an example of a simple login form
File: Login.page
<com:TContent ID="Main"> <com:TForm> <h1>Login</h1> <p>Username<br/> <com:TTextBox ID="Username"/></p> <p>Password<br/> <com:TTextBox ID="Password" TextMode="Password"/></p> <com:TButton ID="LoginButton" Text="Login" OnClick="loginButtonClicked" /> </com:TForm> </com:TContent>
The
File: Login.php
<?php
class Login extends TPage
{
public function loginButtonClicked($sender,$param)
{
$username = $this->Username->Text;
$password = $this->Password->Text;
... do authentication and redirect on success ...
}
}
?>
When the login button is clicked, the loginButtonClicked function of the PHP class is called. Technically speaking, an event is raised, which is sent to the page object. The loginButtonClicked function has been linked to the event handler and thus gets called when the event is raised. Inside the class you have access to all the field values by simply using their IDs as class members. $this->Username refers to the TTextBox< ?code> with the ID Username. Being an input field, the text box has a property called text which represents the content of the input field.
That’s it. You can see that code and design are very neatly separated, and with the event driven architecture it is child’s play to handle requests.
The above example is a very simple one. You can have multiple buttons and links inside a form that call different function in you class. You can add validators, that automatically check the input of form fields and display an error message if, for example, the input field is left empty.
Ajax Support
One of the nicer features of Prado is the support of Ajax. This means that events can be raised using JavaScript and the page content can be modified depending on the result of the server sided script. I used this in my project, when people add words to their shopping cart. I wanted to achieve the same kind of feel that you get on Fotolia. When the Add to Cart link is clicked, the word should be added to the cart by the PHP code. On success the Add to Cart text should then change to In Your Cart. So let’s see how this is done. The page contains the following code beneath the word
<com:TActivePanel ID="ToCart" > <p class="action"> <com:TActiveImageButton ImageUrl="images/tocart.png" onClick="onToCartClicked"/> <com:TActiveLinkButton onClick="onToCartClicked">Add to Cart</com:TActiveLinkButton> </p> </com:TActivePanel>
This displays an image of a shopping cart and a link saying Add to Cart. Both of these are contained inside an TActivePanel. Prado uses the “Active” in an elements name to show that is an Ajax enabled element. When either of these is clicked, an Ajax request is sent to the server and the onToCartClicked function is called. This function looks like this
public function onToCartClicked($sender, $param)
{
... add word to shopping cart ...
if ($success)
{
$this->CallbackClient->addCssClass($this->ToCart,'inactivelink');
$this->CallbackClient->replaceContent ($this->ToCart,'<p class="action">In Your Cart</p>');
}
}
When the word is successfully added to the shopping cart, the content of the active panel is modified and a CSS class is assigned to it. The text now reads In Your Cart and the CSS class makes the text appear slightly faded. This signals the user an inactive link.
I found it extremely easy to develop Ajax enabled applications. Behind the scenes Prado uses the Prototype and Scriptaculous libraries. This means you can make use of all the Scriptaculous effects like fading in and out of elements etc.
Conclusions
Prado is a nice PHP framework. It made the development of a relatively large website possible for me. If I had developed the whole website from scratch without a framework, it would have probably taken me at least twice as long. Without using a framework, I would not have dared to include as much Ajax in the website as I have now.
This is the first website that I developed using a PHP framework and I don’t regret my choice. While Prado is the only framework I have gained experience with, I am quite thrilled by it. I will definitely never develop a PHP website again without using a PHP framework. And unless someone can come up with very convincing arguments, I will certainly stick with Prado.
