Asynchronous template load within jQuery UI autocomplete widget

This week I was playing with jQuery UI Autocomplete widget. I usually use Mustache.js as a template engine for rendering HTML, and I load templates on-demand.

My problem was that the widget was not ready for asynchronous load.

I use this code to load the Mustache template and render it in the Autocomplete widget :


    var MustacheRender = function(TemplateName, datas, callback) {
      $.ajax({
        type: "GET",
        url: "/MustacheLoader/",
        dataType: 'html',
        data: {
          template: TemplateName
        },
        success: function(template){
          return callback(Mustache.render(template, datas));
        }
      });
    };

    $('input').autocomplete()
      .data( "autocomplete" )._renderItem = function( ul, item ) {

        var LoadAndRender = function(datas){
          $(datas).data( "item.autocomplete", item ).appendTo( ul );
        };

        MustacheRender('List-Item', item, LoadAndRender);
        return;
      };

In this case, everything is visually ok, but it does not work as expected. If you try it, you will find out that mouse* or key-based events are not triggered.
This is because the item list has not been “refreshed”.

As a workaround, you can manually refresh the list by adding this to the “LoadAndRender” callback:

$('input').data( "autocomplete" ).menu.refresh();

It now perfectly works !

Multilingual documentation with sphinx

These last days, we were looking for a documentation system for the upcoming Phraseanet release. We were used to build the documentation on an old and fixed Microsoft-like documentation system (sometimes called Windows-Help).

We needed a tool that can handle multilingual documentation, easy to use, flexible and easy to transform (HTML, PDF, ….).

We tried many wikis. It was not flexible enough. Export methods were particularly very weak. Until we had a look at ReStructured Text. We now love it !

It is as easy as a wiki to start. The multilingual difficult was solved with multiple documentation roots – one per language. The build is managed by one Makefile wrote with the help of CakePHP ( thank you http://mark-story.com/posts/view/creating-multi-language-documentation-with-sphinx )

Here’s the result : https://github.com/alchemy-fr/Phraseanet-Docs, you can see the html build at http://docs.phraseanet.com

More resources to start your project : http://sphinx.pocoo.org/tutorial.html

Symony2 Response Object

I’ve been playing a lot with the Silex Microframework these last weeks.
I had to build an API for an existing code.
The result is amazing, Silex let us build our API, write full coverage unitTests in no more than a week.
I will write a dedicated post about Silex later, the subject is now the Response Object of the Symfony2 HttpFoundation Component :

I found a disturbing behaviour in this object :

  • If you do not set a charset to this object => HTTP Content-Type header is marqued  ‘UTF8′ for “text/*” content-type (defaut content-type is text/html).
  • or If you set a charset by defining it yourself in the header => HTTP Content-Type header is marqued as your charset (good)

But, in both case, the Response::getCharset method will return null.

This is disturbing for the Unit Tests.
Actually, the WebTestCase component provided by Silex get the Response object, when testing a route. So when I check the charset, the test fails.

<?php
require_once dirname(__FILE__) . "/Silex/autoload.php";

use SymfonyComponentHttpFoundationResponse;

$app = new SilexApplication();

/**
* Good HTTP response / Good Behavior of Response::getCharset
*/
$app->get('/testpass/', function() use ($app)
  {
    $response = new Response('Hello world');
    $response->headers->set('Content-Type', 'text/plain');
    $response->setCharset('UTF-8');
    return $response;
  }
);

/**
* Good HTTP response / Bad Behavior of Response::getCharset
*/
$app->get('/testfail/', function() use ($app)
  {
    return new Response(
                      'Hello world'
                      , 200
                      , array('Content-Type' => 'text/plain; charset=UTF-8')
                );
  }
);

I’ll try to enhance this behaviour in the next few days.