Sprazzi di lucidità

Appunti per me, per google e per coloro che sapranno cosa farsene:

• Reset alla prima option

$(‘#select_id’).val($(‘option:first’, this).val());

• Reset ad opzione nulla

$(‘#select_id’).val(null);

 

Onestamente mi aspettavo qualcosina di più da Webkit…

A voi due miei cari lettori, ecco i dati tratti dal sito di Sunspider relativi al benchmark javascript che ho effettuato su tutti i browser che ho a disposizione, ordinati per performance ottenuta: minore il risultato, migliore la prestazione. (Less is better).

Google Chrome 0.2.149.27
	Total:                 1483.6ms +/- 0.7%
Mozilla Firefox 3.0.1
	Total:                 3435.0ms +/- 1.2%
Safari 3.1.2
	Total:                 3437.4ms +/- 1.1%
Opera 9.5.2
	Total:                 4003.6ms +/- 4.4%
Internet Explorer 7.0.5730.13
	Total:                 26231.8ms +/- 2.3%

Testato e funzionante su Firefox 3 ed Internet Explorer 7. Copiate la riga che segue nella barra dell’indirizzo, sostituendola con l’URL presente e premete invio.

javascript:document.body.contentEditable='true'; document.designMode='on'; void 0

Buon divertimento!

via blogstorm

Durante l’implementazione di un meccanismo di inserimento dati via web, mi sono imbattuto in un problema derivante dal comportamento atipico del pulsante “Refresh” del browser Mozilla Firefox.

Per evitare il re-submit accidentale dei dati del form mediante un refresh della pagina di destinazione (quella indicata nell’attributo “action” del tag “form”), ho creato un sistema, basato sull’impostazione dell’header “Location:” che redirige il browser dalla pagina che elabora gli input a quella che conferma l’avvenuto inserimento dei dati.

Il “percorso” realizzato durante la navigazione è dunque quello che segue:

1. form.jsp : inserimento dati
2. dataprocess.jsp : elaborazione dati, redirige senza alcun input sulla pagina seguente
3. confirm.jsp : pagina statica di conferma dell’avvenuta ricezione dei dati inseriti.

In questo modo, pensavo, il refresh della pagina confirm.jsp non tenterebbe il resubmit dei dati, essendo quest’ultima differente dalla pagina indicata come action su -1-.
Questo è vero per i browser IE6, Safari 3, Opera 9.5, i quali, log del web server alla mano, effettuano solamente un GET di -3-.
Firefox 3, al contrario, esegue nuovamente un POST su -2- per poi finire come da copione su -3-.

Una soluzione possibile viene dal settaggio di un cookie impostato su -1-, che deve essere letto come prima operazione su -2- ed immediatamente distrutto. La presenza del cookie testimonia che il percorso effettuato per il submit dei dati è effettivamente un POST da -1- e non un refresh da -2- o -3- che sia.

Sulla falsariga del post di ieri, continuo ad appuntarmi i problemi incontrati con JS su Internet Explorer, nella speranza che quanto scritto possa servire, prima o poi, a qualcuno.

Internet Explorer, perlomeno nella versione 6, non supporta la sintassi che segue:

<select id="do">
    <option onclick="do(this)" value="Do This"> Do This </option>
    <option onclick="do(this)" value="Do That"> Do That </option>
</select>

La soluzione viene dalla sintassi

<select id="do" onchange="do( this.value )">
    <option value="Do This"> Do This </option>
    <option value="Do That"> Do That </option>
</select>

ossia dallo spostamento dell’evento dal singolo elemento all’elemento select padre. La funzione dovrà essere ovviamente invocata non più utilizzando this come argomento, ma this.value, ovverosia l’attributo value dell’opzione selezionata. Tale funzione avrà una forma simile a quanto segue:

function do( optionValue )
{
	switch( optionValue )
	{
		case "Do This" :
			// SPECIFIC CODE HERE
		break;
		case "Do That" :
			// SPECIFIC CODE HERE
		break;
	}
}

via matthom