Tworzenie zmiennej superglobalnej, czy mozna utworzyc zmienna superglobalną? Opcje

[Orzeszekk]

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']);

[by_ikar]

Kod

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:

Kod

Locale::get('home.form.login.name');

Jest odpowiednikiem takiego zapisu:

Kod

$locale['home']['form']['login']['name'];

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ę:

Kod

framework:
    database:  %database.portale%


database:
    portale:
        driver:     mysql
        dbname:     administracja
        host:       localhost
        user:       root
        password:   secret
    admin:
        driver:     sqlite
        dbname:     %path.app%/data/admin.db

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

Kod

Config::get('database.portale');

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 (IMG:style_emoticons/default/wink.gif)

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 tongue.gif wiec nie moze byc na sztywno bo to rozne ekrany w widokach beda.

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.