On the Script-Tutorials.com site today there's a new tutorial about form validation using a combination of jQuery on the frontend and PHP on the backend.

In this tutorial, I will show you how to create an attractive, pleasant to look form for your website and then I will explain you how to dynamically validate them using Javascript. We'll also cover server-side validation with PHP to make everything 100% safe. This tutorial will help you to add more functionality to your forms which leads to better user experience and better quality of your website.

His sample form (name, password, email and gender) is made from some pretty simple HTML markup. The real trick comes with the jQuery validation on each field handled in an onKeyUp. Included are both a "password strength" method and an email validation method to check the format of the address. Errored fields have their background color changed to indicate that they've failed and some basic validation (length, password match, etc.) are also included. The PHP does much of the same validation once the form is posted and returns any error messages that might have come up.

You can download the code or try out a live demo to see the scripts together in action.

In this recent blog post nikic takes an in-depth look at how large PHP arrays really are - how memory is used in the creation and management of these handy PHP variable types.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage. [...] How much would you expect it to be? [...] Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that's 13.97 MB - eightteen times more than we estimated.

He goes into the details of PHP's memory management and breaks it down into the different totals (for 64 bit and 32 bit OSes) and details on each - zvalue_value, zvalue, cycles collector, Zend MM allocator and the buckets used to isolate one array (hash table/dictionary) from another.

What does this tell us? PHP ain't C. That's all this should tell us. You can't expect that a super dynamic language like PHP has the same highly efficient memory usage that C has. You just can't.

In this new post to Reddit.com, the question is asked "Should I be doing just about everything using REST?" - wondering if their new applications should all sit on top of a web service for their functionality.

I'm pretty new to server-side programming, and actually started out with Python/mod-wsgi. From the ground up, mod-wsgi made a lot of sense. The server gets a request, you route the request. It feels like that's where I should start, so that's pretty much what I'm trying to create with PHP (a REST router - for learning purposes, I know frameworks exist). I'm trying to think of a situation where I wouldn't use a REST interface, but I can't seem to think of one (even for simple cases). Would it be safe to say that using REST is a pretty safe bet, most of the time?

There's some good discussion and answers to his question touching on things like Service Oriented Architectures, some implications of having a web service power an entire application (or applications) and a few comments with some personal experience.

A comment about SOA sums it up well:

You learn to write for your platform in the way developers/partners will have to, so you produce a good quality usable API which encourages development and consumption of your platform.

In this new post to his blog, Johannes Schlüter looks at a high-performance solution to the usual storing PHP session information via a memcache frontend with a MySQL Cluster backend.

Unfortunately even such a system [using MySQL and InnoDB tables] has limits and unfortunately replication is no good solution here to scale further as we will always need a master for writing the updated session data. By using replication we can take some load from it and we can configure a slave which can be promoted to master to keep session alive if the primary master machine fails but at some point in time we need another solution ... but, happy news, again: One doesn't have to look far as MySQL cluster will be happy to help. MySQL Cluster "is a high-availability, high-redundancy version of MySQL adapted for the distributed computing environment," as the MySQL documentation states.

He describes the setup (after pointing to this post about installing MySQL Cluster for memcache) and includes some sample code/SQL/ini settings you'll need to use to get PHP's memcached functionality to cooperate with it.

On the PHPClasses.org blog today there's a new post showing how you can use PHP-GTK to generate websites, not just the more traditional desktop applications people associate it with.

es, you read it right, GTK+, the Gnome Toolkit library, normally used to create desktop applications, can now be used to serve the same applications via the Web to a browser that supports HTML 5 canvas objects. PHP-GTK is a PHP extension that uses the GTK+ library to build PHP desktop applications. So it can eventually benefit for this GTK library enhancements to build PHP-GTK based applications that can be served over the Web to HTML 5 browsers.

Manuel starts by explaining a bit about what PHP-GTK (and GTK+) is and a recent update to GTK+ that allows it to generate output to different backends - Wayland (direct graphics rendering) and Broadway (HTML5 canvas support). There's no example code to go along with the post, but there's a good description of how the output of an X Windows session could be pulled in and displayed in a browser (see this video for a cool example using GIMP and Broadway).

On the IBM developerWorks site, there's a tutorial from Vikram Vaswani showing you how to connect to Wikipedia's API in your PHP application. It shows how to fetch, search and update entries through their backend. The tutorial's a little bit older (from May 2011) but the content is still relevant.

Wikipedia is the ultimate online encyclopedia, containing millions of entries on different aspects of human knowledge. Web application developers are able to access and search these entries through the Wikipedia API. This article introduces the Wikipedia API and demonstrates it in the context of a PHP application, explaining how to search and retrieve different elements of Wikipedia content with PHP.

He starts with a general introduction to the API including example feed results and URL request formats. From there he moves into the code - a mostly Zend Framework-driven example that uses the REST client. He shows how to make requests for categories, full-text search, grabbing raw page content and adding/editing the content of pages.

Kevin Schroeder has a recent post to his blog today looking at how he used Stomp to connect his backend PHP to frontend Flex, a text-based protocol that can be used to connect to a MQ server instance.

In yesterday's post I talked a little bit about some of the details on how I used messaging to connect a front end on demand request to a back end scheduled data processing mechanism. In this post we're going to talk about how to send data from a web page to a running Flex application without using HTTP. It is really quite easy.

His demo application watches a Magento instance and notifies him whenever a new sales comes in. Because of Magento's event-based system, it made the setup relatively easy. He includes the code for the observer on the Magento side and the Zend Framework-based logger code that it calls. Using the AS3Stomp library to make the connection, Kevin sets up the data provider for the Flex app to push the latest sale information into a list.

On the Agile Toolkit News site today there's a recent post looking at a specific part of several of the different PHP-based frameworks out there - the UI or view layer. He wonders why, with UI-specific PHP frameworks out there, why the two can't just play nice together.

I came over this old question on StackOverflow: "Which PHP Framework will get me to a usable UI the fastest?" I couldn't help but wonder, why people are not aware of all those other PHP UI frameworks? There are few, right? If you google for "php ui" you can find them. Those are more generally referred to as UI toolkits. But why those toolkits are not known in the mainstream?

He notes that most of the major frameworks leave you out to dry when it comes to presentation. They don't include much in the way of interface helpers in the name of modularity and backend focus. He suggests a few reasons why this happens and why the UI frameworks out there haven't made it to the mainstream. He gives three rules that could help this situation: view and object handling, giving developers a way to extend things easily and knowing the limitations of what the framework can do.

Mike Willbanks has a new tutorial posted to his blog today about combining memcache and the Zend Framework's caching component to work with session handling.

If I haven't said it before, I suppose I will say it now, I love memcached; it is a wonderful tool to have in your tool belt. However, Zend Framework does not currently have an official cache adapter for Memcached (it has one for the extension memcache but not memcached). [...] About 6-9 months ago, I had implemented a Session_SaveHandler_Cache (although it seems some others have as well), to plug this all in together and keep things consistent in a ZF application. It now enables us to utilize the consistent hashing from the Libmemcached adapter by using the PHP Memcached extension.

He moves on into the details of how to save session information into the memcache with a Zend Framework application, using a Zend_Session_SaveHandler_Cache component (code included) as a light-weight interface between the caching server and the application. He also includes the configuration you'll need to add to your application.ini, additions to the bootstrap and a neat trick using the Subversion revision to prefix the cache entry name (a "versioned" caching system).

Ivo Jansch of Ibuildings has taken a look at a different sort of spin on Apple's iPad device and asked what potential it has to affect the PHP companies out there.

I see the iPad (and the non-Apple alternatives that already exist or are on the way) as a game changer. It brings new ways of consuming content and will reach audiences that the laptop has never reached. [...] In any case, the iPad is a game changer. What does this mean for the web and for tech companies such as us? First, it's nice to see that Apple is pushing open standards heavily with the iPad. [...] Second, the typical architecture behind most iPad apps (and other mobile applications for that matter) is to have a thin client on the device, and a rich API as the backend.

Ivo talks about the one of the key pieces of technology behind it all - the API that your service provides for iPad/iPod applications too hook into. Without a well-built, solid API to interface with, your application can be world class but not be very useful at all.