Przejście z CGI do mod_perl. Zrozumienie mojego, naszego, lokalnego

Question

Używam apache mod_cgi przez kilka lat. Teraz przechodzę do mod_perl i znalazłem kilka problemów, szczególnie z podprogramami. Do tej pory nigdy nie używałem my, our ani local; a skrypty CGI działały bez problemów. Po przeczytaniu dokumentacji, a nawet niektórych wcześniejszych pytań, rozumiem mniej więcej, jak działa my,i local. Obawiam się, jakie informacje będą dzielone między kolejnymi żądaniami (jeśli dobrze rozumiem, to jest główny problem, który muszę mieć podczas uruchamiania mod_perl zamiast mod_cgi).

• Czy jest jakaś różnica między używaniem our w skalara czy tylko skalara bez deklarowania nic specjalnego, takie jak my? Czy nie są zarówno globalne?
• Jeśli nie zadeklaruję, że skalar jako prywatny zostanie udostępniony w następnym żądaniu? Nawet w innym wniosku innego skryptu perl na tym samym serwerze?
• Jak udostępnić wartość skalarna wewnątrz podprogramu na zewnątrz podprocedury, ale poza tym samym plikiem i tym samym żądaniem?
• Jeśli używam my w skalarnym wewnątrz if na tym samym poziomie pliku lub w tym samym podprogramie, a następnie tworzę kolejny if, gdzie używam tego samego skalarnego; czy ten skalar jest dzielony pomiędzy if, czy też każdy if oznacza różne bloki? A co z while i for, czy są one różnymi blokami dla wcześniej zadeklarowanego skalaru my lub który działa tylko dla podprogramów i plików?

Answer 1

Edytuj: to są ogólne informacje dotyczące tylko zakresu zmiennych Perl. Proszę zobaczyć post Borodina dla konkretnych problemów z mod_perl.

Zmienne zadeklarowane za pomocą my są leksykalne. Innymi słowy, istnieją one tylko w obecnym zakresie. Powinieneś zadeklarować wszystkie zmienne domyślnie z my; rób coś innego tylko wtedy, gdy chcesz mieć inną funkcjonalność.

Używanie zmiennych o zasięgu leksykalnym jest podstawową częścią dobrego projektowania kodu w (prawie) dowolnym języku. Wprowadzenie use strict; i use warnings; we wszystkich skryptach będzie wymagać przestrzegania tej dobrej praktyki.

our to sposób deklarowania zmiennej globalnej; podstawowy wynik jest bardzo podobny do użycia niezgłoszonych globali. Jednak ma dwie różnice:

1. Wyraźnie twierdzisz, że chcesz, aby zmienna była globalna. Jest to dobra praktyka do naśladowania, ponieważ użycie zmiennych globalnych powinno być wyjątkowym przypadkiem. Z tego powodu możesz stworzyć globalny w ten sposób, nawet jeśli jesteś use strict;.
2. Zmienna zadeklarowana za pomocą our będzie dostępna pod nazwą zadeklarowaną we wszystkich pakietach w bieżącym zakresie. Z kolei niezadeklarowana zmienna jest dostępna tylko poprzez nazwę prostą w aktualnym pakiecie. Poza tym można to tylko nazwać jako $package::variable.

Aby uzyskać więcej informacji, zobacz the documentation for our.

local nie tworzy zmiennej leksykalnej; zamiast tego jest to sposób na nadanie zmiennej globalnej wartości tymczasowej w ramach bieżącego zakresu. Stosowana jest przede wszystkim ze specjalnych wbudowanych (interpunkcyjnych) zmiennych Perla:

{ 
    local $/; #make the record separator undefined in this scope only. 
    my $file = <FILE>; #read in an entire file at once. 
} 

Możesz iść daleko po prostu za pomocą my przez cały czas dla swoich zmiennych i stosując local tylko w szczególnych przypadkach, jak to przedstawiono powyżej.

Answer 2

mod_perl działa poprzez zawijanie każdego skryptu Perla w podprogramie o nazwie handler w pakiecie na podstawie nazwy i ścieżki skryptu. Zamiast uruchamiać nowy proces uruchamiania każdego skryptu, ten podprogram handler jest wywoływany przez jedną z wielu trwałych wtyczek Perla.

Zwykle ta wiedza pomoże dużo do zrozumienia zmian w środowisku z mod_cgi, ale ponieważ nigdy nie zostały dodane use strict do swoich programów i zapoznać się z działaniem deklarowanych zmiennych masz dużo do nadrobienia !

mod_perl środowisko ma potencjał do powodowania nieoczywisty naruszenia bezpieczeństwa i należy rozpocząć już teraz do use strict na każdy skryptu i deklarują każdą zmienną. use Carp pomoże również zrozumieć dzienniki błędów.

Nazwa zmiennej zadeklarowana jako our jest leksykalnym synonimem dla zmiennej pakietowej o tej samej nazwie, której można używać bez pełnej kwalifikacji nazwy przez podanie nazwy pakietu. Na przykład, zwykle zmienna zadeklarowana za pomocą our $var zapewni dostęp do skalaru $main::var (jeśli nie było wcześniejszej deklaracji package) bez określenia main::. Jednak takie zmienne, które rozpoczęły życie z wartością undef w mod_cgi będą teraz zachowywać swoje wartości z poprzedniego wykonania danego wątku mod_perl, a dla spójności najbezpieczniej jest zawsze zainicjować je w punkcie deklaracji. Zauważ również, że domyślna nazwa pakietu nie jest już main z powodu owijania, które robi mod_perl, więc nie możesz już uzyskać dostępu do zmiennych pakietu przy użyciu prefiksu main::, i nierozsądne jest znalezienie rzeczywistej nazwy pakietu i jawne użycie tego ponieważ będzie to długa nazwa, która zmieni się po przeniesieniu lub zmianie nazwy skryptu.

Zmienna to taka, która istnieje niezależnie od tablicy symboli paczek, a zwykle jej żywotność jest czasem działania pliku otaczającego (dla zmiennych zadeklarowanych w zakresie pliku) lub podprogramu. Są one bezpieczne w mod_perl, jeśli oba są zadeklarowane i użyte w zakresie pliku skryptu lub całkowicie w ramach podprogramu, ale możesz zostać użądlony, jeśli mieszkasz zakresy i zadeklarujesz my $global w zasięgu pliku, a następnie spróbujesz użyć go w podprocedurze. Powód tego nie jest prosty, ale jest spowodowany przez mod_perl zawijanie skryptu w podprogramie handler, więc masz zagnieżdżone deklaracje podprogramów. Wewnętrzny podprogram będzie miał tendencję do przyjmowania tylko pierwszego wystąpienia i ignorowania jakichkolwiek innych utworzonych przez późniejsze wywołania do handler. Jeśli potrzebujesz zmiennej globalnej, powinieneś ją zadeklarować za pomocą our i zainicjować ją w tej deklaracji, jak opisano powyżej.Zmienna jest bardzo podobna do zmiennej , ponieważ tworzy synonim zmiennej pakietowej. Jednak tymczasowo zapisuje bieżącą wartość tej zmiennej i zapewnia nową kopię do użycia aż do końca pliku lub zakresu bloku. Ze względu na automatyczne tworzenie i usuwanie w jego zasięgu może być użyteczną alternatywą dla skryptów my w szczególności, gdy używasz wskaźników do struktur danych, takich jak, powiedzmy, instancja klasy CGI. Stwierdzenie, że our $cgi = CGI->new poprawnie utworzył obiekt, ale z powodu trwałości 01_trwałości mod_perl, pozostawiłoby go w pamięci do czasu, aż następne wykonanie wątku usunie go, aby zrobić miejsce dla innego.

Co do pytania:

• Korzystanie zmienną bez deklarowania albo powoduje błąd kompilacji, jeśli use strict jest na swoim miejscu, jak powinno być. W przeciwnym razie jest synonimem tej zmiennej w bieżącym obszarze nazw pakietów.

• Zmienne to zmienne pakietowe lub zmienne leksykalne; nie ma możliwości zadeklarowania zmiennej jako jako prywatnej. Zmienne leksykalne (zadeklarowane za pomocą my) będą tworzone i niszczone przy każdym uruchomieniu skryptu, chyba że utworzono nieprawidłowe zamknięcie , jak opisano powyżej, pisząc podprogram, który używa zmiennej zadeklarowanej w szerszym zakresie, gdy zmienna będzie trwałe, ale nie zrobią tego, czego chcesz. Zmienna zadeklarowana za pomocą our zachowa swoją wartość przez wywołania skryptu, a jedna zadeklarowana z local zostanie zniszczona po zakończeniu skryptu. Zarówno zmienne our, jak i local są zmiennymi pakietowymi, a wszystkie odwołania do tej samej nazwy zmiennej odnoszą się do tej samej zmiennej.

• Aby zadeklarować zmienną, która jest stale dostępna wszędzie w ramach jednego wywołania skryptu, można użyć zmiennej local lub zainicjowanej zmiennej . Zakres pliku local $global jest w dużej mierze równoważny ze skryptami our $global = undef dla mod_perl. Jeśli używasz zmiennej our, aby wskazać strukturę danych, pamiętaj o zniszczeniu jej na końcu skryptu za pomocą undef $global.

• my zmienne są unikalne, a widoczne wewnątrz bloku, w którym zostały zadeklarowane, czy to jest blok wewnątrz if, while lub for, lub nawet tylko gołe { ... } zakresie bloku. Zawsze używaj zmiennych my dla tymczasowych zmiennych roboczych, które są używane tylko wewnątrz bloku i są dostępne nigdzie indziej.

Mam nadzieję, że to pomoże