I finally started clearing out my incoming bookmarks folder, still a long ways to go but a lot of whats left are reference links i’ll need when I do the writeup about my embedded mozilla project (thing pdf generation).

Anyhow here is the summary of todays updates.

library

Ajax.NET - The free library for .NET (C#)

Full Featured C# ajax lib

DWR - Direct Web Remoting

AJAX library for Java

Accesskey Underlining Library

Easy way to add access keys to any html page without changing the actual html

script.aculo.us - web 2.0 javascript

Effect and Drag n Drop library built on top of prototype

SACK - Simple AJAX Code Kit

JavaScript library for performing AJAX

youngpup.net - DOM-Drag

Lightweight JS Drag n Drop lib

article

adaptive path » ajax: a new approach to web applications

Original article that Created the AJAX name

The Man in Blue > This is not another XMLHttpRequest article

Article discussion the decision of JavaScript for “the extras” or for primary features, focuses on Gmail and Google maps

Using the XML HTTP Request object

Article covering the ins and outs of using XMLHttpRequest on various browsers, various requests such as GET POST HEAD are covered

oss

Monket Calendar

GPL AJAX online Calendar written in PHP and JavaScript

Through Planet PHP I saw the blog entry "Is PHP staying the language I want to work with?", for with comments are cowardly disabled. Although the way classes are handled is debatable, moaning that PHP 4.4 breaks "return ($ret)" when returning by reference only shows that the programmer has had no clue about references in the first place. If you place () around a variable, you're making it an expression. You can only return variables by references, not expressions. The return-by-reference in this function never could have worked as it should have in the first place. Clue: Don't use "return ()", but just "return ".

A week ago PHP 4.4.0rc1 was released - this release addresses major problems with references in PHP. But not many people are fully aware of how variables and references actually work in PHP. This is where my latest article in PHP Architect comes into play. It explains in details how assigning variables, passing variables to functions and returning variables from functions work - both by-value and by-reference.

The new PHP4.4 beta is supposed to fix some memory corruption bugs that deal with references. The good news is that it appears to fix some crashes I have been having with PHP4 on Windows. These crashes never happened on Linux, and were so hard to reproduce that essentially I gave up trying to reproduce an example in 4.3.

The bad news is this is quite disturbing, as PHP4 has been out for over 5 years yet no one has found this error before. The fact that PHP4 is known for reliability also suggests that references are a rarely used feature. Now you need to use references a lot in PHP4 to implement OOP well (otherwise all assignments create a duplicate copy of the object instance), which also suggests the takeup of OOP is pretty low in PHP4.

For me, the worst thing about PHP4.4 is that this type of code:

function &dosomething($a)
{
  $b = false;
  return empty($a) ? $b: $a;
}

Will generate a warning in the return statement:

Only variable references should be returned by reference 
  in d:\inetpub\wwwroot\test.php on line 8

This is really weird as $b and $a are variables. This is a known bug since Dec 2004: see bug 20953 at bugs.php.net (ignore the Dec 2002 timestamp in the bug report, bugs.php.net has bugs :-), but no one is looking into it currently. I hope this problem can be fixed without requiring us to change any source code.

I had a nice time in Vancouver, although my visit was very short. This conference only had one track, and this approach has some advantages. For example, the speakers are able to reference material from earlier talks and be reasonably assured that most people in the audience are able to follow. The main disadvantage is the lack of choice and variety, but this was alleviated somewhat by the fact that the entire conference was on such a specific topic.

My talk, the PHP Security Audit HOWTO was one of my most popular yet - I have received more positive feedback from this talk than any talk I've given to date. I think the widespread satisfaction is the result of two things - the conference was based entirely upon a topic that is my particular area of expertise, and my talk was more pragmatic than usual (I tend to recite a lot of theory when discussing security). As a result, I plan to make my talks a bit more practical and relax the theoretical purity. The perfect balance of theory and practicality is hard to find, but I'll start searching for it. :-)

The slides of my talk are currently available on Brain Bulb's web site:

• http://brainbulb.com/talks/php-security-audit-howto.pdf (PDF)
• http://brainbulb.com/talks/php-security-audit-howto.swf (Flash)

I got to hang out with Bruce Perens quite a bit. Although we talked about a number of different things, software patents are clearly the major topic on his mind these days. He has written a good article called The Problem of Software Patents in Standards. It's worth reading.

We just released the first release candidate for PHP 4.4.0. This is a bug-fix only release, the increased middle digit is needed because this release changes PHP's Internal API that causes existing third-party binary extensions to be incompatible with the new version. This release address a major problem within PHP concerning references. If references were used in a wrong way, PHP would often create memory corruptions which would not always surface and be visible. In other cases it can cause variables and objects to change type or class. If you encountered strange behavior like this, this release might fix it. Besides addressing this reference related bug, 46 other bugs are fixed. Please test this release and report any bugs or problems in our bugsystem (after searching first). You can find 4.4.0 RC1 at http://qa.php.net/~derick/

I just packaged PHP 4.4.0RC1, the release announcement goes as follows:

The PHP Team just released it's first release candidate for PHP 4.4.0. This is solely a bug-fix only release, the increased middle digit is needed because this release changes PHP's Internal API that causes third-party binary extensions to be incompatible with PHP 4.3.x.

This release address a major problem within PHP concerning references. If references where used in a wrong way, PHP would often create memory corruptions which would not always surface and be visible. In other cases it can cause variables and objects to change type or class. If you encountered strange behavior like this, this release might fix it.

Besides addressing this reference related bug, 46 other bugs are fixed. Please test this release and report any bugs or problems in our bugsystem (after searching first).

If all goes well I plan to roll a release of 4.4.0 on June 27th. If there are problems a new RC will follow. Only critical bugs are going to be fixed between RC1 and RC2.

For users of eZ publish, this release will make the CMS run much more stable, because of the reference bug fixes.You can find 4.4.0 RC1 at http://qa.php.net/~derick/.

I love good documentation, but do not love writing or maintainting it.. I'm not talking about the nice docbook manuals in PEAR or PHP, but good old reference manuals for C API's.

As anyone who has worked with gtk or gnome will tell you, the semi-automated API docs that are generated for things like gtk and gnome-db, are a godsend. They frequently make the difference between taking 3 hours work to code something up, and a few days. This was one of the reasons why writing DBDO was not too complex.

However, the downside is that DBDO interacts with two API's, gnome-db and PHP. On one side, there is a detailed API documents, along with a highly structured design (gobject). On the other, is a organically grown API, which has evolved, relatively undocumented (except a few articles and the extension guide in the PHP manual).

As DBDO has reached a point where it implements the basic functionality, it has become quite clear that building it (or more specifically the libraries that it depends on) is extremely complex. And while it is increadibly featurefull and easy to code against, it's adoption is always going to be affected by this barrier to entry. (including my enthusiasum to set it up on my clients boxes. So as a parallel effort I've been exploring using PDO as the backend for DBDO.

The Itch
My work on these projects is usually restricted to a couple of evenings a week. As It's not exactly fee paying, and I'm often busy fighting bugs or other workload during the day. It had become quite clear in doing this,  that the complexity of both the PHP and PDO API's, along with lack of documentation was leading to a situation where I was spending at least half of my time looking through lxr.php.net working out which bit of the API I needed to use to do each task.

So in a fit of fustration, I started looking at both documenting, and simplifying the API's (initially of PDO, and then wandering off to consider PHP).

Documentation generation
Looking at the first of these two problems, Documentation, It's clear that the result of gnome/gtk's way of documenting API's is very efficient. It's quite easy to look at any gtk project, and understand the underlying ideas and locate methods that are likely to be the best match, just by browsing through the documents. (although images of the widget would frequently be nice..)

Taking gnome-db as an example, it uses 'gtk-doc' to parse the .h files (using perl), reading a few tags, then merges this with docbook templates, with placeholders for the API details (like synopsis etc.) and then uses a docbook tool to actually render this to HTML (or other formats as required.)

While this works really well, it adds one thing that I started off by saying, the need to actually 'love and care' for the generation of API docs. While It's a great idea,

Truncated by Planet PHP, read more at the original (another 4754 bytes)

Helgi Þormar pointed me to a document that explains the Agavi project's rationale for choosing SimpleTest over PHPUnit.

First off, I have to say that I never really looked at SimpleTest. I hope I will have the time soon to do that. Next, let us take a look at each of their points:

• "We can simply glob for files like *Test.php and give them to SimpleTest and it'll parse them, where as with PHPUnit2 you needed to give it an actual class."
  
  Wrong, there are other ways to add tests to a test suite with PHPUnit2. This will even get easier with the new addTestFile($filename) method that has been added to the PHPUnit2_Framework_TestSuite class in PHPUnit 2.3.0.
  
  
• "Mock Objects."
  
  Yes, PHPUnit2 currently lacks support for Mock Objects. I recently started working on it and I hope to have it done in time for PHPUnit 2.4.0.
  
  
• "There's no assertNotEquals() in PHPUnit2."
  
  assertNotEquals() will be in PHPUnit 2.3.0.
  
  
• "Only allowed to pass objects to assertSame() in PHPUnit2."
  
  assertSame() asserts that two variables reference the same object. Why should assertSame() work on non-objects?
  
  Update: In PHPUnit 2.3.0 assertSame() and assertNotSame() will work on non-objects. See the comment by Bob.
  
  
• "The overhead of setting up the actual tests seems lighter with simpletest and we like to keep things light and simple."
  
  Since I have not yet looked at SimpleTest I cannot comment on this point.

Maybe users of both PHPUnit2 and SimpleTest can add a comment to this entry and explaing why they prefer the one over the other.

Twice in the past week I found myself needing to create or alter database search functionality in some APIs for work. In doing this work, I discovered some techniques that make this process much easier. In line with The Pragmatic Programmer, I found myself exploring the DRY principle (Don't Repeat Yourself), and looking into code generation (this time, SQL) -- basically to exploit my inherent laziness and to make my job easier.

I thought I'd share some of the principles I've discovered for myself as I haven't read much information on the subject. Some of this may be rudimentary for some readers or those who work with more advanced abstraction layers (I suspect DB_DataObject may do much of this), but hopefully the information can be a useful reference for others (myself included).

Continue reading "Search APIs"