Które rozszerzenia plików są zależne od zaufanej pamięci ColdFusion

Question

Jakie rozszerzenia plików są buforowane przez zaufaną pamięć podręczną? CFM i CFC są oczywiste, ale co z CFR? Czy istnieją inne rozszerzenia plików, które są przechwytywane przez zaufaną pamięć podręczną?

niektórych miejscach ja wiem/podejrzewam, że pliki wchodzą cache szablonu to:

• bezpośrednio określony w URL (cfm, cfml, cfc, więcej?)
• cfinclude (dowolne rozszerzenie pliku, który jest używany w np cfinclude <cfinclude template="./some.css">)
• cfmodule (cfm, więcej?)
• cfimport (cfm również jar i tld?)
• cfobject, CreateObject (cfc, również .net, com, usługi Java i internetowych?)
• cfreport (cfr które mogą być spełnione użyteczności cfcompile?)

Czy istnieją inne znaczniki które będą miały taki sam efekt dodawania treści do pamięci podręcznej szablonów?

Answer 1

Niestety nie ma oficjalnego źródła tych informacji. Jednak przy dużej ilości pracy można przetestować każdy tag, aby sprawdzić, czy pliki znajdą się w zaufanej pamięci podręcznej.

Twoje pierwsze dwa punkty są objęte odpowiednio Shawn Holmes' answer i Sean Corfield's answer.

Bullet 3: cfmodule jest ograniczony do plików cfm, więc rozszerzenie jest jedynym, o który musisz się martwić.

Bullet 6: cfreport nie powinien wchodzić do pamięci podręcznej szablonów, ponieważ konwertuje plik, nie kompilując go do wykonania kodu.

Answer 2

Domyślnie ColdFusion jest dostarczany z rozszerzeniami * .cfm, * .cfc i * .cfml zmapowanymi w JRun jako zaufanymi rozszerzeniami. Możesz wyświetlić te mapowania, otwierając pliki konfiguracyjne j2ee-web.xml i web.xml w \ JRun4 \ serwery \ cfusion \ cfusion-ear \ cfusion-war \ WEB-INF \ (lub w pobliżu tego, w zależności od instalacji) :

<servlet-mapping id="coldfusion_mapping_3"> 
    <servlet-name>CfmServlet</servlet-name> 
    <url-pattern>*.cfm</url-pattern> 
</servlet-mapping> 
<servlet-mapping id="coldfusion_mapping_4"> 
    <servlet-name>CFCServlet</servlet-name> 
    <url-pattern>*.cfc</url-pattern> 
</servlet-mapping> 
<servlet-mapping id="coldfusion_mapping_5"> 
    <servlet-name>CfmServlet</servlet-name> 
    <url-pattern>*.cfml</url-pattern> 
</servlet-mapping> 

Jednakże, można również ręcznie skonfigurować mapowania nowiutkie tutaj, jak również, co pozwoli ColdFusion do analizowania/skompilować tagów CFML w plikach z innym rozszerzeniem, jak również (pracowałem już z serwerów CF że zostały skonfigurowane do parsowania .shtml, na przykład)

Uwaga: Będziesz musiał również wykonać dodatkową konfigurację swojego serwera WWW, czy to Apache, IIS, czy cokolwiek innego.

Po skonfigurowaniu CF do obsługi pliku określonego rozszerzenia, jest on dodawany do listy plików przetwarzanych w zaufanej pamięci podręcznej - ponieważ plik ten ostatecznie odpowiada skompilowanemu plikowi .class pod maską .

Answer 3

Adobe ColdFusion (i Railo) kompiluje szablony CFML do kodu bajtowego JVM i, jeśli zostało to skonfigurowane, zapisuje skompilowane klasy (klasy) na dysk jako pliki .class. Pamięć podręczna szablonów jest mechanizmem mówiącym: jeśli klasa docelowa jest już załadowana, nie przejmuj się plikiem (źródłowym) na dysku, aby sprawdzić, czy potrzebuje rekompilacji - zaufaj temu, co jest w pamięci.

Niedawne udoskonalenia ACF i Railo umożliwiają określenie, że pliki (źródłowe) mogą być sprawdzane zawsze (niezaufane), raz na żądanie, nigdy (zawsze zaufane).

To nie powinno być wiadomością dla nikogo.

Oczywiście, ACF i Railo skompilują dowolny plik .cfm lub .cfc, który jest proszony o przetworzenie, aby te "trafiły" do zaufanej pamięci podręcznej, jeśli jest włączona.

Jeśli cfinclude plik - dowolny plik - ACF i Railo również skompiluje to do kodu bajtowego JVM (i utworzy plik .class na dysku, jeśli zostało to skonfigurowane). Ponieważ skompilowany plik jest kompilowany, będzie również "kończyć się" w zaufanej pamięci podręcznej.Co się stanie, jeśli włączysz plik CSS? Zostaje skompilowany do kodu bajtowego, który wyprowadza całą zawartość pliku CSS jako ciąg do strumienia odpowiedzi. Ponieważ jest to klasa skompilowana, która teraz wyprowadza zakodowany ciąg znaków, jeśli zmienisz plik źródłowy CSS i ma włączone zaufane cache, ACF i Railo zaufają temu, co jest w module ładującym klasy, i nie rekompilują go (zakładając, że "nigdy" źródłem sprawdzenia jest administrator oprawa).

Możesz to sprawdzić, czyszcząc folder cfclasses, restartując silnik CFML i uruchamiając swój kod. Zobaczysz plik .class dla twojego pliku CSS (zakładając, że masz zapisane pliki klas na dysku włączone).

Tak więc, cfinclude wymusza kompilację "dowolnego" pliku, a normalne reguły zaufanej pamięci podręcznej mają zastosowanie do klas ładowanych do pamięci.

Nie używam już ACF, więc nie mogę szczegółowo mówić do plików .cfr (Railo nie obsługuje plików raportów), ale najprawdopodobniej zależy to od tego, czy ACF skompiluje plik .cfr, czy nie. Powinno to być łatwe do zweryfikowania (patrząc w folderze cfclasses).