Back to my little pet project. I already have playlists being generated according to folder structure, but a random playlist link had been on my mind as some days I just don't want to pick an album to listen to. To do that a list of the entire directory structure has to be made to pick from randomly. From my days of running web servers and web servers that had octopus like directories full of mp3s I knew I needed a recursive algorithm to sweep through all of those folders. The concept of a recursive algorithm is the same in all programming languages, the function calls itself again once the same set of steps are needed for a level down. It should also not run forever, which is an easy feat when doing this type of logic. I did some research and found some examples, but these errored out as they needed far to large amounts of memory to be allocation temporaryily. With some tweaking I came up with:

function directoryToArray($directory,$recursive=true,$include_directories_in_list=true){
 $array_items=array();
  if($handle=opendir($directory)){
   while (false!==($file=readdir($handle))){
    if($file!="."&&$file!=".."){
     if(is_dir($directory."/".$file)){
      if($recursive &&){
       $narr=directoryToArray($directory."/".$file,$recursive);
       foreach($narr as $nr){
        array_push($array_items,$nr);
       }
      }
      if($include_directories_in_list){
       array_push($array_items,preg_replace("/'/","\\'",($directory."/".$file)));
      }
     }else{
      if(preg_match("/mp3$/i",$file)){
       array_push($array_items,preg_replace("/'/","\\'",($directory."/".$file)));
      }
     }
    }
   }
   closedir($handle);
  }
 return $array_items;
}

Sort, simple and it got the done in a reasonable amount of time. I added the javascript to tie it together and a random playlist was doable. Now I have to deal with the whole UTF-8 charater set. That's for next time.

iPhone-ready SDK

The disk image now contains a Custom SDK. This makes the framework a lot easier to use on the iPhone. See the INSTALL file in the dmg for details.

New sortKeys option

This makes the generator produce objects with the keys in sorted order. This is very handy when you need to compare JSON documents.

Leopard only

From version 2.1 onwards this framework is Leopard-only. Stick with version 2.0 if you need Tiger support. Some of the Objective-C 2.0 features are just too shiny to pass up for long. Some of the changes related to this:

• 64 bit support
  
  The JSON framework now supports 64 bit. Moved to use the 10.5 64-bit compatibility typedefs for basic types.

• Garbage collection support
  
  The framework is now built with garbage collection support by default.

• Syntesized properties
  
  Killed some redundant code by moving to use synthesised properties.

• Fast iteration loops
  
  Update the code to use Objective-C 2.0 fast iteration loops in a couple of places.

Removed deprecated methods

Removed the option-taking category methods, as promised in v2.0. Rewrote some tests to use the underlying object instead.

New error code

Introduced a new error code for clarity: EEOF - premature end of input.

Documentation target

Added a documentation target to integrate the documentation into Xcode automatically.

The problem is however that almost all the tools out there in Fedora-Commons land are biased towards XML, and have (almost) never heard of JSON. So if I only have some basic Dublic Core and a gob of JSON in my objects, that is not going to help very much. The other extreme, and undoubtedly "The Right Way To Do It" is to have a lovely shiny Content Model and define everything in an ontology and RDF and then my brain melts. And we want to migrate our repository sooner rather than later and don't have the time to remain in la-la land designing around our navels forever.

So now I am swinging back the other way and have decided to store the data in the objects as simple stupid XML with a smattering of tags, and at least have some XSLT disseminators to provide more buzzword compliant FOAF, Bibliontology, OAI-ORE etc. And JSON. Via XSLT. Which brings me to http://code.google.com/p/xml2json-xslt/ which pointed at http://badgerfish.ning.com/ and finally to pesterfish:

Jacob Smullyan wrote a related Python model, pesterfish, which he describes as: "a quick Python module which is uses the same xml object model as the dominant xml module in the Python world, elementtree; Some elementtree implementation (there are several) and simplejson are required. BTW, elementtree stores namespaces in Clark notation: {http://www.w3.org/1999/xhtml}br and so does this.". pesterfish also lets you round trip XML through it without any data loss.

I like the ElementTree API. Lots. It is very elegant and a joy to work with, especially if you have ever had to use any other XML APIs like DOM or SAX that makes you want to gnaw your own arm to the bone out of frustration. So the chance of having an ElementTree-like way of consuming XML in Javascript expecially appeals to me. (well until http://en.wikipedia.org/wiki/E4X E4X is widely supported)

And so, with this long-winded preamble I would like to present pesterfish on AppEngine:

http://epoz.appspot.com/pesterfish/

You can POST an XML file to it, and it will return the pesterfish application/json.

Or you can call it with a URL for the XML file specified in the 'in=' parameter, like this.

http://epoz.appspot.com/pesterfish/?in=http://www.w3schools.com/XML/note.xml

It turns this XML:

<note>

	<to>Tove</to>

	<from>Jani</from>

	<heading>Reminder</heading>

	<body>Don't forget me this weekend!</body>

</note>

Into this JSON:

{"text": "\n\t", "tag": "note", "children":
 [{"text": "Tove", "tail": "\n\t", "tag": "to"},
 {"text": "Jani", "tail": "\n\t", "tag": "from"},
 {"text": "Reminder", "tail": "\n\t", "tag": "heading"},
 {"text": "Don't forget me this weekend!
", "tail": "\n", "tag": "body"}]}

And it supports JSONP:

http://epoz.appspot.com/pesterfish/?in=http://www.w3schools.com/XML/note.xml&callback=some_callback

Thanks Jacob!

The only problem is how to deal with statically typed languages like C# and Java. These languages need the types of the objects that application will consume from a Web service defined up front. So if we could just figure out how to come up with service documents for JSON services that included the notion of a class definition, we could pretty much have our cake and eat it to with regards to getting the ease of use of an RPC system while building a RESTful service.

This isn't that hard:

- get Damien Katz latest CouchDB from svn.

- get JSon.Net

- learn LINQ

With JSon.net you can easily convert objects from c# to JSon, and vice versa, then POST those directly to CouchDB with their REST API. In practice, its mildly more difficult than that. Consider you have a c# object called Product. This can be easily converted to JSon using JSon.net and POSTed to couchdb. Voila, object database using REST api.

To de-serialize this to CouchDB you need to be able to accept some standard fields for ID and Revision that CouchDB is going to add to any document you POST. In JSon:

{"_id":"00018aefcce4a579c8dc263ebae00638","_rev":"550271284", ...

To handle this you need to extend your c# Product type. This can be done easily with generics:

   // documents have at a minimum the _id and _rev properties
    public abstract class Document : IDocument
    {
        public string _id { get; set; }
        public string _rev { get; set; }
        public virtual string ToJSon()
        {
            return JavaScriptConvert.SerializeObject(this);
        }

    }

   public class Entity<T> : Document
    {
        public T entityobject;

        public static Entity FromJSon(string json)
        {
            JsonSerializer serializer = new JsonSerializer();
            serializer.MissingMemberHandling = MissingMemberHandling.Ignore;

            StringReader sr = new StringReader(json);
            Entity<T> docObject = (Entity<T>)serializer.Deserialize(sr, typeof(Entity<T>));
            return docObject;
        }
    }

So now we have something that can read and write an object from couchdb using REST and return a strongly typed object. Some helper methods are embedded to get/set JSon. In the serialized result, the c# object itself is always contained in the JSon field called "entityobject", which sits beside the ID and Revision root level elements.

{
   "_id":"00018aefcce4a579c8dc263ebae00638",
   "_rev":"550271284",
   "entityobject":{
      "SKU":"my SKU",
      "ISBN":"",
      "Cost":2.1e+01,
      "Price":8.99899999999999948841e+01,
...

This all sounds great but what I find even more enticing is to leave the results in a generic JSon object (similar in spirit to XmlNode), and run LINQ queries to extract the fields I needed from that. JSon.Net provides JObject for this purpose, which can be bound to an asp.net MVC view:

var query = from row in ViewData.Model["rows"].Children()
               orderby row.Value<int>("value") descending
       select new
           {
               Manufacturer = row.Value<string>("key"),
               Count = row.Value<int>("value")
           };

Its not as pretty as Rails, or as elegant as Python, but it seems to make sense. And making sense is what its all about.

"What do YOU Pursue?"  That's the question Dillon asks on his latest CD that dropped today called "The Pursuit."  The first song I ever heard from Dillon was on the 13 Letters CD from the 116 Clique, called "Take 'em Back."  The song was about the book of Philemon.  That's the thing about guys like Dillon Chase - the music is hot and the lyrics are all straight up exegetical!

Check out tha songs and download tha CD now at the following link or by clicking on the album cover above.  http://www.thebus-shop.com/shop.cfm?prod=462

/*sample code by stikiflem

Copy and Paste all of these. Save as sample.html. Run in browser.
*/
function getData(){

var sampleJSON = {
// string
a : 'accessing a string in json',
// array
b : ['obj1','im a string in an array!','three',4,'obj5'],
// function
c : function() {
alert('im a function!');
}
}

alert(sampleJSON.a);
alert(sampleJSON.b[1]);
alert(sampleJSON.c());

}
/*
JSON is just pure javascript. no BS.
Just remember:
1. Entry inside {} are properties.
2. Entry with [] is an array which can contain another array or a property.
3. JSON can also carry a function (e.g. in alert #3)
*/
</script>
<input type="button" value="Get JSON Sample" onClick="getData();" />

apache, opensource, documents, metadata, database, json, javascript, REST, addressability, horizontal scaling, erlang.

So I found myself at Railscamp UK on the weekend without a ruby+rails topic to really talk about during the presentations part of the camp. I'm still a noob wrt. Rails, you see. Realising that CouchDB is relevant to most web developers because most developers deal with document-based content at some point and that Ruby, Rails, and Erlang are kindda like the current bratpack (in a John Hughes-sense) of computer languages, I thought it would be a great little topic for a 15-minute presentation.

So I thought I share the slides and some of the code I hacked up on the weekend. First of all the slides...

(click me)

You can play about with some sample code that was expanded upon after the presentation. Here's a little helper class to interface into CouchDB using JSON and HTTP:

[sourcecode language='ruby']
require 'rubygems'
require 'httparty'
require 'json/pure'
require 'find'

class CouchHack
include HTTParty
base_uri 'http://127.0.0.1:5984'
format :json

def update( path, document )
options = { :body => JSON.generate(document) }
puts self.class.put(path, options )
end

def get(path)
self.class.get(path)
end

def create(db_path, document )
options = { :body => JSON.generate(document) }
self.class.post(db_path, options )
end

def define_view(db_path, design_doc_name, views )
document = { "views" => views }
options = { :body => JSON.generate(document) }
self.class.put("#{db_path}/_design/#{design_doc_name}", options)
end
end
[/sourcecode]

Once that's in place you can use the CouchHack class by defining a view like so:

[sourcecode language='ruby']
ch = CouchHack.new
gem_views = {
  "small_gems" =>
    {
      "map" => "function(doc) { if (doc.length < 3000) emit(doc.path, doc) }",
    },
  "large_gems" =>
    {
      "map" => "function(doc) { if (doc.length > 3000) emit(doc.path, doc) }",
    }
}
ch.define_view("/railscamp", "gems", gem_views)
[/sourcecode]

This design document, as is its known in CouchDB parleance, defines two views (think 'baked queries'), to return a list of small gems - those less than 3000 bytes - and a list of large gems - those larger than 3000 bytes.

So where do these gems come from and how do they end up in CouchDB ? That's what the next and last little fragment of Ruby code does.

[sourcecode language='ruby']
Find.find('/Library/Ruby/Gems/1.8/gems/' ) do |f|
  if File.file?(f) and f.ends_with?('.rb' )
    begin
      gem_contents = IO.read(f)
      gem_document = { "path" => f, "length" => gem_contents.length, "content" => gem_contents }
      ch.create( "/railscamp", gem_document )
    rescue Exception => bang
      puts "Skipping #{f}"
    end
  end
end
[/sourcecode]

So what happens is that the last little fragment traverses the filesystem starting at /Library/Ruby/Gems/1.8/gems/ and looks for *.rb files. When it finds one it POSTs that whole document including the file length to CouchDB, where it becomes part of the resultset of one of the pre-defined views. These views can be accessed through the following two URLs (assuming the 'railscamp' DB was used).

• http://localhost:5984/railscamp/_view/gems/large_gems
• http://localhost:5984/railscamp/_view/gems/small_gems

Feel free to post comments and ask questions.

Enjoy.

P.S. and if you get a chance to go to a *camp conference, GO! They're an amazing format and you'll learn soooo much!.

Quando terminava o upload, a aplicação retorna um código JSON, só que o jQuery infelizmente não tem nenhuma utilidade de conveter uma String representada para JSON. Só que ai veio uma idéia: vou utilizar um antigo e quase esquecido amigo do Javascript, o eval(). Então simplsmente fiz assim:

Código retornado pelo PHP (string representada):
{"filename":"file.ext","size":"2516582","location":"\/path\/to\/file\/file.ext"}

Solução em Javascript:
var response = eval( '(' + jsonString + ')' );

Só tomem cuidado com o tamanho da string em JSON que irão retornar, o eval() é bom, mas tem que saber utilizar ele. Esta função é uma das mais básicas, porém essenciais numa linguagem de programação. ;D

Apreciem com moderação. ;)

It has a auto complete feature as well. It works by caching all the results from a JSON Request and feeding them to the autocompleter object. When a item is added as a box, it’ removed from the feed array, and when the box is disposed it’s added back, so that it becomes available in the list when the user types. You’ll also be able to let it add boxes from the HTML directly. If you are interested in this amazing textboxlist, you can mail me

on-my-mind

To help you find programmes, no matter which station or channel they are broadcast on, we've started publishing schedules for all our genres (sport, music etc.). These views are being used as part of the BBC's Olympics coverage - specifically to drive the TV schedule and individual sport pages. But as you might be able to guess a little bit of URL hacking gives you more. All you need to do is add /schedules to the end of any genre aggregation, so for example:

A schedule for your favourite music genre :
www.bbc.co.uk/programmes/genres/music/classicpopandrock/schedules

What's happening on the Olympics:
www.bbc.co.uk/programmes/genres/sport/olympics/schedules

Drama on radio:
www.bbc.co.uk/radio/programmes/genres/drama/schedules

Or science and the environment on Radio 4:
www.bbc.co.uk/radio4/programmes/genres/factual/sciencenatureandenvironment/schedules

And obviously you can get this data both as HTML and as XML, JSON, YAML just by adding .xml .json or .xml to the end of the URL. So the TV coverage for sailing as XML is:

www.bbc.co.uk/programmes/genres/sport/sailing/schedules.xml

Hope that helps you find your favorite programme.

UPDATE

As Duncan has previously discussed on the BBC's Radio Lab blog you can also get this data in your Calendar via iCal - just add .../upcoming.ics to the above URL. For example:

www.bbc.co.uk/programmes/genres/sport/sailing/schedules/upcoming.ics

www.bbc.co.uk/radio4/programmes/genres/factual/sciencenatureandenvironment/schedules/upcoming.ics

[sourcecode language='jscript']
$("#idBoton").click(function () {
$.getJSON("./devuelveJSON.do,
function(data){
$("select[name='idSelect']").removeOption(/./);
$.each(data.listaObjetos, function(i,objeto){
$("select[name='idSelect']").addOption(objeto.id, "[" + objeto.nombre + "] " );
});
});
});
[/sourcecode]

Para la manipulación de Selects (del modo que se hace aquí) hay que importar un plugin de JQuery que se encuentra en la siguiente URL http://www.texotela.co.uk/code/jquery/select/.

A continuación se muestra como devolver una cadena JSON desde un action de Struts. En el ejemplo el JSON se genera a partir de un ArrayList de objetos "Objeto" (valga la redundancia). Cada objeto tiene como atributos un "id" y un "nombre". Para la conversión de listas a cadenas JSON se usa Json-lib, una librería java muy útil para la transformacion de beans, mapas, colecciones, arrays y XML a JSON y viceversa.

[sourcecode language='java']
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {

response.setContentType("text/json");

ArrayList lista = new ArrayList();
Objeto objeto =new Objeto();
objeto.setId("1");
objeto.setNombre("Objeto 1");

lista.add(objeto);

objeto.setId("2");
objeto.setNombre("Objeto 2");

lista.add(objeto);

JSONArray jsonArray = JSONArray.fromObject(lista);

PrintWriter pw = response.getWriter();
pw.write("({\"objetos\":" + jsonArray.toString() + "})");
pw.flush();
pw.close();
return null;

}
[/sourcecode]

The first step is... integration (please note my avoidant personality which tend to ignore stuff like "how the f' should I code *anything* in Ext and jumps right into "ok, how should I display a grid ?"). This integration comes in two flavors - XML and JSON. From what I figure, an XML representation is larger (in terms of bytes) than a JSON representation so I tried to go the JSON way.

On the Spring side some there is a small lib called Spring JSON View which is basically a Spring view implementation. Long story short - it serializes JavaBeans to a JSON representation which is sent to the facade. Yes, of course it has more features, like form validation and stuff, but all in due time...

On the ExtJS side we have a JsonStore which is basically a DataStore encapsulating a proxy and a JsonReader. Here's where my stupidity kicked-in: the JSON generated by Spring looks something like
{"model":
{"products":
[{"productName":"Pretzels","skuNo":"1","productPrice":2.0},
{"productName":"Arrows","skuNo":"3","productPrice":4.0},
{"productName":"Nuclear warheads","skuNo":"2","productPrice":2.3}]
}
}
As an absolute n00b I wondered "Ok, which is the root of the store ? Is it "products" ? Is it "model" ? Is it "model.products" ? The latter was my logical choice but it didn't work. I wandered around forums and various blogs, I even wrote an override for the JSON reader, figuring that the problem is the root.

After spending a few hours on this I decided to ask the forums... Turns out that this specific line in the JsonStore was a bit... wrong:
fields:[{name:'productName',type:'string'},{name:'skuNo',type:'string'},name:'productPrice',type:'double'}]
Double is not an accepted type. I replaced it with "float" and everything worked like a charm

Never underestimate the power of your own stupidity...

<% $Response.ContentType = "application/json; charset=utf-8" %>
<% $Response.Cache.SetCacheability([System.Web.HttpCacheability]'NoCache') %>
<% $Response.Cache.SetExpires([DateTime]::MinValue) %>
<% if( !($n = $Request.QueryString["n"] -as [int]) ) { $n = 10 } %>
{"processes":[
  <% [string]::Join(",`n  ",
  (get-process | sort ws -desc | select -first $n | foreach {
  "{'ID':$($_.ID),'Name':'$($_.Name)','WS':$($_.ws)}" })) %>
]}

After we set the JSON ContentType and cache policy, we try to fetch an "n" query parameter. If n is missing or not a number, we default to 10. Now we can start building our JSON object. To build our array, we use System.String's static Join method (the backtick is PowerShell's escape character, so `n is a newline). Join's string[] parameter is provided by a PowerShell pipeline that fetches our system processes, sorts by working set size, selects the top $n and then iterates through those process objects, returning a string of JSON with our desired properties. Note also that PoShASP seems to require an empty line at the end of the file, otherwise "]}" is ignored. Our output will look something like this:

{"processes":[
  {'ID':1672,'Name':'sqlservr','WS':506028032},
  {'ID':3296,'Name':'devenv','WS':230555648},
  {'ID':4720,'Name':'w3wp','WS':181100544},
  {'ID':376,'Name':'services','WS':121995264},
  {'ID':3372,'Name':'w3wp','WS':102522880}
]}

Let's save our JSON endpoint as %12%\TEMPLATE\LAYOUTS\Get-Process.json.ps1x, which we can test by visiting http://server/_layouts/Get-Process.json.ps1x?n=5. Now it's AJAX time! Since not everyone can use the ASP.NET AJAX Extensions, we'll just do it the old-fashioned way. Starting with a Content Editor Web Part on a page of your choice, set the source to the following:

<div id="d_procs">
<img src="/_layouts/images/GEARS_AN.GIF"
  alt="Loading..." align="center" />
</div>
<script>
function getXmlHttpRequestObject() {
 if (window.XMLHttpRequest) {
  return new XMLHttpRequest();
 } else if(window.ActiveXObject) {
  return new ActiveXObject("Microsoft.XMLHTTP");
 } else {
  document.getElementById('d_procs').innerHTML =
  'Cound not create XmlHttpRequest Object.';
 }
}

var r = getXmlHttpRequestObject();
var c = 0;
var mTimer;

function getProcs() {
 if (r.readyState == 4 || r.readyState == 0) {
  r.open("GET", '/_layouts/Get-Process.json.ps1x?n=5', true);
  r.onreadystatechange = handleReceiveProcs;
  r.send(null);
 }
}

function handleReceiveProcs() {
 if (r.readyState == 4) {
  var d = document.getElementById('d_procs');
  var response = eval("(" + r.responseText + ")");
  var p = response.processes;
  var t = "<table width=\"100%\">";
  t += "<tr><th>ID</th><th>Name</th><th>WS(MB)</th></tr>";
  for(i=0;i < p.length; i++) {
   t += '<tr><td>'+p[i]['ID']+'</td>';
   t += '<td>'+p[i]['Name']+'</td/>';
   t += '<td align=\"right\">';
   t += (p[i]['WS']/(1024*1024.0)).toFixed(2);
   t += '</td/></tr>';
  }
  t += "</table><p>Refresh count: "+(++c)+"</p>";
  d.innerHTML = t;
  mTimer = setTimeout('getProcs();', 3000); // 3-sec refresh
 }
}

_spBodyOnLoadFunctionNames.push('getProcs');
</script>

I haven't put much effort into cleaning up the code, but it does the job (in FF2 and IE7, at least):

With PowerShell's ease of development and specialized adapters, this is just the tip of the iceberg. What other real-time data would you find useful?

Определение возможностей осуществляется для двух целей:

• Различение мобильных и десктопных браузеров. Скорее всего вы захотите иметь различные представления сайтов для пользователей, работающих с обычных компьютеров и с мобильных устройств.
• Отладить работу поведения сайта в каждом конкретном случае в зависимости от возможностей устройства.

На персональных компьютерах различия довольно минимальны: необходимо поддерживать 3 или 4 популярных браузера, все компьютеры имеют клавиатуру и мышь, и мы можем с большой степенью вероятности утверждать, что пользователи работают с разрешением 1024x768 и выше. При сравнении характеристик мобильных устройств существуют колоссальные различия: бесконечное количество различных браузеров, разрешений экрана и устройств ввода.

Чтобы уверенно поддерживать работу сайта на всем этом многообразии, необходимо иметь универсальный инструмент для определения возможностей мобильных устройств. Эта статья описывает интеграцию Google App Engine и базы данных устройств DeviceAtlas от dotMobi. Почему именно DeviceAtlas?

• Он содержит точную и всеобъемлющую информацию. База данных DeviceAtlas включает в себя информацию из различных источников: WURFL, Volantis, ArgoGroup и прочих
• Он достаточно быстрый - несколько тысяч запросов на умеренном аппаратном обеспечении
• Он бесплатен для разработчиков

Наша статья описывает процесс создания простейшего приложения для определения типа мобильного устройства и соответствующего ему вывода информации. Приложение будет выводить месторасположение офиса компании dotMobi в Дублине с помощью Google Maps, учитывая возможности целевого устройства:

Начинаем

Первое, что необходимо сделать - создать как обычно каталог нового приложения Google App Engine и его конфигурационный файл app.yaml. Мы назовем наше приложение - "contact-dotmobi".

Далее, необходимо добавить к приложению код определения мобильных устройств. Эта статья описывает использование интерфейса API DeviceAtlas для языка Python. Достаточно положить в каталог с приложением модули библиотеки и JSON-файл с базой данных устройств:

• api.py - основной модуль DeviceAtlas
• daExceptions.py -определения исключений
• DeviceAtlas.json - данные устройств

Обратите внимание, что библиотека зависит от модуля SimpleJson, который производит обработку файла данных. Так как он не включен в стандартную поставку платформы, то его необходимо добавить вручную. Наиболее простой способ это сделать - скачать его с сайта http://www.undefined.org/python/ и поместить каталог с модулем SimpleJson в каталог нашего приложения. После этого он будет выглядеть так:

api.py
app.yaml
daExceptions.py
DeviceAtlas.json
index.yaml
simplejson

Теперь необходимо задать схему URL в конфигурации приложения и иконку нашего приложения favicon.ico. Содержимое файла app.yaml:

application: contact-dotmobi
version: 1
runtime: python
api_version: 1

handlers:
- url: /
  script: contact-dotmobi.py
- url: /favicon.ico
  static_files: favicon.ico
  upload: favicon.ico

Пишем первый код

Конфигурация завершена, теперь необходимо создать файл с кодом contact-dotmobi.py. Начнем со стандартных импортов:

import wsgiref.handlers
from google.appengine.ext import webapp
from google.appengine.ext.webapp import template

Далее мы импортируем модуль DeviceAtlas:

И читаем данные устройств из файла данных:

Этот код создает экземпляр интерфейса библиотеки и загружает базу данных с конфигурациями мобильных устройств. Он выполняется лишь один раз и создает доступные для всех остальных запросов объекты.

Теперь когда данные готовы для работы, мы можем перейти к созданию обработчика запроса:

class MainPage(webapp.RequestHandler):
    def get(self):
        self.response.headers['Content-Type'] = 'text/html'
        ua = self.request.user_agent

Здесь мы просто создаем потомок класса RequestHandler, устанавливаем HTTP заголовок ответа и определяем тип браузера пользователя по переменной, полученной из запроса. Самое интересное здесь как раз и является переменная ua, значение которой мы будем передавать интерфейсу DeviceAtlas:

        props = da.getPropertiesAsTyped(tree, ua)

Это обращение приведет к поиску в данных объекта tree нашей строки с определением браузера пользователя. Метод getPropertiesAsTyped возвращает словарь значений, которые сообщают наиболее подробную информацию об устройстве пользователя. Теперь мы можем принять решение о формате вывода данных, прежде всего, является ли удаленное устройство мобильным:

        mobileDevice = False
             if props.has_key('mobileDevice'):
                         if props['mobileDevice']:
                             mobileDevice = True

Далее мы определяем, какого размера изображение мы можем вывести на экран пользователя:

        mapWidth = 512 # по умолчанию максимум для Google maps 
        mapHeight = 512

        if mobileDevice:
            mapWidth = 128 # используем, если нет информации о размерах экрана
            mapHeight = 128
            if props.has_key('displayWidth'): # иначе определяем по ширине
                mapWidth = mapHeight = props['displayWidth'] - 25

Так как большинство мобильных устройств имеют портретную ориентацию, мы используем ширину экрана как наименьшую величину, устанавливая его высоту такой же. Уменьшая определенное значение на 25 пикселей, с учетом различных скроллеров, мы гарантируем что изображение не будет вылазить за пределы экрана.

Теперь мы знаем всю необходимую для отображения информацию и готовы сформировать словарь этих параметров и передать в шаблон:

        template_values = {
            'props': props,
            'mapWidth': mapWidth,
            'mapHeight': mapHeight,
            'zoom': zoom,
            'ua': ua,
            }

Шаблоны

В большинстве случаев предпочтительнее генерировать разметку в формате XHTML для мобильных устройств и обычный HTML для "настоящих" компьютеров. Обычно их стандартные браузеры меньше следуют стандартам и позволяют использовать больше вольностей в разметке страниц, что позволяет создавать богатый интерфейс. В нашем случае мы хотим использовать раздельные шаблоны для мобильных и стационарных устройств:

        if mobileDevice:
            self.response.out.write(template.render('index.xhtml', template_values))
        else:
            self.response.out.write(template.render('index.html', template_values))

Этот код передает параметры в шаблон, который создает ответ для устройства. Ниже приведен пример шаблона для мобильных устройств:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN" "http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Contact dotMobi</title>
</head>
<strong>Phone: </strong>
{% if props.uriSchemeTel %} <a href="tel:+35318541100">+353 (1) 854 110</a> {% else %} +353 (1) 854 1100 {% endif %}
<img src="http://maps.google.com/staticmap?center=53.348592,-6.247315&amp;zoom={{zoom}}&amp;maptype=mobile&amp;size={{mapWidth}}x{{mapHeight}}&amp;markers=53.348592,-6.247315,blued&amp;key=xxx" width="{{mapWidth}}" height="{{mapHeight}}" alt="map" />
Detected UA string: {{ua}}
DeviceAtlas version: {{apiRevision}}
Vendor: {{props.vendor}} Model: {{props.model}>

В этом шаблоне есть три интересные вещи:

• мы используем атрибут uriSchemeTel из свойств, полученных от интерфейса DeviceAtlas, чтобы определить поддерживает ли устройство ссылку на номер телефона. Если да - отображаем ее
• размер изображения с картой Google определяется по шаблонной переменной mapWidth
• внизу таблицы мы выводим некоторую отладочную информацию: строка UA, версия библиотеки DeviceAtlas, производитель и модель мобильного устройства.

Версия шаблона для стационарных компьютеров (index.html) в отличии от мобильной очень простая и мы не будем ее здесь рассматривать. Что у нас получилось:

Запуск приложения

Теперь все что осталось, добавить основной код приложения:

Теперь каталог с приложением выглядит так:

api.py
app.yaml
daExceptions.py
DeviceAtlas.json
favicon.ico
contact-dotmobi.py
index.html
index.xhtml
index.yaml
simplejson

Это все. Работу этого приложения "наживую" можно посмотреть на сайте http://contact-dotmobi.appspot.com/.

Другой пример

Разработчики, которые экспериментировали с DeviceAtlas предложили другой пример приложения, отображающего все доступные возможности текущего устройства:

Код этого приложения очень простой:

def get(self):
self.response.headers['Content-Type'] = 'text/html'
ua = self.request.user_agent
apiRevision = da.getApiRevision()

props = da.getPropertiesAsTyped(tree, self.request.user_agent)

if props.has_key('vendor') and props.has_key('model'):
imgSrc = 'http://deviceatlas.com/sites/deviceatlas.com/themes/eris/img/device_images/%s/%s.jpg' % (props['vendor'].lower(), props['model'].lower())
else:
imgSrc = False

template_values = {
'apiRevision': apiRevision,
'props': props,
'imgSrc': imgSrc,
'ua': ua,
't': True,
'f': False,
}

Соответствующий файл с шаблоном выглядит так:

{% if imgSrc %}
<img src="{{ imgSrc }}" alt="Device Image" />
{% else %}
<p>No image available</p>
{% endif %}

<strong>Available Properties</strong>

<table style="font-size:0.9em;">
{% for prop in props.items %}
<tr style="background-color: #{% cycle fff,f8f8f8 %};">
<td>
<strong>{{ prop.0 }}</strong>
</td>
<td>
{% ifequal prop.1 t %}
<span style="color: #0c0;"> {{ prop.1 }}</span>
{% else %}
{% ifequal prop.1 f %}
<span style="color: #c00;"> {{ prop.1 }}</span>
{% else %}
{{ prop.1 }}
{% endifequal %}
{% endifequal %}
</td>
</tr>
{% endfor %}
</table>

Аналогично, посмотреть работу приложения можно по адресу http://deviceatlas.appspot.com/. Исходный код обоих приложений доступен здесь и здесь соответственно. После загрузки необходимо переименовать расширения файлов в обычные .zip.

Скачать библиотеку можно после регистрации на сайте производителя

Cut to four months later, and I have launched my new search portal, Chofter.com.

To add it to the search bar in your browser, click here.

Immodest as it may sound, Chofter.com provides a better search experience than Google, Yahoo or Microsoft Live, because it incorporates search results from all of them, and much more.

The entire application is written using the Dojo toolkit, utilising

• Layouts, Dialogs, Menus and ContentPanes for the user interface.
• dojo.data and dojo.rpc for data transfer.
• dojox.dtl (Django Templating Library) for transforming search data into visuals.
• dojo.fx and FisheyeLite for eye candy
• .... and a chunk of custom code.

As of writing, the following search sources are available, arranged into a number of categories:

• Google - web, news, image, blog, video and book search.
• Yahoo - web, news and image search.
• Microsoft Live - web and news search.
• YouTube - video search.
• Flickr - image search.
• BBC News - news and sports search.
• Digg - web, news and video search.
• Amazon.com - book search.
• Wikipedia - web search.
• IMDB - video search.
• Technorati - blog search.
• DZone - technical search.

I will be adding more as time goes on.  A forum is being set up, and I welcome all feedback on the site.  I've also set up a blog for the site at http://www.chofter.com/blog.

Upon migrating from ColdBox 2.52 over to ColdBox 2.6 I was caught out by a subtle but show stopping issue. Unfortunately the error thrown is not very precise as to the details of the error is or what exactly has triggered it.

Looking into the pages being called prior to the error you can see the line ..

Called from \coldbox\system\plugins\XMLParser.cfc: line 1013

So one can assume it is probably an issue with one of the XML file, yet which file is not mentioned. However the XML file itself is not the problem, rather it is the data contained within. As JSON or JavaScript Object Notion like XML is another form of human readable data interchange. Unlike XML though JSON is light weight and less complex.

Now if you read the official What’s New Guide for ColdBox 2.6 you can find the following heading ‘JSON notation for dynamic complex settings’.

The configuration file allowed for simple notation to create structures: {name:'luis',active:'true'} and arrays: [1,2,3]. However, with the inclusion of the new json plugin, you can now declare full JSON syntax notations on ALL complex variables in the configuration file. So you can inflate queries, nested arrays, structures and so much more.

My slipup was that I was transferring an old ColdBox 2.52 coldbox.xml file for use in ColdBox 2.6. I had missed one of my Settings elements under YourSettings that used complex but invalid JSON style data structures. But it was easily fixed with a few single quotes here and there...

2.52 statement

<Setting name="TransferSettings"
value="{datasourceFile:config/datasource.xml.cfm,
transferFile:config/transfer.xml.cfm,
definitions:config/definitions}"/>

2.6 updated statement

<Setting name="TransferSettings"
value="{datasourceFile:'config/datasource.xml.cfm',
transferFile:'config/transfer.xml.cfm',
definitions:'config/definitions'}"/>

Our work so far has focused on providing core information for every artist the BBC plays on our daytime radio network shows. That's shows like Annie Mac and Chris Moyles on Radio 1, or Steve Lamacq on 6Music. We've focused on these shows because we've integrated the site with the radio playout system VCS dira! which are basically giant iPods in the basement of Broadcasting House. Unfortunately the specialist shows as well as national and local radio shows don't use these so we haven't got track listing data in the right format for these programmes. But we have a plan and will be adding more shows in due course.

So what have done so far?

For starters we decided that we wanted to have a single canonical page for every artist. We decided to do this because we want to aggregate everything we know about an artist at a single URL. But this means that we need unique, persistent, unambiguous URLs. Thankfully, as Michael has already discussed, Musicbrainz gives us unique identifiers that allow us to provide just such a set of URLs.

The core of the new site then is built around Musicbrainz. In addition to giving us web scale identifiers Musicbrainz is also being used to give core music metadata e.g. discographies, related artists and related links. Some of those related links are Wikipedia links and we are using those to go and fetch the introductory text for each artist's biography from Wikipedia.

The approach we're using to keep the Wikipedia data up to date is, I think, quite neat. Patrick has written a bot to monitor the Wikipedia IRC channel for updates - when it spots an update we fetch the new Wikipedia content. Oh and obviously all this data is rendered dynamically using the same MVC framework we are using for /programmes which means that updates happen almost instantaneously.

This brings me to the next major feature - integration with /programmes. As I've said we have integrated with VCS to give us track listing information for our daytime radio shows - we are matching this data with both our internal database of programme metadata and Musicbrainz. This lets us know which radio stations and shows have played which artists.

We also want to make this data available for others to use and so have designed the site to provide a RESTful API, following the principles of Linked Data:

...namely thinking of URIs as more than just locations for documents. Instead using them to identify anything, from a particular person to a particular programme. These resources in-turn have representations, which can be machine-processable (through the use of RDF, Microformats, RDFa, etc.), and these representations can hold links towards further web resources, allowing agents to jump from one data-set to another.

If you would like to have a play with these we have RDF, XML, JSON and YAML representations of the resources - just add .xml .rdf .json or .yaml to the end of the artist url.

Where next?

Nick, Michael and I have previous spoken about our plans for linking programmes, music, events, topics and users. Well this is our first foray into this world. Information about programmes and music is interesting, it's useful; but it's not as interesting nor as useful as when the two are intelligently linked. Joining the two worlds means that you can aggregate information about the programmes that have played an artist [as we've done], you can put track listings on episode pages, you can have charts of which artists are played most on all BBC Radio programmes, on Radio 1, by Zane Lowe. You can also aggregate all episodes that you can currently listen to that feature a given artist. Or show which programme first played a given artist and how often the BBC has played them since. Basically the interesting stuff happens at the joins between the nodes because that's where the context lives.

By exposing the information that is created by joining programmes and music we can provide context and serendipity. We can help you find out about the music you've just listened to and introduce you to new shows that also features the music you like. So that's what we're working on.

We also need to provide more data about each artist - from both inside and outside the BBC. That means bringing the album reviews into the fold, hooking up external news feeds and the like. But whatever we do it's worth bearing in mind that this is on a much larger scale than the current music site. This new site has in the order of 388,398 artist pages, 157,677 external links and 93,912 artist to artist relationships.

It would be great to hear what you think about what we've done and our plans for the future. You are welcome to leave a comment here, or via the Backstage mailing list.