Strony naszych warsztatów: http://www.ncdc.pl/community/szluug/webolution/index.pl.html
Są utrzymywane do tej pory na serwerze NCDC. Chyba już czas najwyższy, żeby przenieść ten content na strony SzLUUGa. :) Pytanie jak to najlepiej zrobić? Właściwie całe warsztaty też można traktować jako osobny projekt, czy raczej dokumentację innego projektu (wątek "hello world dla różnych technologii WWW" :) ). Np. do 4 warsztatów wrzuciłem całkiem sporo contentu o tomcacie, a właściwie warto by wrzucić jeszcze więcej (minimalna webaplikacja). http://www.ncdc.pl/community/szluug/webolution/workshop04.pl.html Coś mi się zaczyna wydawać, że najlepszym sposobem dokumentowania tutaj, było by wiki (zamiast contentu dla konkretnych warsztatów, tylko linki do zagadnień na wiki - np. PHP, ASP.NET, XML, DOM, XSLT, Tomcat, etc.) Oryginalny content stanowią pliki xml w formacie: <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd"; > Format ten łączy cechy docbooka, z funkcjonalnością potrzebną dla web i jest wykorzystywany w celach dokumentacyjnych, przez dużą ilość różnych projektów, szczególnie tych powiązanych z apache.org. BTW, planowane elementy XHTML2.0, upodobnią go bardzo do formatu "document". Możliwe rozwiązania co do przeniesienia contentu "webolution": 1. prostym XSLT przerabiam wszystko na HTML i wklejam do formularza SzLUUGowego CMS. Wady - o ile rozumiem tracę kontrolę wersji. 2. Odrobinę bardziej skomplikowanym XSLT (stopień skomplikowania zależy od tego, czy zastosowany zostanie layout CSS bez tabel) generuję statyczny HTML, który w jakiś sposób zostanie podpięty do obecnych stron (modyfikacje contentu będą wymagać za każdym razem upload, co można zautomatyzować). 3. Na analogicznej zasadzie robię XSLT, który generuje prosty HTML, który z kolei jest włączany jako content przez jakiś PHP include. 4. Użycie transformera XSLT wewnątrz PHP dla każdego pobrania contentu (może to być trochę niepotrzebny overhead, ale zaleta - można by czytać od razu z svn). Moje ogólne refleksje są takie, że typowe systemy CMS przechowujące dane w bazie nie nadają się dobrze dla prowadzenia dokumentacji projektów. Chętnie bym pokazał jak to robimy u nas w firmie. Koncepcja jest mniej więcej taka: Każdy projekt w CVS ma określoną nazwę, którą stanowi część jego URL w intranecie: http://www.ncdc/projects/ncdc-commons-utils/ Projekt musi mieć podkatalog docs. Dokumentacja dla projektu jest pobierana z tej lokalizacji według następującego pseudo-algorytmu: * jeśli istnieje plik index.xml (zgodny z formatem "document" apache'a), to wygeneruj z niego content, jeśli nie istnieje, utwórz content z listingu katalogu docs, przy czym pobierz tytuły dokumentów jako nazwy linków. * do contentu dodaj nawigację wygenerowaną na podstawie aktualnego katalogu (analogicznie jak wyżej - nazwy linków, to tytuły dokumentów). * wyślij to do przeglądarki (jeśli kończy się na .html, to wysłany jest html, jeśli na .pdf, to pdf (bez nawigacji), jeśli .xml, to czysty xml, etc. - można by np. wysyłać pliki openoffice). Analogiczny algorytm działa dla każdego podkatalogu (rekursywnie) z wyjątkiem katalogów "resources" i "images". W ich przypadku zamiast generacji następuje po prostu czytanie zawartości. Kolejny wyjątek, to podkatalog "wiki". Jeśli taki podkatalog jest założony w dowolnym miejscu wewnątrz podkatalogu "docs", to content z niego jest parsowany do xml z tekstowych plików wiki. Przykład dokumentacji projektowych robionych na analogicznej zasadzie: http://forrest.apache.org/ http://forrest.apache.org/index.pdf Chętnie bym się zorientował, jakie są możliwości XSLT w PHP (kiedyś znajomy używał czegoś, co się nazywało sablotron) -- "Meaning is differential not referential" Kazimierz Pogoda Nordic Consulting & Development Company http://www.ncdc.pl/
