Google results right-click FireFox reset

When you use FireFox, you might notice that the Google search results show a different URL once you click on a link.

Google has been experimenting/implementing/… this for quite some time now but apparently not in all countries/browsers/users/… simultaneously?

It is caused by some JavaScript script that re-routes the link through Google in order for them to be able to track clicks. Although I can imagine some people make a fuss about this, personally I do not care as long as the results are good.

But this becomes annoying once you right-click a link to copy it (e.g. in an e-mail): I want to send the original URL and it sounds a bit strange to track other people clicking on my search result (for some good reason it probably makes sense to Google though).

You can easily avoid this (at least in FireFox) with a Greasemonkey script. Scripts have been available for some time, but I made a simple one with jQuery that does the trick for me.

Download or install jQuery Google click tracking removal script.

View specific JavaScript with Zend Framework

Because Zend Framework (and in this case also the MVC part) lets you choose how you structure your project, you may have doubted about where to place client-side JavaScript scripts.

icon_javascript

Personally, I place application-wide scripts in something like /media/js/application.js, but in many cases you have scripts that are only applicable to a certain view. Of course we want to avoid having a JavaScript file for each view somewhere in a general JS folder like /media/js.

Putting the JavaScript straight into the view also isn’t optimal since Zend_Layout can for instance put more HTML below it and client-side scripts should be right before the </body> tag.

I thought it would be nice to be able to have [viewname].js files inside the views/[controller] directories. E.g.:

/application
  /controllers
     BugController.php
  /views
     /bug
        index.phtml
        index.js

That makes development easier since your view-specific scripts are still as close to your view as possible, but separated in a .js file so your IDE/editor can parse them as JavaScript. In my case I thought it would also be nice if the .js file would be parsed like the view itself meaning that any variables assigned to the view can also be used in the JavaScript file.

The Zend_Controller_Action postDispatch() method provides a possibility to parse and include the client-side script into the inlineScript view helper where it belongs:

public function postDispatch()
{
    $request = $this->getRequest();
    $controllerName =  $request->getControllerName();
    $actionName =  $request->getActionName();
    foreach ($this->view->getScriptPaths() as $path) {
        $fileName = $controllerName . DIRECTORY_SEPARATOR
            . $actionName . '.js';
        if (file_exists($path . $fileName)) {
            $view = clone $this->view;
            $script = $view->render($fileName);
            $this->view->inlineScript()->appendScript($script);
        }
    }
}

As you can see, the regular view script is cloned so that the same information is passed to the JavaScript file.

The only thing you now need to do is subclass Zend_Controller_Action, paste in the code above and use that new class in your controllers:

class MyController extends My_Controller_Action {}

Happy JavaScripting!

Ext on its way to world domination

Ext JS Core

While Ext JS turns 3 and already had a turbulent past, the development team has come up with a new project & licensing structure.

While it is still in beta, Ext JS seems to have been split up in an Ext JS Core library, which is a complete alternative to jQuery, Prototype, Dojo, Mootools,… and the upcoming full Ext JS library, which will probably include the features you know Ext best for: the slick user interface.

Together with the beta release of the core version, a bunch of popular widgets have been mimicked: Lightbox, Tabs, Image rotation and Context menu’s.

The Ext JS Core is MIT licensed, which basically means it is completely free. There was of course no other way to go because of the competition. But since the core version completely eliminates the use of any other JavaScript framework, it will pave the way even more for the full version. Together with the already huge Ext community (> 70000 registered members), world domination can’t be far away.

Although I have had a lot of fun with jQuery, I guess I no longer have a reason to use it. They seem to have done a fine job to offer a replacement (with a file size that almost matches)!

XHTML compliant online rich-text editor

With the launch of a new JavaScript XHTML WYSIWYG editor, Xinha, a quick overview of the competition.

Popular rich-text editors that support XHTML are:

  • TinyMCE: one of the first and still very popular. Has almost every feature you can imagine (including resizing of images). Used by WordPress and many other CMS’s. Liberal license.
  • XStandard: despite the nice features, their licensing is a major issue. You pay per user and I assume for most that isn’t an option. It explains why their customers are large enterprises. The Lite version misses a lot of useful features you probably can’t do without.
  • FCKeditor: probably the most popular but in my opinion, FCK lacks usability (some options aren’t as user friendly as they could be, e.g. creating tables). Also a liberal license.
  • KTML: shined where TinyMCE and FCK disappointed, but sadly enough, Adobe decided to discontinue KTML. XHTML support was troublesome though.

The built-in ExtJs HTML editor is really promising, but it currently does not generate XHTML. However: it at least looks as clean and usable as an online editor should be: with just a few more features it will be unbeatable.

Unless I’m steadily becoming blind, there still isn’t a really awesome solution for online rich text editing. And I’m sure it is not a case of little demand…