Appunti per me, per google e per coloro che sapranno cosa farsene:
$(‘#select_id’).val($(‘option:first’, this).val());
$(‘#select_id’).val(null);
Ispirato da questo, ho fatto una modifica allo script proposto da Yaakov al fine di stampare i risultati nel caro, vecchio sistema metrico decimale e per importare i dati del METAR di Forlì.
E’ necessario installare da CPAN le librerie
use LWP::Simple;
use IO::Socket;
use Geo::METAR;
e modificare l’indirizzo IP della stampante ed il codice ICAO che, nel caso di Forlì, è LIPK.
Lo script è stato testato su una HP4350, che ha un display 20×4. Your mileage may vary.
... Date: Fri, 23 Jan 2009 12:09:48 +0900 From: [?var=TAGMAILFROM] Subject: [?var=rx] ... [?var=rx] http://[?var=urlrx]
Ritenta, sarai più fortunato…
Chrome
Safari
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%
Le premesse lasciamole a chi non ha nulla da dire: andiamo al sodo.
Il problema dello scambio di dati da 1 ad N persone su internet viene solitamente affrontato sulla base del valore di N:
con relativi svantaggi:
La soluzione bittorrent, pur con dei -risolubili?- problemi, appare immediatamente come quella tecnicamente più conveniente, scalando perfettamente da piccoli numeri (comunicazione 1-1) a numeri anche grandissimi (comunicazione 1-N).
Ho deciso di dedicarmi, come progetto a lungo termine, alla programmazione di un client IM basato su XMPP che implementi un tracker/client bittorrent e la relativa gestione dei download ristretta a gruppi di utenze.
Chiunque abbia suggerimenti, feature da proporre, voglia di dare una mano, può lasciare un commento qui.
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
L’impostazione della proprietà innerHTML su un oggetto di tipo select
<select name="name" id="id"> <option value="a">a</option> </select>
tramite una chiamata Javascript come
document.getElementById('id').innerHTML='<option value="b">b</option>';
fallisce miseramente su Internet Explorer.
Il workaround è un wrap dell’oggetto select all’interno di un <div> così strutturato
<div id="div-id"> <select name="name"> <option value="a">a</option> </select> </div>
e la riscrittura dell’intero contenuto del div mediante innerHTML come segue:
document.getElementById('div-id').innerHTML='<select name="name><option value="b">b</option></select>';
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:
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