Getting over again this problem I found out what was wrong: all my ajax requests did’t expressly declarate the dataType attribute when called; this, for some reason, have no default fallback (dataType:”html”) if the request is made from a local file using the v. 1.5 of jQuery but it is resolved correctly once called from a web server.

So, after adding the correct dataType, all the ajax calls now works correctly even if called directly from a local file:

before:

$.ajax({
type: "GET",
url: url,
data:pageData,
success: function(response) {...}
})

after:

$.ajax({
type: "GET",
url: url,
data:pageData,
dataType:"html",
success: function(response) {...}
})

There’s no documentation about this issue on the jquery site and maybe someone will find this information usefull.
For an accurate documentation on the new ajax module read: http://api.jquery.com/category/version/1.5/.

Go to the component page for the latest update:

http://pupunzi.open-lab.com/mb-jquery-components/mb-_menu/

Now is

This is a powerful jQuery component to build easily a multilevel tree menu or a contextual menu (right click) in an intuitive way!

You can add as many submenus as you want; if your submenu or menu is not declared in the page, the component’ll get it via ajax calling the template page with the id of the menu you need (the value of  “menu” attribute) the ajax page should return a well formatted code as the example below for the menu voices code.

go to the component page for the latest release

Dependencies:

optional: jquery.metadata.plugin

optional: jquery.hoverIntent.plugin

here is the js call:


$(".myMenu").buildMenu(
{
template:"menuVoices.jsp",
additionalData:"",
menuWidth:200,
openOnRight:false,
menuSelector: ".menuContainer",
iconPath:"ico/",
hasImages:true,
fadeInTime:200,
fadeOutTime:100,
adjustLeft:2,
adjustTop:10,
opacity:.95,
shadow:true,
closeOnMouseOut:true,
closeAfter:500,
minZindex:200,
hoverIntent:0
});

or you can call it as contextual menu:

(can’t work in opera due to a security restriction)

$(document).buildContextualMenu(
{
template:"menuVoices.html",
menuWidth:200,
overflow:2,
menuSelector: ".menuContainer",
iconPath:"ico/",
hasImages:false,
fadeInTime:200,
fadeOutTime:100,
adjustLeft:0,
adjustTop:0,
opacity:.99,
shadow:true,
onContextualMenu:function(o,e){}
});


params:

template:

is the ajax page that build this level menu structure ;
If the menu you are calling is not on the page, the component automatically will try to build it calling via Ajax the “template” page, passing the ID of the menu you call in the request (“menuId”).
The temlate page should be a dinamic page (php, jsp, aspx, …) that’ll build the menu from the ID param passed in the request.

If you are a beginner on javascript and coding in general just write your menu code directly on your page; it’s easyer!

additionalData:

are additional data needed to build the menu, by default it send the actual menuline id;
If you need some other params to be passed to the template page to build your menu you can set them here, writing them like: “pippo=1&pluto=false”;

openOnRight:

let the menus open on the right side instead bottom;

openOnClick:

define if the menu is opened by a mouse click or by a mouseover event;

hasImages:

define if the menu voices have images or not on its left;

menuSelector:

is the css class applied to each menu container of this menu context;

closeOnMouseOut:

the menu can be close either onclik on the window or just when your mouse exit the menu

closeAfter:

the time to whait befor close the menu (works just if closeOnMouseOut is set to true)

fadeInTime / fadeOutTime:

those params control the speed of the opening and closing fade effect.

hoverIntent: (New!)

this param sets the delay for the hover event; if set to 0 the hoverIntent function is not used.
To use this feature you have to include the jquery.hoverIntent plug in in your page!

submenuHoverIntent: (New!)

this param sets the delay for the hover event on submenu calls; if set to 0 the hoverIntent function is not used.
To use this feature you have to include the jquery.hoverIntent plug in in your page!

onContextualMenu:

A function invoked once each contextualMenu is called;
the function has either the dom element you clicked on, either the event:
onContextualMenu:function(o,e){
testForContextMenu(o);
},

here is the code for each menu header:

and for each submenu:

How to use it:

header

The menu header shouldn’t necessarely be a table (also an unordered list or what else you want).
to append a menu to each voice of the header you simply add an attribute “menu” to the tag with the ID of the menu you want as value; if the menu already exist in the page it get it otherwise it’ll be called via ajax at the url specified in the “template” attribute.

each menu

Each menu is a div with an ID that represent the content you want to call and a class “menu”; this div contains all the voices of the menu as “a” tag.
Give a look at the code to understand all the possible definition of each voice line!

Uno dei core business di Open Lab è focalizzato sulla realizzazione di applicazioni web based (teamwork ne è un esempio).

La parte di sviluppo delle interfacce GUI (Graphic User Interface) ha un ruolo fondamentale nel successo di qualsiasi applicazione, tantopiù se questa è fruibile attraverso un browser.
Occupandomi di graphic design, questo aspetto mi affascina e mi interessa in maniera particolare (Open Lab ha un sito dedicato: More than Icons).

Oggi è inpensabile scindere gli aspetti di interazione tra “chi utilizza” e “ciò che è utilizzato” (è anche questo un interessante tema di comunicazione); un designer non solo deve avere una cultura teorica sull’argomento (e già questo aspetto implica un attenzione ed una sensibilità rivolta al contemporaneo); ma deve conoscere gli strumenti che le tecnologie e le nuove tecnologie mettono a disposizione per la realizzazione di strumenti e metodi di fruizione delle interfacce.

One of the core businesses of Open Lab is building web based applications (teamwork is an example).
Development of web based GUI (Graphic User Interface) today plays a key role in the success of any application, especially if it is available through a browser.  Graphic design fascinates me, particularly when combined with usability (see our web site: More than Icons).
Today it is unthinkable to separate aspects of interaction between “those who use” and “what is used”  (this is also an interesting theme of communication), a designer must not only have technological background  (and this already implies a sensitivity and attention devoted to the contemporary), but must also know the tools that new technologies provide for the creation of usable interfaces.

Per le applicazioni realizzate in ambiente web (quello che ora viene chiamato Web 2.0), che sempre più stanno assumendo un ruolo centrale nello sviluppo informatico, stiamo assistendo a sanguinose battaglie per l’affermazione degli standard comportamentali dei browser di fruizione; anche l’indiscusso protagonista IE (che fino ad oggi ha imposto in maniera arrogante i suoi standard proprietari, costringendo chi come me si occupa di programmazione di interfacce web a frustrazioni e sforzi disumani per far sì che le interfacce siano coerenti su tutti  i browsers) si stà allineando agli standard del W3C e ECMA, rendendo tutti un po’ più felici.

Gli strumenti per realizzare interfacce in ambiente web, a prescindere dall’ambiente in cui l’applicazione è stata sviluppata server side, sono tendenzialmente 2: L’HTML o XHTML (HyperText Markup Language) per la gestione della strutura dei contenuti ed il CSS (Cascading Style Sheet) per la loro visualizzazone. A questi si aggiunge l’ECMAscript (javascript) per la manipolazione del DOM (struttura della pagina) e dei suoi contenuti.

Ci sono inoltre elementi realizzati con codice compilato che possono essere inglobati nelle pagine e per i quali sono richiesti plug in client side per la loro fruizione; tra questi, il linguaggio più utilizzato è senza dubbio l’actionScript in ambiente Flash o Flex di Adobe ®.
Inoltre, per la fruizione contestuale di oggetti multimediali quali filmati, audio, documenti pdf, oggetti 3D e quant’altro, ogni softwarehouse (Adobe®, Apple®, Microsoft®, etc.) ha implementato plug in proprietari per integrare la loro tecnologia all’interno del’ambiente web. Il maggior difetto di questi componenti è quello appunto di essere codice compilato e non interpretato per cui l’iterazione tra oggetti diversi su una stessa pagina non è esplicita e gli eveti non sono condivisi.

Il Web 2.0 differisce dalla precedente gestione delle pagine web fondamentalmente per due aspetti:

1. La manipolazione degli oggetti del DOM a seguito di eventi scatenati dall’utente (mouse click, mouse hover, mouse out,  change, time events,  etc.).
2. La possibilità di modificare il contesto dei contenuti a seguito di richieste specifiche server side, senza dover ricaricare interamente il contenuto della pagina, tramite la tecnologia Ajax (Asynchronous JavaScript and XML).

La tendenza generale è quindi quella di utilizzare quanto più possibile i linguaggi interpretati (javascript, HTML e CSS) per la realizzazione delle interfacce così da poter condividere gli eventi e modificarne i contenuti attraverso codice espresso direttamente sulla pagina o su files a questa collegati.

Tutto questo si scontra comunque con le diverse specificità dei browser utilizzati per fruire dei contenuti web (in realtà le specificità sono 2: IE da un lato, tutti gli altri dall’altro!!).
Come già detto, a differenza di browser come Firefox (basato su motore Mozilla), Safari e l’ultimissimo nato Chrome (basati su motore webkit), Opera ed altri che hanno sposato l’idea di seguire standard comuni per l’interpretazione del codice e degli eventi scaturiti; rimane IE (Internet Explorer) di Microsoft®, che da solo ricopre poco meno del 50% dell’utenza e quindi non può essere tenuto di poco conto (anche se se lo meriterebbe!) che cerca di dettare standard proprietari (sia per l’interpretazione degli eventi, sia per gli aspetti grafici) in netto conflitto con gli altri (http://maxb.net/blog/2008/06/17/blacknwhite/), facendo sì che il codice necessario alla realizzazione dell’interfaccia, sia visiva che comportamentale, debba essere sottoposto a costanti verifiche di funzionamento e sporcato per far sì che l’applicazione sia coerente su tutte le piattaforme di fruizione.

Per far fronte a questo inconveniente, almeno per l’aspetto comportamentale, sono nate delle API (Application Programming Interface) basate su javascript che permettono allo sviluppatore di scavalcare i problemi di compatibilità tra interpreti delegando ai propri metodi la verifica e la gestione delle differenze di codice necessario; hanno inoltre linearizzato i metodi di analisi del DOM e implementato metodi di gestione di eventi e metodi di gestione Ajax.

Questo ha facilitato talmente la programmazione da far sviluppare in poco tempo interfacce che fino a soli 2 o 3 anni fà sarebbero state irrealizzabili.

Le librerie più utilizzate oggi sono Prototype, Mootools, Dojo, jQuery; ognuna di queste ha dei buoni motivi per essere usata, comunque io ho sposato jQuery che ha, a mio parere, un approccio meno invasivo nella manipolazione del dom e degli eventi, una forte comunity che alimenta costantemente lo spettro di applicazioni, esempi e tutorials, ed è veramente write less get more.

Alcuni link utili di comparazione fra jQuery e le altre API:

• Prototype and jQuery: A code comparison
• Why jQuery’s Philosophy is Better
• jQuery: (Mis)leading the Pack
• Javascript Toolkit Comparison
• Zebra Table Showdown
• Event Selector Showdown

Per concludere, la ricerca nell’ambito dell’usablità applicativa è in continua evoluzione ed offre grandi spazi creativi; pubblicherò in seguito alcuni componenti che ho realizzato per le nostre applicazioni.

Intanto, se volete, potete andare a vedere mb.ideas.repository, un sito che ho realizzato per la pubblicazione dei miei compnenti javascript.

Per  informazioni sulla storia della Graphical User Interface dei sisemi operativi :

• http://en.wikipedia.org/wiki/History_of_the_graphical_user_interface