2012-03-21 6 views
12



Ho un'API di registrazione che desidero esporre a un codice JS interno. Voglio essere in grado di utilizzare questa API per accedere, ma solo quando eseguo una build di debug. In questo momento, ho parzialmente funzionante. Registra solo le build di debug, ma le chiamate a questa API sono ancora nel codice quando c'è una build regolare. Vorrei che il compilatore di chiusura rimuova questo codice essenzialmente morto quando eseguo il compilatore con goog.DEBUG = false.Utilizza la funzione di registro del registro di chiusura del compilatore

definizione Log:

goog.provide('com.foo.android.Log'); 
com.foo.Log.e = function(message){ 
    goog.DEBUG && AndroidLog.e(message); 
} 
goog.export(com.foo.Log, "e", com.foo.Log.e); 

AndroidLog è un oggetto Java fornito al WebView questo verrà eseguito in, e adeguatamente externed come questo:

var AndroidLog = {}; 

/** 
* Log out to the error console 
* 
* @param {string} message The message to log 
*/ 
AndroidLog.e = function(message) {}; 

Poi, nel mio codice, posso usare :

com.foo.Log.e("Hello!"); // I want these stripped in production builds 

La mia domanda è questa: come posso fornire questa API, utilizzare questa API in tutto il mio codice, ma poi h hai rimosse le chiamate a questa API quando non sono state compilate con goog.DEBUG = true? In questo momento, il mio codice base sta diventando gonfio con un sacco di chiamate all'API Log che non vengono mai chiamate. Voglio il rimosso.

Grazie!

+0

OK, dopo qualche ulteriore scavo, sembra che funzioni externed non sono inline. http://code.google.com/p/closure-compiler/issues/detail?id = 230 Mi piacerebbe ancora trovare una soluzione alternativa all'apertura di ogni chiamata con goog.DEBUG && –

+0

Ho scritto io stesso un piccolo script in Python per rimuovere tutti i miei messaggi di debug dal sorgente come parte del mio processo di compilazione. Potrei trovare qualcosa anche quando ne avevo bisogno. È strano perché dovrebbe essere un bisogno così comune. – jfriend00

+0

Sì, posso seguire questa strada :) –

risposta

0

OK, è facile farlo se smetto di esportare com.foo.Log() e i suoi metodi. Se voglio davvero essere in grado di accedere in alcuni casi specifici, ma ancora nudo fuori le chiamate di registro nel mio codice interno, posso solo dichiarare due classi per questo:

// This will get inlined and stripped, since its not exported. 
goog.provide('com.foo.android.Log'); 
com.foo.Log.e = function(message){ 
    goog.DEBUG && AndroidLog.e(message); 
} 
// Don't export. 


// This be available to use after closure compiler runs, since it's exported. 
goog.provide('com.foo.android.production.Log'); 
goog.exportSymbol("ProductionLog", com.foo.android.production.Log); 
com.foo.android.production.Log.log = function(message){ 
    goog.DEBUG && AndroidLog.e(message); 
} 
// Export. 
goog.exportProperty(com.foo.android.production.Log, "log", com.foo.android.production.Log.log); 
0

Invece di eseguire il proprio script come jfriend00 suggerito vorrei guardare le API definiscono del compilatore (che è dove goog.DEBUG proviene pure), si dispone di DEBUG, compilato per impostazione predefinita, ma ci si può tira il tuo.

+1

Manca il punto. Il punto non è semplicemente disattivare l'output di debug (è facile). Il punto è rimuovere tutto il codice di debug prima della distribuzione, in modo che non stia prendendo spazio, eseguendo o addirittura mostrando spazio al mondo. – jfriend00

+0

lennel, grazie per il suggerimento. Come accennato da jfriend00, questo mi permetterà semplicemente di passare i dati. Sto già usando i dati passati attraverso il parametro goog.DEBUG, e sta rimuovendo perfettamente il corpo di una funzione. Ma quel corpo di funzione vuoto non viene mai inserito nel mio codice per rimuovere gli usi della funzione. Penso che questo sia dovuto al fatto che CC non può presumere che le funzioni esterne non verranno modificate in fase di esecuzione? –

+0

scusa, sono stato via in vacanza. Se si compila con una variabile define impostata su false, il compilatore ometterà quel codice in modalità avanzata. – lennel

1

la chiusura compilatore offre quattro opzioni in CompilerOptions.java per rimuovere il codice: 1) stripTypes, 2) stripNameSuffixes, 3) stripNamePrefixes e 4) stripTypePrefixes. Lo strumento di creazione Closure plovr, espone stripNameSuffixes e stripTypePrefixes tramite JSON configuration file optionsname-suffixes-to-strip e type-prefixes-to-strip.

Ci sono ottimi esempi di come queste opzioni funzionano in Chiusura: The Definitive Guide alle pagine 442 a 444. Le seguenti linee sono forniti come casi di uso comune:

options.stripTypePrefixes = ImmutableSet.of(“goog.debug”, “goog.asserts”); 
options.stripNameSuffixes = ImmutableSet.of(“logger”, “logger_”); 

di capire le sfumature di questi opzioni ed evitare potenziali insidie, consiglio vivamente di leggere gli esempi completi in Chiusura: la Guida definitiva.

+0

Grazie! Devo dire che sto usando l'attività Closure Ant e quindi non ho la possibilità di passare direttamente le opzioni del compilatore. Stavo contemplando la sottoclasse del compito della formica per passare le mie opzioni di compilatore, ma volevo chiedere prima se ci fosse in effetti un modo per farlo. Daremo un'occhiata anche a plovr. –

+0

@SkyKelsey: le opzioni del compilatore sopra menzionate per il codice strip sono interne al sorgente Java del compilatore Closure, ovvero CompilerOptions.java. Tuttavia, plovr facilita l'uso di stripNameSuffixes e stripTypePrefixes senza scrivere codice Java. Attualmente sto scrivendo una suite di attività Ant per tutti gli strumenti di chiusura che forniranno maggiore flessibilità. Speriamo che siano pronti per l'uscita entro la fine di aprile 2012. –