Qual è il punto di AssetManager di Yii?

Question

non riesco a trovare molte informazioni su AssetManager di Yii per la gestione dei file JS e CSS. La mia domanda è qual è il punto di utilizzare l'AssetManager? Non sono sicuro di quale valore si aggiunge al mio processo di sviluppo, infatti, sembra che complica il mio codice ... ogni volta che cambio il mio script o codice CSS, devo andare in e cancellare il mio patrimonio cartella per assicurarsi ho le ultime versioni.

Sembra è molto più semplice di mettere solo tutti i file Javascript sotto / webroot / js / e basta usare i tag per caricare i file invece di passare attraverso la fatica di AssetManager. In più, la funzione registerCoreScript di Yii pone sempre tag di script all'interno del tag di intestazione, invece di porre sul fondo del codice, nei pressi del tag body di chiusura, come raccomandato dal YSlow.

Penso che ci deve essere una lacuna nella mia comprensione della AssetManager di Yii. Qualcuno ha tutte le idee perché utilizzando l'AssetManager è meglio di codificare i tag di script all'interno del codice PHP? Sono un po 'confuso ...

Grazie!

Answer 1

Sono sicuro che qualcuno può rispondere meglio di me stesso, ma in fondo è così che il sorgente file JS e CSS può rimanere nella cartella protetta.

Questo è un po 'più sicuro per una cosa, ma il vantaggio principale per me è che è possibile comprimere e minify ed elaborare le vostre risorse con il sistema di pubblicazione di asset, e rende più facile ospite vostra JS e CSS su un CDN dal momento che è separato dalla base di codice.

Inoltre, ecco un risposta ufficiale dal Qiang (il ragazzo che ha scritto Yii) su questo.

Answer 2

Il principale vantaggio di gestore patrimoniale di Yii è che che permette di strutturare i componenti in maniera autonoma .

Un racconto di un widget

Si consideri un componente che è un widget UI. Supponiamo che la distribuzione include un paio di attività insieme con l'implementazione dei componenti, ad esempio i file:

SuperWidget.php
superwidget.css
superwidget.js
image_for_css.png

Pensate a come si potrebbe integrare questo widget nella tua applicazione se il gestore patrimoniale non esisteva. passaggi tipici possono includere:

1. Copia SuperWidget.php da qualche parte all'interno della directory protected/
2. Copia superwidget.js nella directory js/
3. Copia superwidget.css nella directory css/
4. Copia image_for_css.png nella directory images/ o forse anche css/ dentro per contribuire a ridurre le dipendenze percorso relativo

Quindi in fase di esecuzione SuperWidget emetterebbe tag appropriati per includere il CSS e JavaScript; per fare questo, si avrebbe bisogno di sapere esattamente dove hai messo tali attività . In altre parole:. alcune scelte per quanto riguarda l'installazione può essere fatta in modo arbitrario, ma poi sono scolpiti nella pietra meno che non andiate e modificare la fonte

è il widget riutilizzabile?

Se questo widget sono stati altamente personalizzabile e destinata ad essere una parte inseparabile della vostra applicazione, allora questo approccio avrebbe funzionato bene e non ci sarebbe molto bisogno di avere un asset manager. Ma cosa succede se si tratta di un componente ampiamente utile che si desidera distribuire?

I problemi iniziano a sorgere.

Prima di tutto la schema di distribuzione che abbiamo esaminato richiede agli utenti del widget per copiare file diversi in diverse directory, complicando la procedura di installazione e aumentando la possibilità di errore.

Ma il problema più grande è che il vostro schema di distribuzione potrebbe entrare in conflitto con quella di qualsiasi altro componente sviluppato indipendentemente del tuo. Che cosa succede se qualcun altro ha deciso di avere un file superwidget.js troppo?

Se le istruzioni di installazione per queste due componenti conflitto poi, ovviamente, uno dei quali non possono essere installati a tale scopo, e quindi si ricorre a cambiare alcuni dettagli e hacking del codice sorgente del componente per accogliere questi cambiamenti. Se in seguito l'aggiornamento a una nuova versione di tale componente si sarà costretto a spiegare con cura le personalizzazioni, facendo una "copia / sovrascrittura" upgrade impossibile.

Tutto questo non è davvero bella, e mentre può essere improbabile che accada, in pratica, di certo non mi sembra giusto.

Asset Manager, fare in modo

Ecco dove il gestore patrimoniale viene in Supponiamo che si decide di strutturare il componente in questo modo:.

superwidget/
  SuperWidget.php
  assets/
    css/
      superwidget.css
    js/
      superwidget.js
    images/
      image_for_css.png

E 'possibile copiare direttamente da qualche parte all'interno della vostra directory protected/ non importa ciò che gli altri componenti si è installato; la cosa peggiore che potrebbe accadere qui è che dovreste rinominare superwidget/ a qualcosa d'altro se ci fosse un conflitto.

Utilizzando il gestore patrimoniale, SuperWidget.php pubblica tutta superwidget/assets/ directory, con la copia fino a raggiungere ad esempio, assets/1337c0de/ dove assets/ è il percorso base patrimoniale dell'applicazione e 1337c0de/ è un hash casuale creato da Yii e garantito di non conflitto con qualsiasi altro bene pubblicati.

Ciò significa che i beni per SuperWidget non può assolutamente in conflitto con quelli di qualsiasi altro componente , rendendo SuperWidget veramente riutilizzabili. E dal momento che la struttura di directory all'interno 1337c0de/ sarà lo stesso come nella vostra distribuzione, CSS può fare riferimento alle immagini utilizzando il percorso relativo ../images/ senza la necessità di fare riferimento al valore del hash casuale (che si conoscono solo dopo la pubblicazione).

Qual bene gestireR non è

• Non è un modo per aumentare la sicurezza. La vostra fonte componente sarebbe da qualche parte dentro protected/ in ogni caso (quindi non c'è miglioramento), e le attività devono essere accessibile dal Web, non importa dove essi finiscono per essere copiato (nessuna sicurezza per loro non importa quale).
• Non è un catch-all soluzione per l'elaborazione le risorse (ad esempio minifying CSS). Mentre è possibile installare un gestore patrimoniale personalizzata che fa questo, non dimenticate che i beni inclusi con componenti riutilizzabili sarà una piccola minoranza tra tutti i beni "di applicazioni di base"; se si desidera che minification su tutta la linea, si 'll deve anche tutto il processo il resto e il gestore patrimoniale non si contribuisce a lì.

TL; DR

Il gestore patrimoniale consente di realizzare componenti che sono facilmente distribuibili e possono essere inclusi in applicazioni senza la paura di creare conflitti con gli altri componenti.

Answer 3

Un altro vantaggio che mi piace circa l'asset manager, è che permette di aggiornare i file di asset, senza dover dire agli utenti di cancellare la cache.

http: // www .yiiframework.com / wiki / 311 / assetmanager-clearing-navigatore-s-cache-on-site-update /