🚀 go-pugleaf

LeSio^ <weletek.pococito@poczta.onet.pl> napisał(a): 

> witam.
> mam pytanie, ktore rozwiazanie jest dobre?
> 1. implementacja interfejsu ILocalize we wszystkich klasach chcacych byc 
> lokalizowanymi ( tlumaczonymi na wersje jezykowe ) programu( lacznie z 
> obiektami wizualnymi ) w tym rozwiazaniu karzda klasa musialaby korzystac z 
> jednego trwalego obiektu, ktory mapuje tabele przechowywujaca wersje 
> jezykowe wszystkich stringow programu

i co sie dzieje dalej z takimi klasami? Po co ten wspolny interface?
Poza tym, chcesz zastapic standardowe klasy wlasnymi, "lokalizowalnymi"? 
(czyli LesioString zamiast String, LesioDate zamiast Date itd?)

> 2. tworzenie osobnej klasy np. TTranslator i implementacja metod 
> odpowiedzialnych za lokalizacje wszystkich innych klas? ( to mi sie 
> niebardzo podoba )
> 

troche malo danych ;) 
na razie moge powiedziec, ze nazwa klasy slaba, bo lokalizacja, to 
troche co innego niz translacja. Reszta zalezy od tego jak to mialoby
dzialac. 

> 3. za pomoca tego zamapowanego obiektu mozna wyciagnac z bazy danych 
> okreslony string, czy dobrym rozwiazaniem jest pobieranie z tabeli 
> okreslonego stringa, identyfikujac go poprzez jego tresc, oraz podajac 
> rzadany jezyk wynikowy dla tego stringa?

przez tresc?? jesli chcesz angielska wersje dla stringu "Litwo Ojczyzno moja,
Ty jestes jak zdrowie [ciach 10MB tekstu]", to podasz ten tekst jako argument?
Poza tym dlaczego chcesz trzymac "stringi" w bazie danych?

Jedna uwaga: "lokalizacja" to nie tylko zapewnienie roznych wersji jezykowych 
tekstow pokazywanych na ekranie uzytkownika. To takze odpowiednie formatowanie
dat, kwot itd. 
Proponuje popatrzec jak to zrobili inni. Zobacz np. klasy .net framework
odowiedzialne za "lokalizacje". 





-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Użytkownik "macko42" <macko42.SKASUJ@gazeta.pl> napisał w wiadomości 
news:cugg1k$k1j$1@inews.gazeta.pl...
> i co sie dzieje dalej z takimi klasami? Po co ten wspolny interface?
> Poza tym, chcesz zastapic standardowe klasy wlasnymi, "lokalizowalnymi"?
> (czyli LesioString zamiast String, LesioDate zamiast Date itd?)
wspolny interface, po to by mozna przelaczyc za jednym zamachem wersje 
jezykowa na inna
nie chce niczego zastapic wlasnymi klasami! chcialem implementowac ten 
interfejs w tych klasach ktore cos pisza po ekranie, rzucaja wyjatki itp.

> troche malo danych ;)
> na razie moge powiedziec, ze nazwa klasy slaba, bo lokalizacja, to
> troche co innego niz translacja. Reszta zalezy od tego jak to mialoby
> dzialac.

zgadza sie na wyrost uzylem slowa "lokalizacja"

> przez tresc?? jesli chcesz angielska wersje dla stringu "Litwo Ojczyzno 
> moja,
> Ty jestes jak zdrowie [ciach 10MB tekstu]", to podasz ten tekst jako 
> argument?
zgadza sie, nie jest to zbyt dobre rozwiazanie, dlatego pytam...

> Poza tym dlaczego chcesz trzymac "stringi" w bazie danych?
miedzy innymi dlatego by uzytkownik mogl, sam dodawac, edytowac wersje 
jezykowe programu, takie wymaganie, prosciej wydaje mi sie skorzystac ze 
zrodla danych juz gotowego niz tworzyc go samemu specjalnie na potrzeby 
tlumaczenia?

> Jedna uwaga: "lokalizacja" to nie tylko zapewnienie roznych wersji 
> jezykowych
> tekstow pokazywanych na ekranie uzytkownika. To takze odpowiednie 
> formatowanie
> dat, kwot itd.
zgadza sie

> Proponuje popatrzec jak to zrobili inni. Zobacz np. klasy .net framework
> odowiedzialne za "lokalizacje".
nie mam dostepu do klas .net'owych 

Użytkownik "macko42" <macko42.SKASUJ@gazeta.pl> napisał w wiadomości 
news:cugg1k$k1j$1@inews.gazeta.pl...
> LeSio^ <weletek.pococito@poczta.onet.pl> napisał(a):

> przez tresc?? jesli chcesz angielska wersje dla stringu "Litwo Ojczyzno 
> moja,
> Ty jestes jak zdrowie [ciach 10MB tekstu]", to podasz ten tekst jako 
> argument?
> Poza tym dlaczego chcesz trzymac "stringi" w bazie danych?
dodam jeszcze, ze nie ktore nazwy elementow trzymanych w bazie tez musza byc 
tlumaczone, do tego dochodzi jak wspomnialem mozliwosc dodawania i edycji 
danych slownikowych przez uzytkownika

LeSio^ <weletek.pococito@poczta.onet.pl> napisał(a): 

> Użytkownik "macko42" <macko42.SKASUJ@gazeta.pl> napisał w wiadomości 
> news:cugg1k$k1j$1@inews.gazeta.pl...
> > i co sie dzieje dalej z takimi klasami? Po co ten wspolny interface?
> > Poza tym, chcesz zastapic standardowe klasy wlasnymi, "lokalizowalnymi"?
> > (czyli LesioString zamiast String, LesioDate zamiast Date itd?)
> wspolny interface, po to by mozna przelaczyc za jednym zamachem wersje 
> jezykowa na inna
> nie chce niczego zastapic wlasnymi klasami! chcialem implementowac ten 
> interfejs w tych klasach ktore cos pisza po ekranie, rzucaja wyjatki itp.
> 

w jaki sposob implementowac i po co wspolny interfejs?


> > troche malo danych ;)
> > na razie moge powiedziec, ze nazwa klasy slaba, bo lokalizacja, to
> > troche co innego niz translacja. Reszta zalezy od tego jak to mialoby
> > dzialac.
> 
> zgadza sie na wyrost uzylem slowa "lokalizacja"

czyli chodzi tylko o rozne wersje stringow?

> > przez tresc?? jesli chcesz angielska wersje dla stringu "Litwo Ojczyzno 
> > moja,
> > Ty jestes jak zdrowie [ciach 10MB tekstu]", to podasz ten tekst jako 
> > argument?
> zgadza sie, nie jest to zbyt dobre rozwiazanie, dlatego pytam...

zwykle robi sie to tak, ze kazdy string ma jakies id i przez to
id odwolujesz sie do niego, a odpowiedni obiekt zwraca string w odpowiedniej
wersji jezykowej. 
Naprawde, popatrz na gotowe rozwiazania. 

> > Poza tym dlaczego chcesz trzymac "stringi" w bazie danych?
> miedzy innymi dlatego by uzytkownik mogl, sam dodawac, edytowac wersje 
> jezykowe programu, takie wymaganie, prosciej wydaje mi sie skorzystac ze 
> zrodla danych juz gotowego niz tworzyc go samemu specjalnie na potrzeby 
> tlumaczenia?

baza danych nie jest jedynym zrodlem danych. 
w tym przypadku (o ile nie przewidujesz ogromnych ilosci stringow), 
jest to troche "armata na wroble". Nie wiem w jakim srodowisku programujesz, 
ale czesto sa gotowe mechanizmy. Jak nie ma, to proste rozwiazanie z plikami
txt w wiekszosci przypadkow tez powinno byc ok. 

> > Proponuje popatrzec jak to zrobili inni. Zobacz np. klasy .net framework
> > odowiedzialne za "lokalizacje".
> nie mam dostepu do klas .net'owych 

msdn jest dostepny w internecie, zreszta nie musi byc .net. 
Rozne rozwiazania znajdziesz bez trudu. 


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Użytkownik "macko42" <macko42.SKASUJ@gazeta.pl> napisał w wiadomości 
news:cuhn41$m6m$1@inews.gazeta.pl...
> LeSio^ <weletek.pococito@poczta.onet.pl> napisał(a):
>
>> Użytkownik "macko42" <macko42.SKASUJ@gazeta.pl> napisał w wiadomości
>> news:cugg1k$k1j$1@inews.gazeta.pl...
>> > i co sie dzieje dalej z takimi klasami? Po co ten wspolny interface?
>> > Poza tym, chcesz zastapic standardowe klasy wlasnymi, 
>> > "lokalizowalnymi"?
>> > (czyli LesioString zamiast String, LesioDate zamiast Date itd?)
>> wspolny interface, po to by mozna przelaczyc za jednym zamachem wersje
>> jezykowa na inna
>> nie chce niczego zastapic wlasnymi klasami! chcialem implementowac ten
>> interfejs w tych klasach ktore cos pisza po ekranie, rzucaja wyjatki itp.
>>
>
> w jaki sposob implementowac i po co wspolny interfejs?
implementowac tak,
ITranslated = interface
.GUID.
    procedure Localize( langId :Integer );
end; // cos w tym stylu

TFlangeLogic = class( TLogic, ITranslated  )
    private
        FLangID :Integer;
        translationRes :TResourceString; // zamapowana tabela ze stringami
    public
        procedure Localize( langId :Integer );
end; // podobnie implementowac interfejs dla karzdej z klas ktora cos pisze 
po ekranie, drukarce, rzuca wyjatki itp...

procedure TFlangeLogic.Localize( langId :Integer );
begin
    FLangId := langId;
    // jesli obiekt jest np. widokiem a nie obiektem logiki biznesowej, to 
tutaj
    // mozna by obsluzyc przeladowanie wszystkich potrzebnych stringow
end;

a poto, by moc latwo nie troszczac sie o sposob w jaki to robi konkretna 
klasa, przelaczyc w trakcie dzialania programu wersje jezykowa, poprzez to 
mozna stworzyc tablice przechowujaca liste obiektow implementujaca interfejs 
ITranslated, np translatedObjects :TInterfaceList i dla kazdego w petli 
wykonac Localize, nie przejmujac sie tym jak one to robia? moze zle 
rozwiazania, dlatego pytam
wszystko rozbija sie o to by moc latwo zmieniac wersje jezykowa w trakcie 
dzialania programu

> czyli chodzi tylko o rozne wersje stringow?
dokladnie tak

> zwykle robi sie to tak, ze kazdy string ma jakies id i przez to
> id odwolujesz sie do niego, a odpowiedni obiekt zwraca string w 
> odpowiedniej
> wersji jezykowej.
> Naprawde, popatrz na gotowe rozwiazania.
szukam :), w przytoczonym przykladzie pozyskuje odpowiedni string poprzez ID

> baza danych nie jest jedynym zrodlem danych.
> w tym przypadku (o ile nie przewidujesz ogromnych ilosci stringow),
> jest to troche "armata na wroble". Nie wiem w jakim srodowisku 
> programujesz,
> ale czesto sa gotowe mechanizmy. Jak nie ma, to proste rozwiazanie z 
> plikami
> txt w wiekszosci przypadkow tez powinno byc ok.
zgadza sie, ale poco znow pisac obsluge np. plikow ini badz txt jesli mam 
zamapowana tabele przechowujaca stringi programu, system OR/M obsluguje mi 
wszystkie operacje na tej tabeli i tabelach bedacych z nia w relacji, bardzo 
latwo mozna dac uzytkownikowi mozliwosc manipulacji resourcestring'ami nie 
martwiac sie o odpowiednia obsluge zrodla danych...? pozatym liczba tych 
strongow jest bardzo duza

> msdn jest dostepny w internecie, zreszta nie musi byc .net.
> Rozne rozwiazania znajdziesz bez trudu.
juz szukam 

LeSio^ <weletek.pococito@poczta.onet.pl> napisał(a): 

[...]
> a poto, by moc latwo nie troszczac sie o sposob w jaki to robi konkretna 
> klasa, przelaczyc w trakcie dzialania programu wersje jezykowa, poprzez to 
> mozna stworzyc tablice przechowujaca liste obiektow implementujaca 
interfejs 
> ITranslated, np translatedObjects :TInterfaceList i dla kazdego w petli 
> wykonac Localize, nie przejmujac sie tym jak one to robia? moze zle 
> rozwiazania, dlatego pytam
> wszystko rozbija sie o to by moc latwo zmieniac wersje jezykowa w trakcie 
> dzialania programu

aha. teraz skumalem ;)
IMO w sumie moze tak byc. 
Moze, ewentualnie, sugerowalbym zastosowanie tutaj mechanizmu "event 
source/listeners" (co zreszta sprowadza sie prawie do tego samego). 
Kazdy obiekt, ktory ma byc "lokalizowalny" rejestuje sie jako (przyjmijmy 
jakies nazwy) LocaleChangedListener. 
Uzytkownik zmienia jezyk - ustawiasz go w "LocalizationManagerze",
to powoduje odpalenie odpowiedniej metody na wszystkich LocaleChangedListener.
Dzieki temu masz troche latwiejsze zycie z ta "tabela" (kazdy obiekt sam sie
rejestuje/usuwa). 
LocalizationManager moze miec metode getString(stringID), ktora zwroci
string dla aktualnego jezyka. 
To jest chyba mniej wiecej standardowe rozwiazanie.
 
> > baza danych nie jest jedynym zrodlem danych.
> > w tym przypadku (o ile nie przewidujesz ogromnych ilosci stringow),
> > jest to troche "armata na wroble". Nie wiem w jakim srodowisku 
> > programujesz,
> > ale czesto sa gotowe mechanizmy. Jak nie ma, to proste rozwiazanie z 
> > plikami
> > txt w wiekszosci przypadkow tez powinno byc ok.
> zgadza sie, ale poco znow pisac obsluge np. plikow ini badz txt 

jaka tam obsluge! To sa bardzo proste operacje. 
Zeszta w wiekszosci srodowisk masz to "z pudelka". 
Np ResourceBundle w javie.

jesli mam 
> zamapowana tabele przechowujaca stringi programu, system OR/M obsluguje mi 
> wszystkie operacje na tej tabeli i tabelach bedacych z nia w relacji, 
bardzo 
> latwo mozna dac uzytkownikowi mozliwosc manipulacji resourcestring'ami nie 
> martwiac sie o odpowiednia obsluge zrodla danych...? pozatym liczba tych 
> strongow jest bardzo duza

mam doswiadczenia ze sporymi projektami, gdzie "stringi" byly w plikach txt
i nie bylo problemow wydajnosciowych. 
Nie wiem jak dziala Twoj OR/M, ale krzywilem sie na uzycie tutaj bazy danych 
wlasnie ze wzgledu na wydajnosc. Po co Ci dodatkowy ruch w sieci i obciazanie
bazy danych? Odczytanie stringu to jest prosta operacja i na txt/xml/czymstam
dziala IMO wystarczajaca dobrze. 
Tutaj nie potrzeba ani relacyjnosci, ani transakcji, ani niczego do czego 
bazy danych sa stworzone. Takie jest moje zdanie. 

Milego "lokalizowania" ;)


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> aha. teraz skumalem ;)
> IMO w sumie moze tak byc.
> Moze, ewentualnie, sugerowalbym zastosowanie tutaj mechanizmu "event
> source/listeners" (co zreszta sprowadza sie prawie do tego samego).
> Kazdy obiekt, ktory ma byc "lokalizowalny" rejestruje sie jako (przyjmijmy
> jakies nazwy) LocaleChangedListener.
> Uzytkownik zmienia jezyk - ustawiasz go w "LocalizationManagerze",
> to powoduje odpalenie odpowiedniej metody na wszystkich 
> LocaleChangedListener.
> Dzieki temu masz troche latwiejsze zycie z ta "tabela" (kazdy obiekt sam 
> sie
> rejestuje/usuwa).
> LocalizationManager moze miec metode getString(stringID), ktora zwroci
> string dla aktualnego jezyka.
> To jest chyba mniej wiecej standardowe rozwiazanie.
tak dokladnie chcialem to rozwiazac, w calej aplikacji stosuje wzorzec 
Model-View-Controller wiec praktycznie jest to dosyc latwe do zrealizowania

>> > baza danych nie jest jedynym zrodlem danych.
>> > w tym przypadku (o ile nie przewidujesz ogromnych ilosci stringow),
>> > jest to troche "armata na wroble". Nie wiem w jakim srodowisku
>> > programujesz,
>> > ale czesto sa gotowe mechanizmy. Jak nie ma, to proste rozwiazanie z
>> > plikami
>> > txt w wiekszosci przypadkow tez powinno byc ok.
>> zgadza sie, ale poco znow pisac obsluge np. plikow ini badz txt
>
> jaka tam obsluge! To sa bardzo proste operacje.
> Zeszta w wiekszosci srodowisk masz to "z pudelka".
> Np ResourceBundle w javie.
tak dokladnie w javie jest to z definicji, Delphi ma troszke gorzej

> jesli mam
>> zamapowana tabele przechowujaca stringi programu, system OR/M obsluguje 
>> mi
>> wszystkie operacje na tej tabeli i tabelach bedacych z nia w relacji,
> bardzo
>> latwo mozna dac uzytkownikowi mozliwosc manipulacji resourcestring'ami 
>> nie
>> martwiac sie o odpowiednia obsluge zrodla danych...? pozatym liczba tych
>> strongow jest bardzo duza
>
> mam doswiadczenia ze sporymi projektami, gdzie "stringi" byly w plikach 
> txt
> i nie bylo problemow wydajnosciowych.
> Nie wiem jak dziala Twoj OR/M, ale krzywilem sie na uzycie tutaj bazy 
> danych
> wlasnie ze wzgledu na wydajnosc. Po co Ci dodatkowy ruch w sieci i 
> obciazanie
> bazy danych? Odczytanie stringu to jest prosta operacja i na 
> txt/xml/czymstam
> dziala IMO wystarczajaca dobrze.
> Tutaj nie potrzeba ani relacyjnosci, ani transakcji, ani niczego do czego
> bazy danych sa stworzone. Takie jest moje zdanie.
>
> Milego "lokalizowania" ;)
dzieki 

Użytkownik "LeSio^" <weletek.pococito@poczta.onet.pl> napisał w wiadomości
news:cufrde$7q9$1@atlantis.news.tpi.pl...
> witam.
> mam pytanie, ktore rozwiazanie jest dobre?
> 1. implementacja interfejsu ILocalize we wszystkich klasach chcacych byc
> lokalizowanymi( tlumaczonymi na wersje jezykowe ) programu( lacznie z
> obiektami wizualnymi ) w tym rozwiazaniu karzda klasa musialaby korzystac z
> jednego trwalego obiektu, ktory mapuje tabele przechowywujaca wersje
> jezykowe wszystkich stringow programu
> 2. tworzenie osobnej klasy np. TTranslator i implementacja metod
> odpowiedzialnych za lokalizacje wszystkich innych klas? ( to mi sie
> niebardzo podoba )
>
> dodam iz w calym programie, uzywam OR/M systemu, poprzez ktory mam miedzy
> innymi zamapowane dwie tabele( z ktorych jedna przechowuje wszystkie stringi
> w kombinacji z roznymi wersjami jezykowymi, prosta relacja jeden-do-wielu )
>
> 3. za pomoca tego zamapowanego obiektu mozna wyciagnac z bazy danych
> okreslony string, czy dobrym rozwiazaniem jest pobieranie z tabeli
> okreslonego stringa, identyfikujac go poprzez jego tresc, oraz podajac
> rzadany jezyk wynikowy dla tego stringa?
>
> za sugestie dziekuje
>
> pozdrawiam LeSio^

Sugestie już dostałeś, ja tylko nieco podsumuję ...
Implementacja wspólnego interfejsu w wielu obiektach jest najzwyczajniej w świecie
rozwiązaniem zbyt silnym, nadmiarowym. Daje Ci np. możliwość wybiórczego
"lokalizowania ;)" każdego elementu w systemie z osobna. A tego wcale nie
potrzebujesz. I nawet takie "silne" rozwiązanie można uzyskać prościej - czyli
bez narzucania klasom w systemie dziwnych rzeczy.
Spróbuję pokrótce przedstawić na poziomie koncepcyjnym to, co Ty zaproponowałeś
i porównać to do koncepcji prostszej.

Najpierw model ogólny: mamy mnóstwo takich klas-komóreczek. Te komóreczki
siedzą w większym środowisku, jakim jest system i tworzą większe całości.
Teraz system coś od nich chce - stawia im wymagania. Twoja wizja wyglada mniej
wiecej tak: system narzuca komórkom jak mają wyglądać i dzięki temu umie sobie
z nimi radzić.
Jest to całkiem OK - ale do czasu. Jeśli w system wchodzą nowi więksi gracze
z własnymi pomysłami to wg. tej koncepcji każdy z nich odciska na komóreczce
swoje własne wymagania. Efekt końcowy może być taki, że w system składa
się z samych "jeży", czyli błony wszystkich komórek są naszpikowane różniastym
sprzętem. Poważnie zostaje zachwiana równowaga między ich własną funkcjonalnością
a dodatkowym balastem, który narzucają inne systemy. Innymi słowy: błona komórki
zamiast być jej facjatą (opisywać ją) staje się "przeglądem wszelkich usług systemu".

I dlatego bardzo poważnie trzeba rozważyć inną koncepcję, w której system zaczyna
bardziej myśleć w ten sposób: nie będę moich komóreczek męczył, tylko raczej
postaram się stworzyć im jednolity, scentralizowany interfejs oferowanych usług.
Czyli to system zaczyna sobie narzucać interfejsy a komórki mają z nich korzystać
ew. zgłaszać własne usługi, które system wchłonie i np. wystawi dla innych.
Idealnie nadaje się tu wzorzec singleton, i było to zresztą już wspomniane. Padło
nawet pojęcie "managera lokalizacji". Otóż to - system organizuje usługi dostarczane
przez różne komórki w postaci skupionej przez managery, np. manager uprawnień,
manager
blokad zasobów, manager bazy danych itp. W dalszej kolejności managery funkcji
biznesowych. Takie podejście wymaga też, by komórki w mniejszym stopniu komunikowały
się bezpośrednio między sobą, a skupiły swoją uwagę na tym, co oferują managery.
Można by to porównać do sytuacji, w której każda komórka kupuje sobie telewizorek
i telefon,i korzysta z nich w domowym zaciszu, a na błonie widać to, co sama
oferuje systemowi, a nie to, z czego korzysta.

Przenosząc to na twój grunt: funkcjonalność związana z "lokalizacją ;)" powinna
być skupiona w jednym miejscu, włąśnie w takim ResourceBundlu albo innym managerze,
który będzie udostępniał proste funkcje: podajTekst(id). A komóreczki muszą po prostu
z tego korzystać. Nieco komplikuje sprawę fakt, że chcesz dynamicznie przełączać
lokalizację, a więc system chce mieć jakiś młotek, którym od czasu do czasu puknie
do wybranych komórek i powie: "baczność, flagę zmień !". Ale to jest bardziej
problem tego, że komóreczki mają skłonność do gromadzenia swoich zdobyczy i nie
zauważają, że coś się zmieniło. To jednak można załatwić bez kombinacji "z błoną"
- czyli bez rozbudowywania interfejsów.

In message cuv0j8$139$1@news.onet.pl, Filip Sielimowicz
<sielim@poczta.onet.pl> wrote:
> Sugestie już dostałe¶, ja tylko nieco podsumuję ...

Proszę więcej takich ukierunkowujących wykładów.

Z góry dziękuję
Miroo

Filip Sielimowicz <sielim@poczta.onet.pl> napisał(a): 

> Najpierw model ogólny: mamy mnóstwo takich klas-komóreczek. Te komóreczki
> siedzą w większym środowisku, jakim jest system i tworzą większe całości.
> Teraz system coś od nich chce - stawia im wymagania. Twoja wizja wyglada 
mniej
> wiecej tak: system narzuca komórkom jak mają wyglądać i dzięki temu umie 
sobie
> z nimi radzić.

o ile ja dobrze zrozumialem nasze wczesniejsze rozwazania, to "system" tylko 
informuje komorki, ze cos (jezyk) sie zmienilo. Reszta nalezy 
do "komóreczek". 




-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Użytkownik "macko42" <macko42.SKASUJ@gazeta.pl> napisał w wiadomości
news:cuv8tc$i13$1@inews.gazeta.pl...
> Filip Sielimowicz <sielim@poczta.onet.pl> napisał(a):
>
> > Najpierw model ogólny: mamy mnóstwo takich klas-komóreczek. Te
komóreczki
> > siedzą w większym środowisku, jakim jest system i tworzą większe
całości.
> > Teraz system coś od nich chce - stawia im wymagania. Twoja wizja wyglada
> mniej
> > wiecej tak: system narzuca komórkom jak mają wyglądać i dzięki temu umie
> sobie
> > z nimi radzić.
>
> o ile ja dobrze zrozumialem nasze wczesniejsze rozwazania, to "system"
tylko
> informuje komorki, ze cos (jezyk) sie zmienilo. Reszta nalezy
> do "komóreczek".

No i ja tego nie kwestionuję. Zakwestionowałem jedynie potrzebę
implementowania
interfejsów w "lokalizowanych" elementach, którą pokazał Lesio. Podoba mi
się
podany przez Ciebie pomysł, gdzie klasy rejestrują się w jednym miejscu
(czyli w manadżerze lokalizacji) i w ten sposób system na trwałe nawiazuje
z nimi łączność. Tyle, że myśląc już konkretnie w języku Java, komponenty
niekoniecznie muszą przecież rejestrować dokładnie siebie, ale wystarczy, że
po prostu rejestrują jakiś listener, a ten dopiero implementuje zrozumiały
dla managera interfejs.
Kwestia wyboru jest tu podobna do dylematu: czy jak mamy własne okienko
graficzne (JFrame, JApplet lub coś w tym stylu) to czy implementować
wszelakie EventListenery w klasie tego okienka, czy tworzyć małe listenerki
schowane wewnątrz.
Jeśli przewidujemy, że nasze okno będzie się rozwijać i interfejsów może być
dużo - lepiej wybrać to drugie. Tym bardziej, że w pewnym momencie okaże
się,
że ten sam interfejs wykorzystują do komunikacji różne usługi, a dla każdej
z nich trzeba go implementować inaczej. Przykład: w przypadku problemu
lokalizacji, naciągajac nieco, można wyobrazić to sobie np. tak, że w
systemie pojawiają się dwie różne usługi lokalizacji - jedna standardowa
zdefiniowana
jak wcześniej i obowiązująca w całym systemie i druga dotycząca specyficznej
grupy komponentów przy zachodzących specyficznych warunkach dodatkowych,
np. jakieś raporty są wysyłane za granicę i ich kopia ma trafiać tam
z nagłówkami i opisami kolumn w innym języku, niż lokalnie (ale tylko
nagłówki
i opisy kolumn). Jeśli nie chcemy pchać do komórek logiki sprawdzającej
warunki
- o jaki rodzaj lokalizacji chodzi - po prostu definiujemy w systemie dwie
różne usługi i te raporty podpinają się umiejętnie do obu, nie zajmujac się
ich powiązaniami i zależnościami - po prostu reagują na żądania zmiany
lokalizacji zgodnie z tym, gdzie jakie poszczególne kontrolki zostały
podpięte
i tyle. Gdzie indziej leżą decyzje, jak to ze sobą zgrać i czy w ogóle
będzie
wykorzystywane.

--
Filip Sielimowicz
http://panda.bg.univ.gda.pl/~sielim/genetic/index.htm

Użytkownik "Filip Sielimowicz" <sielim@poczta.onet.pl> napisał w wiadomości 
news:cv0hqv$o9g$1@news.onet.pl...
>
> Użytkownik "macko42" <macko42.SKASUJ@gazeta.pl> napisał w wiadomości
> news:cuv8tc$i13$1@inews.gazeta.pl...
>> Filip Sielimowicz <sielim@poczta.onet.pl> napisał(a):
>>
>> > Najpierw model ogólny: mamy mnóstwo takich klas-komóreczek. Te
> komóreczki
>> > siedzą w większym środowisku, jakim jest system i tworzą większe
> całości.
>> > Teraz system coś od nich chce - stawia im wymagania. Twoja wizja 
>> > wyglada
>> mniej
>> > wiecej tak: system narzuca komórkom jak mają wyglądać i dzięki temu 
>> > umie
>> sobie
>> > z nimi radzić.
>>
>> o ile ja dobrze zrozumialem nasze wczesniejsze rozwazania, to "system"
> tylko
>> informuje komorki, ze cos (jezyk) sie zmienilo. Reszta nalezy
>> do "komóreczek".
>
> No i ja tego nie kwestionuję. Zakwestionowałem jedynie potrzebę
> implementowania
> interfejsów w "lokalizowanych" elementach, którą pokazał Lesio. Podoba mi
> się
> podany przez Ciebie pomysł, gdzie klasy rejestrują się w jednym miejscu
> (czyli w manadżerze lokalizacji) i w ten sposób system na trwałe nawiazuje
> z nimi łączność.
no dokladnie w ta strone chcialem zmierzac, chcialem stworzyc cos na 
kształt:
klasy TTranslator, kotra bedzie scentralizowanym managerem wersji 
jezykowych, i zarazem bedzie udostepniala proste metody
getText( id ); bedzie rowniez mogla przypiac do siebie listenerow( lub moze 
obserwatorow ) ktorzy to maja w TYM MIEJSCU waski interfejs ITranslated 
zawierajacy jedynie metode Translate( idJezyka ); w ten sposob mysle przez 
jedno machniecie moge zmienic w locie jezyk na inny... jednak do tego 
potrzebuje wydaje mi sie  zaimplementowac interfejs ITranslated w karzdej 
klasie ktora cos pisze? by zkolei TTranslator mogl poprostu przeiterowac 
kolekcje zarejestrowanych "obserwatorow" i "klepnac mloteczkiem - zmieniam 
flage"?

LeSio^ 

In message cv4vkk$eni$1@atlantis.news.tpi.pl, LeSio^
<weletek.pococito@poczta.onet.pl> wrote:
> klasy TTranslator, kotra bedzie scentralizowanym managerem wersji
> jezykowych, i zarazem bedzie udostepniala proste metody
> getText( id ); bedzie rowniez mogla przypiac do siebie listenerow(
> lub moze obserwatorow ) ktorzy to maja w TYM MIEJSCU waski interfejs
> ITranslated zawierajacy jedynie metode Translate( idJezyka ); w ten
> sposob mysle przez jedno machniecie moge zmienic w locie jezyk na
> inny... jednak do tego potrzebuje wydaje mi sie  zaimplementowac

Czy zamierzasz w każdej klasie przechowywać lokalnie
tekst odebrany od TTranslator czy za każdym razem
dynamicznie wywoływać getTekst(id)?
Bo jeśli to drugie, to nie wiem po co ci metoda translate?
Wystarczy ogólna metoda typu Refresh, nie ograniczona tylko do
odświeżenia napisów w danym języku, ale bardziej uniwersalna.
Nie musiałbyś wtedy dodawać wąskiego i wąskospecjalizowanego
interfejsu ITranslated.

Pozdrawiam
Miroo