On Tue, 28 Dec 2010 13:36:24 -0000, Borys Pogoreło <b...@p...edu.leszno>
wrote:

>>> a) musimy i tak zduplikować bazę
>>
>> Nie. Dodać kolumnę na datę/wersję.
>
> A jeśli w międzyczasie zmienia się struktura bazy?

To migrujesz stare dane. Jeśli stare pola przestają mieć sens w nowym
układzie, to w nowych rzędach wstawiasz NULLe.

Archiwalna wersja strony to nie musi być archiwum *implementacji*, nie?

>> Nie od razu. Nowe pliki dodawaj pod nową nazwą, jeżeli konieczne jest
>> zachowanie wyglądu starej strony.
>
> A jeśli zawartość plików się zmienia, a nazwy pozostają?

No to tak nie rób. Zasada "nowa zawartość = nowy URL" przy okazji ułatwia
długie cache'owanie plików.

>>> c) musimy stworzyć nowe pliki klas
>>
>> WTFBBQ? Nie możesz nowej funkcjonalności dodawać tak, aby była
>> "kompatybilna wstecz"?
>
> Nie wszystko da się tak dodać.

OK, ale to raczej w przypadkach ciężkich przeróbek, a wtedy to nie jest
głupia robota z copy&paste klasy, a utrzymywanie dwóch kompletnie różnych
rzeczy (czego nie da się uniknąć, jeżeli utrzymywanie dwóch wersji jest
dokładnie twoim celem).

>> Poza tym w OOP wymyślono pare rzeczy, które mają zastąpić copy&paste...
>
> A ja znów przypominam, że nie ma ani słowa o OOP w pierwszym poście :)
> Zaś w PHP zbyt wielu z tych rzeczy nie ma...

Czego takiego brak, co by tu ułatwiło?

--
http://pornel.net
this.author = new Geek("porneL");

do góry

Dnia Tue, 28 Dec 2010 14:15:33 -0000, porneL napisał(a):

> Archiwalna wersja strony to nie musi być archiwum *implementacji*, nie?

Oczywiście, że nie. Ale nie wiemy jakie wymagania ma "góra". Jeśli serwis
ma wyglądać i zachowywać się dokładnie tak, jak w określonym roku, to
programista osiwieje od liczby ifów.

>> A jeśli zawartość plików się zmienia, a nazwy pozostają?
>
> No to tak nie rób. Zasada "nowa zawartość = nowy URL" przy okazji ułatwia
> długie cache'owanie plików.

To nie ja tak robię ;) Tylko wymyślam problemy, które się mogą pojawić.
Niemniej jeśli linki do plików były wstawiane jakimś wyswigiem, to zapewne
nie ma żadnego pośrednika - zawartość pliku się zmienia, url pozostaje.

> OK, ale to raczej w przypadkach ciężkich przeróbek, a wtedy to nie jest
> głupia robota z copy&paste klasy, a utrzymywanie dwóch kompletnie różnych
> rzeczy (czego nie da się uniknąć, jeżeli utrzymywanie dwóch wersji jest
> dokładnie twoim celem).

Dlatego ja bym to zwyczajnie skopiował, zamiast rzeźbić w g* :-)

Przypuszczam, że na "genialny" pomysł zachowania "migawek" ktoś wpadł już
dawno po uruchomieniu tego systemu. A taka funkcjonalność powinna być
wpleciona w jego strukturę od samego początku.

>>> Poza tym w OOP wymyślono pare rzeczy, które mają zastąpić copy&paste...
>>
>> A ja znów przypominam, że nie ma ani słowa o OOP w pierwszym poście :)
>> Zaś w PHP zbyt wielu z tych rzeczy nie ma...
>
> Czego takiego brak, co by tu ułatwiło?

W tym konkretnym przypadku za mało danych by to stwierdzić.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 2010-12-28 09:24, beherit / pn pisze:

> Szybkie i proste:
> - klasa dziedzicząca po tej, która obsługuje Ci stronę,
> - podmiana nazw tabeli gdy podany ?year=2007 z moj_content na
> moj_content_2007. Cała filozofia.. Pliki analogicznie.

Czyli content_2007, content_2008... to kolejne kopie bazy danych z
poszczególnych lat?

Problem jest np. z archiwizowaniem funkcjonalności. Jeśli przykładowo
jakaś formatka określa, że po lewej mamy treść, a po prawej newsy a w
kolejnym roku ma być odwrotnie (czyli nastąpiła zmiana w kodzie HTML
formatki), to takie przełączenie źródła danych nie wystarczy.

Teraz sam sobie odpowiadam. Pewnie nie da się archiwizować za pomocą
"guzika". Kopia bazy + kopia HTML = niezależny serwis WWW. Obawiam się,
że to jedyna droga. Muszę to uzgodnić z klientem aby wiedzieć co
faktycznie archiwizacja oznacza.

do góry

W dniu 2010-12-29 00:41, Marek pisze:
> W dniu 2010-12-28 09:24, beherit / pn pisze:
>
>> Szybkie i proste:
>> - klasa dziedzicząca po tej, która obsługuje Ci stronę,
>> - podmiana nazw tabeli gdy podany ?year=2007 z moj_content na
>> moj_content_2007. Cała filozofia.. Pliki analogicznie.
>
> Czyli content_2007, content_2008... to kolejne kopie bazy danych z
> poszczególnych lat?
>
> Problem jest np. z archiwizowaniem funkcjonalności. Jeśli przykładowo
> jakaś formatka określa, że po lewej mamy treść, a po prawej newsy a w
> kolejnym roku ma być odwrotnie (czyli nastąpiła zmiana w kodzie HTML
> formatki), to takie przełączenie źródła danych nie wystarczy.
>
> Teraz sam sobie odpowiadam. Pewnie nie da się archiwizować za pomocą
> "guzika". Kopia bazy + kopia HTML = niezależny serwis WWW. Obawiam się,
> że to jedyna droga. Muszę to uzgodnić z klientem aby wiedzieć co
> faktycznie archiwizacja oznacza.

Oczywiście, że się da, a czemu nie. Ograniczyłbym jedynie zmiany w
strukturze kodu szablonów i ogólnie logiki aplikacji obsługującej serwis.
Click
-> twórz nowe tabele (lub jak zaproponował porneL -> automatem data,
wersja)
-> twórz kopie plików (jeśli musisz dla danego roku) np.
index.2009.tpl
a później wszystko sobie wywoływać choćby nawet z użyciem SESSION jak
bardzo chcesz
if($_SESSION['year']=2009)
wyswietl komunikat, ze oglada archiwum
+ dane pobierz z tabeli _2009 lub z content.year = 2009
+ zaciągnij do wyswietlenie index.2009.tpl
else
wyswietl aktualne

ba... tutaj nie trzeba nic klikac, pelna automatyzacja jest prosta i
mozliwa :).

Pozdr,p.

do góry

W dniu 2010-12-31 08:49, beherit / pn pisze:
> -> twórz kopie plików (jeśli musisz dla danego roku) np.
> index.2009.tpl

Chyba lepiej by było do katalogu 2009 etc. wrzucać te pliki i nie
zmieniać nazw, wtedy wystarczy ustawić inną ścieżkę w konfiguracji
szablonów, a tak musi jeszcze edytować wszystkie includy i dodać rok w
ścieżkach.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

On Fri, 07 Jan 2011 12:55:02 -0000, Marek <b...@e...com> wrote:

> Nowe tabele czy nowe rekordy? Pornel wspominał o dodaniu nowej kolumny
> oznaczającej wersję a nie nowej tabeli. No i tu problem bo tabel jest
> 100 i dotyczą przeróżnych aspektów. Dokumenty to tylko parę z tych tabel
> (dokument, strona dokumentu, pliki i obrazki, kategorie i jeszcze parę
> innych) a nie tylko dokumenty mają być archiwizowane - również
> funkcjonalność, która częściowo jest określona w innych tabelach a
> częściowo w formatkach. Nad formatkami zapanujemy poprzez ich
> skopiowanie do innego/innych katalogów 2009, 2010 itd. Nad dokumentami
> możemy zapanować tak jak Pornel sugerował. Pozostaje kwestia wszelkich
> konfiguracji w bazie. Załóżmy najprostszy przypadek: definicję jakiegoś
> menu. Jak z tego wersję archiwalną stworzyć bez kopiowania bazy lub
> tworzenia nowego "schematu"?

Zakładam, że to menu w bazie jest w postaci jakiegoś drzewka. Przerób:

menu
- podmenu
- podmenu
- podmenu

na:

2009
- menu
-- podmenu
-- podmenu
-- podmenu

2010
- menu
-- podmenu
-- podmenu
-- podmenu

i pobieraj odpowiedni korzeń w zależności od roku.

Albo utrzymuj jedno menu, tylko do każdego elementu dodaj daty "od" "do",
które określają kiedy element ma być wyświetlany, względem daty strony, na
której jest.

--
http://pornel.net
this.author = new Geek("porneL");

do góry

W dniu 2010-12-31 15:18, Paweł Piskorz pisze:

> Chyba lepiej by było do katalogu 2009 etc. wrzucać te pliki i nie
> zmieniać nazw, wtedy wystarczy ustawić inną ścieżkę w konfiguracji
> szablonów, a tak musi jeszcze edytować wszystkie includy i dodać rok w
> ścieżkach.


Jest z tym pewien kłopot tak czy owak. Zobrazuję to na przykładzie.
Jeśli np. formatka od wyszukiwarki miała zdefiniowaną funkcjonalność
ograniczającą przeszukiwanie do kategorii dokumenty/2009 i powstaje nowa
wersja serwisu, to należy w niej i tak ręcznie zbudować nową formatkę,
dla której ograniczeniem będzie kategoria dokumenty/2010. Drobna zmiana
ale jednak zmiana...

Po drugie: od strony bazy też istnieje ograniczenie. Załóżmy, że mamy
zdefiniowane menu u góry strony i po lewej stronie inne. Ma ono w bazie
identyfikator ver2009. W roku 2010 powstaje nowa wersja menu (jakieś
nowe opcje, albo eliminacja niektórych poprzednich). Jeśli nazwiemy je
ver2010 to dopóki nie poinformujemy o tym fakcie formatki z bieżącego
roku, to będzie ona wyświetlała poprzednie menu - a więc zmiana formatki
nas czeka. Zwróć uwagę, że w ten sposób powstaje również problem od
strony redakcyjnej. Wszelkie systemy menu należy sklonować. Po N latach
powstaje ich N dla góry i N dla lewej strony. Tworzy się z tego niezły
gąszcz. Zwykłe klonowanie bazy i serwisu WWW z usuwaniem sekcji
redakcyjnej z lat archiwalnych chyba jest prostsze. Jak sądzisz?

--
Pozdrawiam,
Marek

do góry

W dniu 2010-12-31 08:49, beherit / pn pisze:

> Oczywiście, że się da, a czemu nie. Ograniczyłbym jedynie zmiany w
> strukturze kodu szablonów i ogólnie logiki aplikacji obsługującej serwis.
> Click
> -> twórz nowe tabele (lub jak zaproponował porneL -> automatem data,
> wersja)

Nowe tabele czy nowe rekordy? Pornel wspominał o dodaniu nowej kolumny
oznaczającej wersję a nie nowej tabeli. No i tu problem bo tabel jest
100 i dotyczą przeróżnych aspektów. Dokumenty to tylko parę z tych tabel
(dokument, strona dokumentu, pliki i obrazki, kategorie i jeszcze parę
innych) a nie tylko dokumenty mają być archiwizowane - również
funkcjonalność, która częściowo jest określona w innych tabelach a
częściowo w formatkach. Nad formatkami zapanujemy poprzez ich
skopiowanie do innego/innych katalogów 2009, 2010 itd. Nad dokumentami
możemy zapanować tak jak Pornel sugerował. Pozostaje kwestia wszelkich
konfiguracji w bazie. Załóżmy najprostszy przypadek: definicję jakiegoś
menu. Jak z tego wersję archiwalną stworzyć bez kopiowania bazy lub
tworzenia nowego "schematu"? (wyjaśnię, że chodzi tu o funkcjonalność
Postgresa - coś w rodzaju przestrzeni nazw, między którymi możemy
przełączać się). Trzeba przy okazji pamiętać, że każdem menu posiada
unikalny identyfikator, którego używamy w formatce. Tak więc formatka
archiwalna z 2009r będzie wskazywała na menu o ID np. ver2009 a ta sama
formatka z roku 2010 musi zostać przerobiona aby wskazywać na inne menu
o ID ver2010, które trzeba sklonować z wersji 2009. Tak więc przy takim
wariancie kliknięcie guzika wydaje się być troszkę nie wystarczające.
Czy mylę się?

> a później wszystko sobie wywoływać choćby nawet z użyciem SESSION jak
> bardzo chcesz
> if($_SESSION['year']=2009)

To przełączanie jest jasne. Niejasne dla mnie jest póki co robienie
archiwum z funkcjonalności j/w.


--
Pozdrawiam,
Marek

do góry

W dniu 2011-01-07 13:19, porneL pisze:
> menu
> - podmenu
> - podmenu
> - podmenu
>
> na:
>
> 2009
> - menu
> -- podmenu
> -- podmenu
> -- podmenu
>
> 2010
> - menu
> -- podmenu
> -- podmenu
> -- podmenu

No właśnie o tym wariancie wspominałem. Każdy rok, to nowe menu/podmenu
= praca dla redaktora w celu utworzenia nowego menu + praca dla
webmastera w celu modyfikacji formatek aby wiedziały, że mają brać pod
uwagę podmenu 2010, a w archiwum z 2009 - menu "2009", a we
wcześniejszym archiwum - "2008" itd. Nie jest to więc "kliknięcie" lecz
ciąg zdarzeń.

To samo dotyczyłoby innych sekcji serwisu: bannery, kalendarze itd. To
dość rozbudowane przedsięwzięcie. Wydaje mi się, że w tym konkretnym
przypadku gdzie archiwizacja będzie coroczna, dam sobie spokój i ręcznie
będę kopiował pliki, bazę i zakładał poddomenę/podkatalog. Raz na rok
nie spocę się od tego :-) W tym momencie zyskamy to, że redaktor niczego
nie będzie musiał zmieniać - dostanie wypełniony serwis a kopie
archiwalne będą bez części redakcyjnej.

--
Pozdrawiam,
Marek

do góry

On Fri, 07 Jan 2011 15:29:47 -0000, Marek <b...@e...com> wrote:

>> menu
>> - podmenu
>> - podmenu
>> - podmenu
>>
>> na:
>>
>> 2009
>> - menu
>> -- podmenu
>> -- podmenu
>> -- podmenu
>>
>> 2010
>> - menu
>> -- podmenu
>> -- podmenu
>> -- podmenu
>
> No właśnie o tym wariancie wspominałem. Każdy rok, to nowe menu/podmenu
> = praca dla redaktora w celu utworzenia nowego menu

Etam, raz na rok odpalasz:

dodaj_menu($rok, wczytaj_menu($rok-1));

(crontab chyba nie obsługuje zdarzeń rocznych :)

> + praca dla webmastera w celu modyfikacji formatek aby wiedziały, że
> mają brać pod uwagę podmenu 2010, a w archiwum z 2009 - menu "2009"

Napisz je raz, żeby używały pokaz_menu($ta_strona->jej_rok());


Chociaż ja dalej nie czaję, dlaczego ważna jest archiwizacja wszystkiego
idealnie co do buga, zamiast pozwolić stronie ewoluować zachowując dostęp
do poprzednich danych.

Może jak ma być idealnie-nietykalnie zamrożone jak dowody sądowe, to
zapuść wget -m?

--
http://pornel.net
this.author = new Geek("porneL");

do góry