Algorytm do wersji językowej, konsultacje Opcje

[daves]

Witam,

Chcę się z wami skonsultować i usłyszeć opinie nt. mojego rozwiązania.

Tworzę system wielojęzyczny przy użyciu Zenda i szablonów SMARTY.
Najważniejszym założeniem z jakiego wyszedłem był globalny dostęp do danych językowych ale przy założeniu, że czynności związane z odczytaniem odpowiedniego tekstu będą możliwie zminimalizowane.
Chcąc stworzyć automatyczny system wielojęzyczny zastosowałem takie oto rozwiązanie.
- Stworzyłem klasę w pełni statyczną, którą inicjuję już w samym bootstrapie i inicjuję dane w odpowiednim języku.
- Pozwoliłem sobie na dostęp do tej klasy za pomocą odwołania statycznego TKlasa::get('firstname') gdzie wywoływana będzie metoda __callStatic i tam odpowiednio obsłużona.
- Jako, że nie chciałem za każdym razem tworzyć obiektu i przekazywać do View postanowiłem stworzyć obiekt już w samym szablonie z odpowiednią ilością danych w tablicy assocjacyjnej przy użyciu ASSIGNE a następnie standarowe odczytanie wartości.

Wiem, że temat był maglowany setki razy ale takiego rozwiązania nie znalazłem.
Dlaczego tak? Ano dlatego, że przy tworzeniu nowego szablonu nie muszę się martwić o dostęp do tekstu i nie trzeba wykonywać nadmiarowych czynności.
Jest tylko inicjalizacja na samym pocżątku, potem w szablonie assigne i następnie odczyt np. labela.

Tutaj chciałbym usłyszeć waszą opinię, czy takie rozwiązanie jest możliwie optymalne, czy i gdzie mogę spodziewać się problemów lub też co mógłbym zmienić by to ulepszyć.

Pozdrawiam
DS

Ten post edytował daves 9.02.2012, 08:57:48

[Sephirus]

Jeśli przy inicjalizacji tej statycznej klasy ustawiasz jej rodzaj języka i ładujesz (leniwie czy nie) odpowiednie pliki jezykowe (o ile masz to w plikach) to nie widzę raczej "bardziej optymalnego" rozwiązania.

Rozumiem też, z tego co napisałeś, że assignowanie do smarty jest wykonywane automatycznie a w samym szablonie potem odwołujesz się do zapisanej już zmiennej językowej o poprawnej wartości?

Jesli tak to raczej nie widzę tu problemów - chyba że za każdym razem ładujesz wszystko a jest tego dużo - wówczas pasowało by ewentualnie podzielić dane językowe na części odpowiadające jakimś częściom aplikacji plus jedna częsć "wspólna"... skrajnym przypadkiem było by ładowanie zawsze dwóch plików językowych:
- plik językowy wspólny (z jakimiś ogólnymi tekstami używanymi prawie wszędzie)
- plik językowy akcji/kontrolera (z tekstami używanimi tylko w danym kontrolerze/akcji)

wydaje mi się że to jedyny problem do jakiego można się przyczepić (czyli ładowanie wszystkiego naraz) - jeśli oczywiście tak to robisz (IMG:style_emoticons/default/smile.gif)