Oct 06 2005
return new Work;
Filed under Ogólne by Łukasz Dywicki
No.. siedzę właśnie w nowej pracy. Jest super. Ludzie spoko, szef w porządku – słowem pracować i nie odchodzić. Do nowego miejsca pracy mam nieco ponad 10 minut pieszo, więc odchodzi problem z autobusami (ostatnio tyle czasu potrzebowałem na dojście do przystanku). Pojawił się mały problem, bo straciłem hasło do kompa w domu i jak by nie patrzećjestem uziemiony. Prace nad PSF stoją, a ja kwitnę wieczorami przed telewizorem. Ale nie będzie źle … po reinstalacji systemu pewnie będzie troszkę szybciej działać. W sumie, może w grudniu wezmę laptopa w raty …
Co do PSF naszkicowałem diagramy klas dla filtrów i configów. Ten pierwszy nie różni się niczym od tego, który można zobaczyć w Core J2EE patterns przy custom filter strategy.
Wcześniej zarzucano mi definiowanie na sztywno ścieżek do plików konfiguracyjnych. Wpadłem na pomysł jak to rozwiązać:
<module> <name>JakiśMod</name> <default>JakaśAkcja</default> <config>%PSF_DIR%/Modules/%PSF_MODULE_NAME%/Config.xml</config> </module>Myślę, że rozwiąże to częściowo problem z definiowaniem typu parsera..
Hm… ja jestem staroświecki. Wszyscy rzucili się na xml jak (bez skojarzeń i obrażeń) pies do mięsa. Wolę wszystko trzymać w bazie.
U ciebie jest takie coś, że masz główny plik xml, w którym trzymac info o modułach. Masz odwołanie do configu modułu, który także jest plikiem xml, przez to tracisz cenny czas ładowania skryptu.
IMHO.
pozdrawiam
Hmmm,
Wg danie możliwości definiowania ścieżek do konfigu jest lekko pozbawione sensu – dochodzimy do paranoi IMHO – ciekawe co swoją drogą można by jeszcze wrąbać do konfiga :| – jak dla mnie pomyłka.
wojtek Nie ma przeszkód, można zdefiniować sobie konfiguracje w INI, nie ma też przeszkód, żeby zrobić to poprzez tradycyjną tablicę. XML nie jest za każdym razem parsowany. Po sparsowaniu obiekt konfiguracyjny jest serializowany. Powtórne parsowanie ma miejsce po zmianie configu..
NuLL Chce uniknąć sytuacji, gdzie config będzie ważył 10kb… Z drugiej strony trzeba jakoś rozpoznawać jakiego typu jest plik konfiguracyjny.
Rozpoznawać – rozszerzenie, pierwsza linia, folder w którym się znajduje ? ;-)
Wg mnie dyskusje o dostarczycielu konfigu to dziki pomysł – tak naprawdę na ten temat można by napisać książkę. Widziałem gdzieś coś co oferowało różne stopnie komplicji – zamieniało pliki .ini na .xml i robiło mnóstwo rzeczy. Ja tez osobiście nad tym rozmyślam własnie teraz. Na moim frameworku będzie chodził duży i obciążony system i nie wiem czy robić dla każdej akcji osobny plik czy zapisać w jednym pliku konfig dla wszystkich akcji w danym module. Aplikacja będzie posiadać 3 lub 4 wersje panelu admina dla różnych osób oraz co mnie gryzie łańcuchy akcji tak więc uruchamiając łańcuch będzie trzeba będzie wczytywać konfig dla każdej z nich :| – nie wiem jak to jeszcze rozwiązać, ale napewno nie omieszkam się pochwalić projektem na działającym blogu :)
NuLL obecnie rozpoznaję po rozszeżeniu, ale jeśli config może leżeć w innym miejscu to jak mam odgadnąć jego rozszeżenie? Po kolei sprawdzać file_exists? Przecież takie rozwiązanie nie jest optymalne. Katalog odpada z tego względu, że nie ma po co wrzucać jednego pliku do odrębnego katalogu, bo nie przeszkadza w miejscu w którym jest. A sprawdzanie pierwszych lini – odpada ze względu na konieczność otwarcia pliku za każdym razem…
Tak więc najwygodniejsze jest rozszeżenie, ale skąd je pobierać skoro nie znamy miejsca w którym plik leży. Ponadto plików może być wiele…
Ja tam zostaje przy .xml-u – zreszta po to jest OOP abym mógł podmienić jedną klasę i po bólu :)
Ja tam mam ciekawsze zmartwienia – jak choćby napisać kompilator filtrów ;D
NuLL fakt OOP ma być bardziej elastyczny, ale co to za elastyczność, gdy za każdym razem musisz przedzucać pliki na FTP? Z kolei okaże się, że robisz z kimś projekt i tej drugiej osobie bardziej odpowiada zapis w INI, albo w zwykłej PHPowej tablicy.. Podmienianie plików, to żadna filozofia.
Hermetyzacja zmienności to na pewno nie jest, a przecież jedno z założeń OOP to jest właśnie odseparowanie tych elementów które się zmieniają, tak aby łatwo dodawać nowe i modyfikować istniejące.
Zgadzam się z Tobą w pełni – ale jest gdzieś granica rozsądku. Pozatym napisanie dostarczyciela konfiga w dowolnych formatach to raczej proscizna. Napisanie driverow dla poszczegolnych typow plikow i tyle. Samo configFactory sprawdza rozszerzenie i cheja :) Ale nie wolno też zapominać o ważnej kwestii – stosunku elastyczność/wydajność – m. in. dlatego ja wykorzystuje jedno zródło choć mógłbym wiele.