klog

Author: Kevin MacArthur, Publisher: APress

Overview: this book is absolutely jam-packed with information useful to the medium-advanced PHP coder. SPL is described over a few chapters, and a quick intro to Zend’s MVC framework is provided. Of particular interest to me were the final chapters, to do with certificate-based authentication, and a chapter near the beginning describing the upcoming features of PHP6. Great book - I really enjoyed it.

Technically, this book is hard to fault. Kevin is very knowledgeable about his stuff and puts across that knowledge easily. It was a real pleasure to read. There were a lot of things in the book that I had only the vaguest idea about before hand - like Phing and Xinc - I will definitely be sitting down to read more about those techs when I get the time.

The book covers SPL, MVC, PHP6, and discusses issues such as continuous integration, web 2.0, source repositories, and digital certificate authorisation.

Kevin states at the beginning that this book was written for advanced PHP developers. I would posit that the book should be given to moderate developers who are looking to develop their project management skills - a lot of pages were devoted to tools and methods that are very useful for managing medium to large projects (continuous integration, MVC).

It is very hard to find fault with this book, but I’ll do my best!

While the title of the book mentions “frameworks”, only the Zend Framework is actually looked at. Not a single other framework was named, although it was mentioned that they exist. I think this is just not on - at the least, Kevin should have provided a few reasons why he chose to describe Zend over everything else. I was looking forward to reading more about such things as Cake, Symfony, et al.

The testing and continuous development sections were not long enough - the author practically raced through the description of continuous integration and did not spend much time on it. I was hoping for some discussion on such issues as keeping databases uptodate throughout development. In a book with this much information, it’s hard to focus on everything, but I think more time should have been spent on this crucial problem in development.

The “web 2.0″ section covered the JavaScript XMLHTTPRequest object but not much mention was given to the higher-level stuff such as JavaScript frameworks and integration of those frameworks with PHP - I like the Sajax and Xajax libraries myself. Other people might go for the more mainstream (and complete) frameworks such as Dojo, MooTools and jQuery. Either way, I think this section should have included more integration with PHP or have been left out altogether.

SOAP was covered in the WebServices section, but not much mention is given of XML-RPC, REST, etc. It’s also not mentioned that JSON (my favourite object representation, described elsewhere in the book) can be used as a transport language for WebServices as well. This appears to be the same problem as the Zend section - Kevin chose a single tech to describe, without giving a good reason why he chose that or even what the alternatives are.

Forgetting about those minor details, I’d have to admit that that was a damned fine read. I would buy the book, and if you’re a serious PHP developer, so would you too.

FCKeditor

If your project uses FCKeditor, then you may need to re-think how the FCKeditor instance is attached to the page - Firefox 3 has changed something (I’m not sure what) which causes FCKeditor to fail in some cases (not all).

The cause is not absolutely clear (the first bug mentioned above states that it relates to loading file:/// URIs, but in my case, that’s not true), but I have managed to fix a few cases by avoiding the dynamic method of on-the-fly initialising FCKeditor (var o=new FCKeditor('blah');o.ReplaceTextarea();, etc) and instead creating the required IFrames and hidden inputs manually. This is a hack - not a true solution, so hopefully someone at the source (FCKeditor) will fix the problem soon.

This bug in their Trac is probably the exact problem I’m experiencing. Note that that bug was “confirmed” by a member of the dev team 9 months ago, and has since been ignored by them.

LCD vertical lines

A few months back, my Acer Travelmate 2420 started developing vertical lines. It would have been expensive to replace the screen, so I instead opted to go for a new machine. I gave the machine to my son Jareth, who doesn’t complain too much about it.

Yesterday, while troubleshooting a sound problem, I noticed that if the screen was twisted /just so/, then the lines vanished. After a bit of experimentation, I found that pressure applied in a certain spot at the back of the screen would clear the lines.

So, there was no other option - I needed to fix it. I got my screwdrivers out, took the screen apart, and MacGyvered a solution together with some paper I had lying around - fold it into a thin strip, then fold one end of it down to form a bulky part, then slot that into place between the screen and the back cover so the bulky part is at the pressure point. When the cover was replaced, the vertical lines were gone.

I have no idea how long the solution will work for, and I am guessing that the solution is causing stress to parts of the screen which may cause a more complete failure at some point in the future, but for now, Jareth is very happily watching a DVD on his machine (Bear In The Big Blue House - Shapes, Sounds And Colours on Fedora 9, KDE4, for those interested).

Missing sound

As stated, Jareth’s laptop had a sound problem - as in lack of sound. this was eventually traced to pulseaudio simply not starting. The solution was to add pulseaudio --system & to /etc/rc.local so the sound engine would start when the machine started.

I’m currently working on removing MooTools from KFM. While doing that, I’m also trying to speed up KFM as much as possible. The reason I’m removing MooTools is that I feel that it is inefficient in some things, and I don’t like how it tries to attach itself to everything in the document - if you retrieve an element with ID ‘test1′ using $('test1'), then inspect the element, you’ll find that MooTools has added itself to the element. This happens a lot. They call it a feature.

I’m replacing it with jQuery. jQuery has a strong community and a database of plugins. I like it. While it is still possible to write inefficient jQuery code, I feel it is a bit more difficult than in MooTools.

change your events code

John Resig’s tutorial recommends adding events to objects using something like this:

$j('#the_element').click(eventToHandleClicks);

While that is very neat, and perfectly fine in most cases, it’s not very efficient when you’re adding it to hundreds of elements on a page when the elements are built up using functions as happens in KFM. (ie; the elements are added ad-hoc, and the events are added at the same time as the element creation)

The method I would recommend is this:

$j.event.add(document.getElementById('the_element'),'click',eventToHandleClicks);

In this case, we avoid the internal stuff that happens in $j() by replacing it with the fast browser function document.getElementById(), and we also jump straight to the addition of the event with the static $j.event.add() instead of $j().click() which is meant to work on an arbitrary number of elements and is therefore slightly slower.

The same applies to generic addEvent() code:

$j('#the_element').addEvent('mouseover',mouseOverEvent);

Again, replace that with:

$j.event.add(document.getElementById('the_element'),'mouseover',mouseOverEvent);

defer creation of events

Let’s say you have a hundred elements to create. Each element has a mouseover, click and mouseout event to be added. That’s 300 operations.

function inLink(){
  window.status='in link';
}
function outLink(){
  window.status='out of link';
}
function clickLink(){
  window.status='link clicked';
}
var i,el;
for(i=0; i<100; ++i){
  el=document.getElementById('link'+i);
  $j.event.add(el,'mouseover',inLink);
  $j.event.add(el,'mouseout',outLink);
  $j.event.add(el,'click',clickLink);
}

This is a very common piece of code. However, it is inefficient, both speed- and memory-wise. If you have 100 links, and are likely to only click one, then why bother adding the mouseout and click events to the rest?

The answer is to add those events upon mouseover and make sure they’re only added once.

function inLink(){
  window.status='in link';
  if(this.eventsAdded)return;
  $j.event.add(this,'mouseout',outLink);
  $j.event.add(this,'click',clickLink);
  this.eventsAdded=true;
}
function outLink(){
  window.status='out of link';
}
function clickLink(){
  window.status='link clicked';
}
var i,el;
for(i=0; i<100; ++i){
  el=document.getElementById('link'+i);
  $j.event.add(el,'mouseover',inLink);
}