Witam. Moze niektorym to pytanie wyda sie głupie i banalne, niemniej jednak jest mi potrzebne.

Z benchmarka mojego wynika ze tworząc system języków, stosując tablicę asocjacyjną zamiast stałych jest 2 -3 razy szybciej. Stosując indeksy cyfrowe jest jeszcze szybciej. Jest to ok. 10-20% czasu wykonywania skryptu.

Niemniej jednak, jeśli stworzę tablicę asocjacyjną to za każdym razem w każdej metodzie gdzie chce uzyc jezyka bede musial pisac global $langs. Dostęp do tablicy przez singleton jeszcze bardziej mija sie z celem gdyż wyjdzie jeszcze wolniej niż stałe.

Mozna (bez uzycia register_globals) utworzyc sobie tablicę superglobalną jak $_POST? bylaby bardzo wygodna w uzyciu.

zamiast pisac:

global $langs;
new Label($langs['pobieranie_danych']);

pisałbym sobie
new Label($langs['pobieranie_danych']);

http://www.php.net/manual/en/reserved.variables.globals.php

Nie, nie można.

Prawdę mówiąc jeżeli chcesz mieć dostęp globalny do jakiejś zmiennej, to albo global, albo singleton. Jest jeszcze zmienna superglobalna: http://www.php.net/manual/pl/reserved.variables.globals.php do której możesz wrzucić dane, tyle że tak czy inaczej, wciąż te dane są globalne, co to za różnica czy użyjesz global, czy wrzucisz to do jakiejś globalnej zmiennej? Zawsze możesz przekazywać takie dane poprzez parametr, a jeżeli ci to nie odpowiada, to z trzech rozwiązań (global, globals, singleton) z tego wszystkiego najlepszy chyba będzie singleton. Chodź ręki uciąć sobie nie dam

Języka nie bede przekazywal przez parametr bo musialbym przerobic chyba wszystkie procedury.

Faktycznie, moge wrzucic do $_GLOBALS cały język i wtedy nie musze dodawac na poczatku kazdej metody global $lang, tylko bezposrednio odczytam z $_GLOBALS. Dzięki za odpowiedź.

Singleton hmmm... w sumie predkosc utworzenia tablicy z językiem będzie taka sama jak przy tabl. asocjacyjnej, predkosc odczytu znacznie wolniejsza, ale przy wyswietleniu strony jest tych odczytow moze z 10-20 gdy przy tworzeniu tablicy jezyka jest do wpisania tych wpisow np 1300, więc małą wydajnosc singletonu przy odczycie mozna pominąć

Singleton bylby wygodny:D Lang::get('moje_piniądze!'); i w razie czego mozna by go zamienic na tablicę za pomocą znajdz i zamien z Lang::get('(.*?)') na $_GLOBALS['(.*?)']; gdyby okazał się wolny troszke przyjemniej sie wpisuje singleton niz ten dolar z kapslokiem.

dzięki panowie za inspirację.

to moze mam jeszcze takie pytanie:

Dlaczego taki .htaccess nie przekierowuje mnie na strony z błędami?

Options -Indexes
php_flag magic_quotes_gpc off
ErrorDocument 404 /Pages/error.php?error=404
ErrorDocument 403 /Pages/error.php?error=403
ErrorDocument 405 /Pages/error.php?error=405
ErrorDocument 406 /Pages/error.php?error=406
ErrorDocument 408 /Pages/error.php?error=408
ErrorDocument 409 /Pages/error.php?error=409
ErrorDocument 410 /Pages/error.php?error=410
ErrorDocument 414 /Pages/error.php?error=414
ErrorDocument 415 /Pages/error.php?error=415
ErrorDocument 400 /Pages/error.php?error=400
ErrorDocument 401 /Pages/error.php?error=401
<Files .htaccess>
Deny from all
</Files>

Htaccess jest w tym samym katalogu co katalog /Pages

i trzecie pytanie:

zrobilem na stronie system wyjątków w sumie nic specjalnego, po prostu jak waliduje dane po stronie modelu (mam MVC) to rzucam wyjątek który pozniej zostaje złapany po stronie widoku i powoduje wyswietlenie komunikatu o błędzie.

No i ten komunikat o bledzie zawiera przyciski: powrot, strona główna itd.

Problem w tym ze np. jeden widok moze byc wywolany z 3 innych i wtedy nie wiadomo na ktory wrocic w razie wystapienia błędu.

Przykład:
widok default -> widok wszystkich poradników -> widok dodawania -> widok odbioru formularza -> błąd -> wróć do?
widok default -> widok listy poradników gracza -> widok dodawania ->widok odbioru formularza -> błąd -> wróć do ?

w tym momencie widok odbioru formularza nie wie na jaki widok ma kierowac przycisk powrót (chodzi o to by przerzucilo uzytkownika tam gdzie był).

generalnie jakby zrobic przekierowanie na poprzedni widok /strone w razie wystapienia bledu automatycznie to zaoszczedzilbym multum pisania.

myslalem o trzymaniu historii otwieranych stron w cookies, ale jesli uzytkownik otworzy strone w kilku kartach to bedzie mu głupio skakało pomiedzy stronami. musiałbym dołączać jakieś ID do strony. Tylko jakie? W linku get nieelegancko. W post nie ma jak bo nie wszystkie przyciski to submit. Z javascriptu nie chce korzystac w kwestiach sterowania stroną.

w takim razie moze przypisac kazdemu widokowi jakis hash i budowac w cookies drzewo rozgalezien ktory hash wywołał który i na podstawie jego wracać? ale to tez bez sensu bo beda sie powtarzaly.

Moze da sie te powroty jakos prosciej zrobic? rozwiazanie z dodawaniem do kazdego linku parametru powrot='obecna_strona' nie podoba mi sie za bardzo

Odnośnie przechwytywania błędów. Jakiś czas temu też stałem przed tym problemem i się zastanawiałem, bo powiedzmy padnie baza i będzie to błąd dla całej strony, a ja sobie wymyśliłem (oczywiście hipotetycznie) stronę błędu, która jest jakby podstroną, czyli zawiera w sobie stopkę/top/jakieś menu i teraz jeżeli padnie baza, to miałbym błąd w błędzie? No właśnie o ile dla błędu 404 taki motyw jeszcze jest możliwy, tak dla błędu aplikacji nie bardzo. W "szablonie" dla strony błędu, najzwyczajniej dane przeznaczone dla usera, nie mogą być z niczego pobierane, najlepiej jakby tam wszystko było na sztywno, oczywiście prócz komunikatu, ale resztę najlepiej zrobić na sztywno. Tak przynajmniej ja ten problem rozwiązałem. IMO zamieściłbym tam 3 linki: strona główna, poprzednia strona (js - historyback), spróbuj jeszcze raz (link do strony na której aktualnie jest).

Osobiście trzymam konfigurację i pliki językowe w 2 klasach statycznych, Config i Locale. Obie nie są zbyt złożone, po profilowaniu xdebugiem aplikacji żadna z tych klas nie znajdowała się w pierwszej dziesiątce. Masz tam wtedy w takiej metodzie dodatkowo sprawdzanie czy dana zmienna istnieje, można dodać defaultową wartość dla nieistniejącej zmiennej. A już nie wspomnę o że można sobie w taką klasę wstawić fliczer typu poruszanie się zagnieżdżonej tablicy (wielowymiarowej).





itp znacznie przyjemniej korzysta się z takiej konfiguracji czy lokalizacji (tłumaczeń).

To akurat nie jest problem przeciez moge sobie po prostu zapisac strone html wygenerowana przez blad 404 dla niezalogowanego usera (czysty kod html bez pehapa) zapisac w pliku error404.html i wyswietlic. Tez myslalem o tym ze strona bledu generowana przez php nie wyswietli sie dla bledu 500

Problem jest w tym - dlaczego nie wyswietla tych stron? czy to przez parametr w linku? czy to musi byc strona html zamiast php?

A jesli chodzi o ten system wyjatkow to on nie dotyczy bledow typu 404 tylko np zle podałes date, probujesz utworzyc turniej w czassie przeszlym itp wiec nie moze byc na sztywno bo to rozne ekrany w widokach beda.

Co do tego singletonu z językiem - zajebisty pomysl! mozna np zrobic kilka getterow dla kilku kategorii jezykowych i dodawanie stalych jezykowych rozbic na kilka metod ktore dodaja je do tablicy i inicjowac te czesci tablicy jezyka ktore sa akurat potrzebne:) genialne;d

No ja coś takiego mam u siebie. Powiedzmy taki zapis:



Jest odpowiednikiem takiego zapisu:



Dodatkowo póki co tylko w konfiguracji zrobiłem sobie taki myk (oczywiście to nie jest nic odkrywczego, bo chociażby symfony coś podobnego ma) że w konfiguracji możesz się odnieść do konfiguracji. Czyli powiedzmy masz sobie taką konfigurację:



(konfiguracja zapisana w yamlu) i przykładowo %database.portale% to jest tak samo jakbym użył:



Takie odniesienie się do konfiguracji, wewnątrz konfiguracji. Dość przydatny feature. W przypadku lokalizacji, to raczej bym pokombinował nad takim rozszerzeniem getera, żeby jako parametr można było podać tablicę parametrów do podmiany. Bo powiedzmy masz jakiś komunikat dla użytkownika, i w tym komunikacie są jakieś dane które są różne, chociażby nick usera. I wtedy albo rozbijasz ten tekst, albo tworzysz w tekście jakieś punkty odniesienia i takie coś akurat w przypadku lokalizacji jest raczej potrzebnym feature



Wyjątków używaj tylko w przypadku błędu aplikacji, a nie w przypadku kiedy user poda złą datę.. A dlaczego ci to nie działa, nie mam bladego pojęcia.

Jakies argumenty za swoim stanowiskiem? Czy tylko "bo tak"?

wyjątki właśnie po to są.. jesli by tak nie bylo to ciekawe dlaczego w prawie kazdym jezyku obiektowym funkcja parsująca string na int rzuca wyjątek jesli tekst nie jest tekstowym zapisem cyfry...

Mam klase wyjątków grubych ktore są rzucane w wypadku błędu aplikacji, oraz wyjątki lekkie dziedziczące z innej podklasy Exception.

class Exception - jest w PHP
class InternalException extends Exception - rzucana przez ErrorHandler w przypadku wystapienia błędu- ten wyjątek jesli zostaje zlapany to rysuje ekran o błędzie a jezeli nie zostanie zlapany to jest lapany przez exceptionHandler i zapisywany do pliku...
class UserException extends Exception - rzucana w sytuacji gdy błąd wywołał użyszkodnik...

class NotLoggedException extends UserException...
class WrongDataException extends UserException...
class NotFoundException extends UserException...

Dzieki temu nie powtarzam sie, a jednoczesnie dla kazdego indywidualnego wystapienia bledu moge zdefiniowac unikalny komunikat. dodatkowo rzucenie wyjątka przerywa bieg programu ktory i tak by sie nie wykonal z powodu blednych danych wiec nie musze kombinowac z jakims Viewer::drawError(typBledu, komunikatBledu); return; tylko rzucam wyjatek i dzieje sie samo dalej.

Tym bardziej ze np sprawdzajac token formularza uzywam metody token::verify. i ta metoda aby wyswietlic komunikat o przedawnionym tokenie musiala by miec referencje na obecny widok, a tak rzuca wyjątek ktory jest lapany w widoku i to widok wyswietla komunikat o bledzie. Kod jest bardziej zwiezly, mniej pisania.


Tylko przydalo by sie zautomatyzowac jakos generowanie przyciskow powrotnych dla wyjątków.

I te wyjątki pozwalają mi na szybkie zapodanie uzytkownikowi informacji że: wymagane jest zalogowanie aby uzyskac dostęp do tej funkcji (dajmy na to - panel turniejowy: info moze zobaczyc kazdy, reszte tylko zalogowani), że uzytkownik przekroczyl uprawnienia - np ktos spoza druzyny probuje wejsc do jej ustawien..

Jakbys chcial to zrobic bez wyjątków? dla kazdego widoku, za kazdym razem pisać od nowa ekran informujący o błędzie? jeden informujący o tym ze uzytkownik wpisal litere zamiast dnia, drugi ze wpisal zly miesiac w datownik itd itp.... a co jezeli podany parametr przy tworzeniu np. nowego teamu musi byc cyfrą?

http://forum.php.pl/index.php?showtopic=146581



validaitor, który przeważnie jest używany przez klasy formularzy i tam takie komunikaty już są. Poczytaj o klasie form w symfony czy zendzie, czy jakichś innych frameworkach. Generalnie ja nie używam klasy form, tylko samej klasy valdiatora bo moim zdaniem do tworzenia formularza, który czasami ma 2 imputy z czego jeden to submit, wcale nie potrzebuje zaawansowanej klasy. Oczywiście w tej kwestii każdy ma swoje zdanie