Sviluppare in asp.net webform e jquery è sicuramente un’attività che consente di realizzare un prodotto con un codice molto pulito e ben strutturato, delegando correttamente le diverse azioni ad ogni modulo.

Tuttavia, al contrario di quanto non avvenga in asp.net mvc, bisogna fare molta attenzione a ciò che succede dietro le scene.

Oggi per esempio mi sono imbattuto in un comportamento che non avevo notato prima.

La situazione è quella in cui, al click di un pulsante, si apra una finestra popup, realizzata tramite jQuery UI dialog. La finestra conterrà una serie di campi e due pulsanti (annulla, salva): l’obiettivo è consentire l’inserimento su DB di una generica entità (ie: un utente).

In aggiunta, ho inserito una serie di regole di validazione ricorrendo a jQuery validation.
Tuttavia, sul change del campo di testo, la console javascript restituisce questo errore:

this[0] is undefined

Questo avviene perchè il dialog viene creato al di fuori del form presente nella master page (come riportato nella figura sottostante).

Per ovviare a questo problema, si deve intervenire sull’evento open del dialog, in modo che il codice del dialog venga inserito all’interno del form.

Di seguito uno snippet del codice necessario:

1
2
3
4
5
6
7
8
9
10
11

$("#popup").dialog({
  title: 'titolo',
  autoOpen: false,
  close: function () { $(this).remove(); },
  open: function () {
    $(this).parent().appendTo($('#aspnetForm'));
  },
  modal: true,
  width: 600,
  height: 300,
  ...

Recentemente ho riscontrato un bug nell’utilizzo del componente datepicker in accoppiata con il plugin masked input di query.
Quando si seleziona una data dal calendarietto associato e si cerca poi di modificarla manualmente, il sistema cancella completamente la data, costringendo l’utente ad inserirla nuovamente.

Ho aperto un ticket nella sezione dev di jquery.

Ottima digressione di Alberto sull’evoluzione del web, dagli albori fino ai giorni nostri.

Mi trovo completamente daccordo con lui. Aggiungo al suo ragionamento due punti:

a) tutto questo fiorire di framework, che con due click ti consentono di creare pagine web anche piuttosto complesse, sta pian piano sminuendo la figura dello sviluppatore;

b) l’unico punto che avrei forse approfondito nella digressione, è quello relativo a Java. Credo che attualmente, il punto di forza di Java su Web non sia tanto il linguaggio o il motore che ci sta dietro, quanto il fatto di poter contare su tutta una schiera di framework rilasciati dal progetto apache (vedi Cocoon, vedi Struts) e non (vedi Hibernate).