2012-11-22 7 views
6

Dopo molti anni di mantenere con successo un applet che utilizza il buon vecchio:Utilizzando deployJava.runApplet a bersaglio specifico elemento

<script src="foo.js"></script> 

metodo per incorporare un applet Java, non siamo in grado di coprire le nostre orecchie e cantare " La la! " più.

E 'il momento di utilizzare:

deployJava.runApplet() 

Quando ho fuoco questo metodo utilizzando un gestore di clic (qui utilizzando un listener di eventi su un pulsante tramite jQuery, ma non importa):

$('#button').click(function() { 
    deployJava.runApplet(attributes, parameters, version); 
}); 

... cancella l'intero documento esistente e lo sostituisce con l'applet. Tutto quello che devo sapere è come scegliere come target un elemento DOM specifico come contenitore per l'applet, in modo che la mia pagina non venga cancellata.

Sembra che sarebbe un attributo che potrei passare sotto forma di target: someElement dove "someElement" è o un oggetto DOM o l'ID dell'elemento come una stringa. Ma ahimè, non riesco a trovare la documentazione per tale attributo.

Per ragioni di completezza, ecco quello che viene passato:

/*here is where I imagine there might be an applicable attribute */ 
var attributes = { 
    name: "SomeName", 
    code: "some.class", 
    archive: "some.jar", 
    width: 640, 
    height: 400 
}; 

var parameters = { 
    someParameter: someValue 
}; 

var version = "1.5"; 

posso document.write tutto quello che ho bisogno di ricostruire un documento, ma sono sicuro che si può tutti ben immaginare quanto orribile questa prospettiva sembra me.

Qualsiasi suggerimento sarebbe molto apprezzato.

+0

Un po 'più di codice e meno testo sarebbe stato meglio :-) – fvu

+0

Non c'è alcun codice di cui parlare. Ti aggiornerò solo per mostrarti, però. ;-) –

+1

Dai un'occhiata a [dtjava.js] (http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm#FBJHAIHG), distribuisci il fratello minore di Java che non documenta.write – fvu

risposta

6

In alternativa alla soluzione Christophe Roussy è possibile ignorare document.write mentre è in esecuzione deployJava.runApplet.

Come così:

function docWriteWrapper(func) { 
    var writeTo = document.createElement('del'), 
     oldwrite = document.write, 
     content = ''; 
    writeTo.id = "me"; 
    document.write = function(text) { 
     content += text; 
    } 
    func(); 
    writeTo.innerHTML += content; 
    document.write = oldwrite; 
    document.body.appendChild(writeTo); 
} 

An poi:

docWriteWrapper(function() { 
    deployJava.runApplet(attributes, parameters, "1.6"); 
}); 

Un po 'hacker, ma funziona come un fascino;)

+0

Wow, grazie per aver trovato il tempo di urlare e rispondere a questo, Kolya! Sicuramente vale la pena provarlo almeno! Sono troppo smemorato, quindi ho intenzione di uscire su un ramo e "accettare" questo ... certamente il codice sembra plausibile all'ispezione visiva. :) –

+0

In una nota a margine, il prodotto passerà a JNLP prima possibile, ma penso che avremo sempre un'opzione per l'applet. –

4

Quindi il nocciolo del problema è questo: deployJava.js utilizza document.write. Se si utilizza questo metodo DOPO il rendering di una pagina (rispetto a una parte del rendering della pagina iniziale), prima verrà cancellato il documento. Che ha evidenti ripercussioni negative.

Sebbene sia destinato a JavaFX, le persone hanno segnalato il successo con dtjava.js e ho tutte le ragioni per credere che sia un'alternativa valida.

Tuttavia, altre parti interessate del mio team hanno già svolto attività relative a deployJava.js e non sono disposte a rinunciare a tale lavoro, il che significava che dovevo limitarmi a deployJava.js. C'è solo un modo per farlo: assicurati che deployJava venga chiamato durante il rendering della pagina, non tramite Ajax, eventi o altri trigger ritardati.

Alla fine, stiamo raccogliendo le nostre informazioni e passandole a una seconda pagina che renderà l'applet come previsto. Funziona e, nella maggior parte dei casi, i nostri clienti lo faranno comunque (raccogliendo informazioni, passandole sul lato server e ricevendo una risposta di reindirizzamento), quindi non aveva senso forzare il problema. Stiamo passando informazioni tramite stringa di query, ma potresti probabilmente utilizzare i cookie e/o l'API di localstorage, se si desidera che window.location mantenga l'aspetto più pulito.

Grazie per le risposte, anche se erano nell'area dei commenti. Altre risposte vengono ancora prese in considerazione se qualcuno ha un modo migliore di farlo!

1

Per risolvere questo fastidioso problema, ho scaricato e compromesso deployJava.js in linea 316, sostituite la linea dal mio:

// document.write(n + "\n" + p + "\n" + r); 
    myDiv.append(n + "\n" + p + "\n" + r); 

Dove myDiv è una variabile globale js impostato sul div desiderata prima della chiamata runApplet:

myDiv = jQuery('#someDiv'); 

se si trova una soluzione meno intrusiva lasciare mi sa ...

+0

Questo ha promesso! Non è come se avessero aggiornato deployJava.js e dovremmo preoccuparci di hackerare la correzione ogni volta ...;) Grazie, Christophe. –

+0

Come ho scaricato, sarà la mia decisione di aggiornarlo, ma questo è sempre un problema con questi hack intrusivi e deve essere in qualche modo documentato. –

+0

concordato. Grazie ancora per il suggerimento, Christophe! –

3

Se si sta utilizzando jQuery e desidera raggiungere un determinato elemento dom, piuttosto che semplicemente accodato:

function docWriteWrapper(jq, func) { 
    var oldwrite = document.write, content = ''; 
    document.write = function(text) { 
     content += text; 
    } 
    func(); 
    document.write = oldwrite; 
    jq.html(content); 
} 

docWriteWrapper($('#mydiv'), function() { 
    deployJava.runApplet(attributes, parameters, version); 
}); 
+0

Grazie per la risposta! È strano come alcune domande abbiano una lenta bruciatura e la gente continua a notare modi intelligenti per risolvere i problemi. Molto apprezzato! –

+0

Ciò ha funzionato perfettamente e fornisce esattamente ciò che è stato chiesto. – Derrick

Problemi correlati