Pagination is a topic that has been done to death -- dozens of articles and reference classes can be found for the management of result sets ... however (and you knew there was a "however" coming there, didn't you?) I've always been disgruntled with the current offerings to date. In this article I offer an improved solution.
Some pagination classes require parameters, such as a database resource and an SQL string or two, to be passed to the constructor. Classes that utilize this approach are lacking in flexibility - what if you require a different formatting of page numbers at the top and bottom of your pages, for example? Do you then have to modify some output function, or subclass the entire class, just to override that one method? These potential "solutions" are restrictive and don't encourage code reuse.
This tutorial is an attempt to further abstract a class for managing result pagination, thereby removing its dependencies on database connections and SQL queries. The approach I'll discuss provides a measure of flexibility, allowing the developer to create his or her very own page layouts, and simply register them with the class through the use of an object oriented design pattern known as the Strategy Design Pattern.
What Is the Strategy Design Pattern?
Consider the following: you have on your site a handful of web pages for which the results of a query are paged. Your site uses a function or class that handles the retrieval of your results and the publishing of your paged links.
This is all well and good until you decide to change the layout of the paged links on one (or all) of the pages. In doing so, you're most likely going to have to modify the method to which this responsibility was delegated.
A better solution would be to create as many layouts as you like, and dynamically choose the one you desire at runtime. The Strategy Design Pattern allows you to do this. In a nutshell, the Strategy Design Pattern is an object oriented design pattern used by a class that wants to swap behavior at run time.
Using the polymorphic capabilities of PHP, a container class (such as the Paginated class that we'll build in this article) uses an object that implements an interface, and defines concrete implementations for the methods defined in that interface.
While an interface cannot be instantiated, it can reference implementing classes. So when we create a new layout, we can let the strategy or interface within the container (the Paginated class) reference the layouts dynamically at runtime. Calls that produce the paged links will therefore produce a page that's rendered with the currently referenced layout.
http://www.sitepoint.com/article/perfect-php-pagination/
Saturday, September 20, 2008
How a Perfect PHP Pagination Works ?
What's new in PHP 5.3 ?
PHP 6 is just around the corner, but for developers who just can't wait, there's good news -- many of the features originally planned for PHP 6 have been back-ported to PHP 5.3, a final stable release of which is due in the first half of this year.
This news might also be welcomed by those that wish to use some of the new features, but whose hosting providers will not be upgrading to version 6 for some time -- hosting providers have traditionally delayed major version updates while acceptance testing is performed (read: the stability has been proven elsewhere first). Many hosting companies will probably delay upgrading their service offerings until version 6.1 to be released. A minor upgrade from 5.2.x to 5.3, however, will be less of a hurdle for most hosting companies.
This article introduces the new features, gives examples of where they might be useful, and provides demo code to get you up and running with the minimum of fuss. It doesn't cover topics such as installing PHP 5.3 -- the latest development release of which is currently available. If you'd like to play along with the code in this article, you should install PHP 5.3, then download the code archive. An article on installing PHP 5.3 can be
found on the Melbourne PHP Users Group web site.
Namespaces
Before the days of object oriented PHP, many application developers made use of verbose function names in order to avoid namespace clashes. Wordpress, for example, implements functions such as wp_update_post and wp_create_user. The wp_ prefix denotes that the function pertains to the Wordpress application, and reduces the chance of it clashing with any existing functions.
In an object oriented world, namespace clashes are less likely. Consider the following example code snippet, which is based on a fictional blogging application:
Read More Here
Google Chrome's Multi-process Architecture
Unlike most current web browsers, Google Chrome uses many operating system processes to keep web sites separate from each other and from the rest of your computer. In this blog post, I'll explain why using a multi-process architecture can be a big win for browsers on today's web. I'll also talk about which parts of the browser belong in each process and in which situations Google Chrome creates new processes.
1. Why use multiple processes in a browser?
In the days when most current browsers were designed, web pages were simple and had little or no active code in them. It made sense for the browser to render all the pages you visited in the same process, to keep resource usage low.
Today, however, we've seen a major shift towards active web content, ranging from pages with lots of JavaScript and Flash to full-blown "web apps" like Gmail. Large parts of these apps run inside the browser, just like normal applications run on an operating system. Just like an operating system, the browser must keep these apps separate from each other.
On top of this, the parts of the browser that render HTML, JavaScript, and CSS have become extraordinarily complex over time. These rendering engines frequently have bugs as they continue to evolve, and some of these bugs may cause the rendering engine to occasionally crash. Also, rendering engines routinely face untrusted and even malicious code from the web, which may try to exploit these bugs to install malware on your computer.
In this world, browsers that put everything in one process face real challenges for robustness, responsiveness, and security. If one web app causes a crash in the rendering engine, it will take the rest of the browser with it, including any other web apps that are open. Web apps often have to compete with each other for CPU time on a single thread, sometimes causing the entire browser to become unresponsive. Security is also a concern, because a web page that exploits a vulnerability in the rendering engine can often take over your entire computer.
It doesn't have to be this way, though. Web apps are designed to be run independently of each other in your browser, and they could be run in parallel. They don't need much access to your disk or devices, either. The security policy used throughout the web ensures this, so that you can visit most web pages without worrying about your data or your computer's safety. This means that it's possible to more completely isolate web apps from each other in the browser without breaking them. The same is true of browser plug-ins like Flash, which are loosely coupled with the browser and can be separated from it without much trouble.
Google Chrome takes advantage of these properties and puts web apps and plug-ins in separate processes from the browser itself. This means that a rendering engine crash in one web app won't affect the browser or other web apps. It means the OS can run web apps in parallel to increase their responsiveness, and it means the browser itself won't lock up if a particular web app or plug-in stops responding. It also means we can run the rendering engine processes in a restrictive sandbox that helps limit the damage if an exploit does occur.
Interestingly, using multiple processes means Google Chrome can have its own Task Manager (shown below), which you can get to by right clicking on the browser's title bar. This Task Manager lets you track resource usage for each web app and plug-in, rather than for the entire browser. It also lets you kill any web apps or plug-ins that have stopped responding, without having to restart the entire browser.
Read More Here
Google Chrome's DNS Prefetching (or Pre-Resolving)
A major goal of Google Chrome was to improve user enjoyment and value in web surfing. Critical to that is increasing the responsiveness of the browser to user input, or reducing user perceived latency. Measurements in the browser have shown that a significant amount of time is traditionally spent waiting for DNS to resolve domain names. To speed up browsing, Google Chrome resolves domain names before the user navigates, typically while the user is viewing a web page. This is done using your computer's normal DNS resolution mechanism; no connection to Google is used. As a result, user navigation time in Google Chrome when first visiting a domain is on average about 250ms faster than traditional browsing, and the occasional but painful 1-second-plus delays are almost never experienced.
How it works, and how much it helps.
First off, DNS Resolution is the translation of a domain name, such as www.google.com, into an IP address, such as 74.125.19.147. A user can't go anywhere on the internet until after the target domain is resolved via DNS.
The histograms at the end of this post show actual resolution times encountered when computers needed to contact their network for DNS resolutions. The data was gathered during our pre-release testing by Google employees who opted-in to contributing their results. As can be seen in that data, the average latency was generally around 250ms, and many resolutions took over 1 second, some even several seconds.
DNS prefetching just resolves domain names before a user tries to navigate, so that there will be no effective user delay due to DNS resolution. The most obvious example where prefetching can help is when a user is looking at a page with many links to various unexplored domains, such as a search results page. Google Chrome automatically scans the content of each rendered page looking for links, extracting the domain name from each link, and resolving each domain to an IP address. All this work is done in parallel with the user's reading of the page, hardly using any CPU power. When a user clicks on any of these pre-resolved names to visit a new domain, they will save an average of over 250ms in their navigation.
If you've been running Google Chrome for a while, be sure to try typing "about:dns" into the address bar to see what savings you've accrued! Humorously, this prefetching feature often goes unnoticed, as users simply avoid the pain of waiting, and tend to think the network is just fast and smooth. To look at it another way, DNS prefetching removes the variance from surfing latency that is induced by DNS resolutions. (Note: If about:dns doesn't show any savings, then you probably are using a proxy, which is resolving DNS on the behalf of your browser.)
There are several other benefits that Google Chrome derives from DNS prefetching. During startup, it pre-resolves domain names, such as the home pages, very early in the startup process. This tends to save about 200-500 ms during application startups. Google Chrome also pre-resolves the host names in URLs suggested by the omnibox while the user is typing, but before they press enter. This feature works independently of the broader omnibox logic, and doesn't utilize any connection to Google. As a result, Google Chrome will generally navigate to a typed URL faster, or reach a user's search provider faster. Depending on the popularity of the target domain, this can save 100-250ms on average, and much more in the worst case.
If you are running Google Chrome, try typing "about:histograms/DNS.PrefetchFoundName" into the address bar to see details of the resolution times currently being encountered on your machine.
The bottom line to all this DNS prefetching is that Google Chrome works overtime, anticipating a user's needs, and making sure they have a very smooth surfing experience. Google Chrome doesn't just render and run Java Script at a remarkable speed, it gets users to their destinations quickly, and generally sidesteps the pitfalls surrounding DNS resolution time.
Of course, the best way to see this DNS prefetching feature work, is to just surf.
Read More Here
Google Chrome Memory Usage - Good and Bad
A lot of smart people are doing some serious tire kicking on Google Chrome. Now with several days of testing under their belts, we're seeing many observations about Google Chrome's memory usage. I've just posted a techie document about memory over on the developer website as an initial brain-dump of our current thinking about memory usage within Google Chrome. This article is a quick summary.
Measuring memory
If you're measuring memory in a multi-process application like Google Chrome, don't forget to take into account shared memory. If you add the size of each process via the Windows XP task manager, you'll be double counting the shared memory for each process. If there are a large number of processes, double-counting can account for 30-40% extra memory size.
To make it easy to summarize multi-process memory usage, Google Chrome provides the "about:memory" page which includes a detailed breakdown of Google Chrome's memory usage and also provides basic comparisons to other browsers that are running.
Read More Here
Thanks,
Webnology Blog Administrator
