Chciałbym wszcząć dyskusję o plusach i minusach "XML" - pisze w skrócie "XML", ale rozumiem przez to słowo całą rodzinę technologii z nim związanych.

Plan jest taki:
1. Rezygnujemy z SQL itp.
2. Osoba używająca przeglądarki z procesorem XSL po odwołaniu się do pliku XML zobaczy poprawną stronę XHTML.
3. Zasadniczo pliki XHTML tworzymy na serwerze.
4. php używamy do:
- generowania kodu XHTML
- zarządzania stroną - edycji plików XML, a także XSL i CSS
- rejestrowania użytkowników, dodawania komentarzy.
5. Artykuły z komentarzami (razem) trzymamy w pojedynczych plikach XML. Tworzymy plik XML z metadanymi artykułów.
6. Bazę użytkowników trzymamy w 1 pliku XML.

ZALETY:
1. Strona powinna wyjątkowo szybko i łatwo się generować.
2. Wyjątkowo łatwa ręczna edycja danych.
3. Artykuł reprezentowany jest przez czytelny plik XML, a nie jako rekord w bazie stasunkowo trudny do odczytania, a tym bardziej np. do przeniesienia.
4. Bardzo łatwa przenośność zawartości serwisu.

WADY:
1. Powolna edycja danych - samo dodawanie powinno działać równie szybko.

PYTANIA:
1. Czy za pomocą XSLT np. postronicuję komentarze, bazę użytkowników?

witam ...

do małych stron - tak, jak tylko coś większego to odpada ... system plików nie nadąży za odwołaniami (cache odpada bo pliki się zmieniają - dodawane są komentarze itd) ...

a tego to nie czaje wogóle ... jak jest poprawnie skonstruwoana baza to artykuł (w zasadzie każdy content) jest czytelny ... potrzeba po prostu wprawy i nie wiem o co chodzi z przenośnością ... robisz dump bazy do pliku potem kompresja, upload jednego pliku na serwer i wczytanie go do bazy ... tak chyba łatwiej niż wgrywanie 800 małych plików ...

xml jako technika przechowywania danych nie zmiennych w małych projektach to tak ... ale do większych elementów musi być db ...

pozdrawiam

Myslisz, ze xslt szybciej wygeneruje strone? Mozesz pokazac jakis test? Np. masz plik xml, który ma wagę 100mb i bazę co ma 100mb. Do boju, kto szybciej wybierze dane, a potem je wyświetli ;}



Klient ma sobie recznie zmieniac pliki? :/



Czemu jest trudny do przeczytania rekord w bazie, to poprostu select? Wg. mnie wiecej zachodu jest z xml.. zwlaszcza jak jest duzy to trzeba tworzyc parser do tego.

Jak ktos wyzej napisal - to nie takie pewne

no tak - do tego jak zwykle problemy z ogonkami:)

A w czym plik xml jest czytejniejszy od zwróconego rekordu z bazy?

Jakis przykład? orson dobrze napisał.

uważam, że DEXTER_c ma rację. tworząc witrynę za pomocą XML i XSLT mamy naprawdę dużo możliwości.

jak wiadomo w dla serwisów internetowych waże jest to aby je maksymalnie odciągnąć od pracy - wydajność jest bardzo ważna. w końcu chyba po tworzymy jak najlepsze skrypty i jak najbardziej optymalne, aby chodziły szybko.

a teraz pomyślcie o takiej sytuacji, kiedy całe SMART'y i innego typu rzeczy(np. obsługe bazy danych) mógłby robić użytkownik za pomocą nowoczesnej przeglądarki i bez pomocy serwera - to chyba marzenie każdego kto widzi jak bardzo ma obciążony serwer po dniu ciężkiej pracy ;)


myślę, że to jest bardzo ważna sprawa. trzymając rekordy w plikach XML mamy duże możliwości - chociażby wspomniana "przenośność". bo po pierwsze nie potrzebuje dostępu do bazy danych(i nie jesteśmy zależni od jej wadliwego działania) a po drugie pliki XML są już "obrobionym" materiałem i mamy nieograniczone możliwości w jego edycji po przez tysiące powstałych do tego programów.

witam ...

a co ze skalowaniem co jak serwer nie będzie dawał rady do bazy dodajesz po prostu kolejny serwer i masz duży wzrost wydajności ... dołożenie kolejnego dysku do raida nie da tego samego ...

a co do edycji danych w plikach: ja nie chce takiego cms'a ... jak znajdziesz klienta (_klienta_, nie znaczy programistę tylko kowalskiego który chce zrobić sobie portal modelarski) który będzie ręcznie edytował kontent w plikach xml to znaczy żę możesz sprzedawać biblie diabłu ...

pozdrawiam

A ja teraz, jako statystyczny klient, poproszę o
- 10 najnowszych newsów z kategorii "Modele malowane"
- losowy artykuł na temat gum do żucia
- oraz oczywiście wyszukiwarkę, sprawdzajacą tylko nazwę producenta modeli drewnianych.

No i teraz porównajmy wydajność bazy danych i plików XML...

Dobra - to tyle na wesoło. A na poważnie. Już nie raz omawialiśmy temat prawidłowego wykorzystania XML.
I zgodna opinia zadecydowała, że XML nadaje się świetnie do komunikacji i wysyłania danych. Nie do ich przesyłania.
Jeśli w końcu doczekamy się przeglądarki, która będzie potrafiła w pełni poprawnie generować wyglą stron w oparciu o XML i XSLT to wtedy właśnie okaże się, że XML świetnie będzie nadawał również do przesyłania danych z serwera do przegladarki.
Nie zmienia to jednak faktu, że dane te będą przechowywane w binarnych strukturach baz danych, będa łatwe do obróbki, pobrania i wyszukania.
A potem, jakiś mechanizm, napisany np. w php wygeneruje z nich ładny, kompletny plik XML, który będzie zawierał wszystkie dane niezbędne do wygerowania strony, a i tak bedzie o wiele prostrzy do wygenerowania, i "lżejszy" do transportu, niż gotowy plik XHTML.

Choć akurat to ostatnie nie jest takie pewne, bo przecież czysty XHTML aż tak bardzo od XML'a nie odbiega. A jeśli całość wyglądu strony przeniesie sie do CSS'ów, to on również jest dosyć prosty do wygenerowania, i nie waży zbyt wiele.

oczywiście pliki XML są bardzo użyteczne - ale ja nie mówię o ręcznej edycji. przecież do edycji plików XML można bardzo dobrze wykorzystać tysiące już istniejących klas. co do wyszukiwarki - to chyba XML jest jednym z najlepiej przygotowanych struktur plików nadających się do szybkiego wyszukiwania.


i mam nadzieję, że DEXTER_c mam właśnie w taki sposób "podawać" dane użytkownikowi. ja np. jestem teraz w trakcie pisania takiego serwisu - XML+XSLT+CSS, oczywiście wspierany przez dynamicznie tworzone bazy XML przez php. jest dla mnie ważne, abym mógł bez problemu przenosić bazy danych w XML'u pomiędzy serwerami - i gdzie nie będę potrzebował dostępu do SQL'a.

krótka dyskusja, acz treściwa odbyła się w tym wątku:
http://forum.php.pl/index.php?showtopic=43160
oraz tu:
http://forum.php.pl/index.php?showtopic=12463

hehe, weź pod uwagę jeden fakt: plik xml każdy może przejrzeć, więc nie możesz tam trzymać haseł użytkowników ...

hasła można trzymać w plikach tekstowych -a hasła haszować, pozatym samuch użytkowinkó możemy trzymać w plikach php albo w bazie danych(czyli jednak się przyda )
a dostęp do plików xml np. po przez skrypt można ograniczyć

sposobów wiele, rozwiązań też...

Co to znaczy kazdy? Zabezpieczesz katalogi/pliki tak zeby nik do nich nie mial bezposredniego dostepu -- wszystko edytowane jest tylko CMS'em. A hasla zahashowane mozesz tez trzymac w XMLu (do bazy tez 'kazdy moze zajrzec' jak ma tam konto i dostep do tej bazy).



LOL -- przeciez odchodzilismy od uzywania bazy danych - zaprzeczasz sam sobie

XML jest dobry do niewielkich porcji danych. Pobierasz dane z serwera, konwertujesz do postaci XML i wyswietlasz w przegladarce po wczesniejszej przerobce przez XSLT lub CSS. Tak naprawde XHTML jest poprawnym plikiem XML ze zgory zdefiniowanym DTD. To ze przegladarki dodatkowo formatuja dane kierujac sie rodzajem uzytych tagow wynika z genezy tego formatu i mozna potraktowac to jak wbudowane w engin przegladarek domyslne style XSLT.

Trzymanie danych w plikach XML i operowanie na nich nie jest moim zdaniem dobrym pomyslem. Nie bierzecie pod uwagę nadmiarowych informacji (tagow opisujacych dane) trzymanych w plikach XML. To niepotrzebne marnotrastwo. Poza tym jak to juz bylo tu wielokrotnie poruszane - poslugiwanie sie baza danych i SQLem jest o wiele prostsze.

Co do przenosnosci - mozna przeciez uzyc SQLitea. Dane przechowywane sa w postaci pojedynczego pliku ktory mozna kopiowac z serwera na serwer jak pozostale pliki. Pliku bazy SQLita nie uruchomisz co prawda na kompie bez serwera, ale pliku php tez nie.

Trzeba tworczo wykorzystywac zalety poszczegolnych formatow i wystrzegac sie ich wad dlatego uwazam, ze ograniczanie sie do palety okreslonych technologi np. z rodziny XML tylko i wylacznie z powodow w mniejszym, czy wiekszym stopniu ideologicznych jest glupota.

czy możesz to uzasadnić?

Bo uważam, że jest dokładnie odwrotnie, szczególnie gdy mówimy nie tylko o jednym pliku, a o całym ich zbiorze.

@DeyV może masz rację. źle to określiłem.

chodziło mi o budowę pliku i jego strukturze - przez paser jest łatwo wyciągnąć dane a potem je posegregować. jednak rzeczywiście baza danych jest lepszym sposobem.

ale to także zależy do jakich projektów zastosujemy bazę jak i samego XML. nie ma jednej z góry dobrej ideologii która można się kierować(i tu ukłon w stronę bigZbig, który zwrócił mi uwagę).

nie wiem czy to przeglądaliście:
Wydajny sposób przechowywania danych - tu odbyła się dyskusja w której problemem było przechowywanie danych w plikach XML i/lub w bazie.
oraz w topicu:
Architektura baza... - krzysztof f. dobrze opisał o co mi chodzi. najlepszy sposób opisany transformacji danych wg. mnie to:
baza->php->xml
a następnie:
xml->xslt->html

Dwie rzeczy:

1. XML nie służy do gromadzenia danych i ich późniejszego przeszukiwania, więc NIGDY nie zastąpi relatywnych baz danych. XML słuzy przede wszystkim do wymiany danych, a inne jego zastosowania wynikają głównie z tego, że jest to format tekstowy i to bardzo prosty, bo samoopisujący się, więc czytelny dla człowieka. Takich formatów/języków jest więcej btw..

2. Nikt świadomy tego co robi nigdy nie będzie wysyłał do przeglądarek dokumentów w postaci XML+XSL, bo to rozwiązanie ma jedną dyskwalifikującą go w tej sferze wadę: jest kompletnie bezużyteczne dla przeglądarek nie obsługujących XSL. Trzeba bowiem zauważyć, że świat nie kończy się na IE, Fx, Opera, Konqueror, Safari, czy iCab... Oczywiście nie tyczy się to róznych specjlistycznych aplikacji.


Poza tym potwierdzam to co napisał bigZbig.

Co do przeszukiwania dużych zbiorów danych, napisałem przecież, że konieczne będzie utworzenie specjalnego pliku z metadanymi, bo przeszukiwanie plików z artykułami pojedynczo było by mordercze.

Jak zrobię tego CMS-a, a w styczniu Vista będzie miała IE7 z interpretatorem XSLT to będę wygrany.

Dzięki plikom XML mogę wypuszczać nowe moduły jeszcze przed utworzeniem odpowiedniego modułu w panelu administracyjnym - kto będzie chciał, będzie mógł wykorzystać nowe możliwości edytując pliki XML ręcznie.

Taki CMS na XML będzie musiał być okrojony z zaawansowanych opcji.

Już się zdecydowałem, robię CMS na XML, jak skończę to pogadamy o jego plusach/ minusach, czy wydajności.

Co do bezpieczeństwa. Najtajniejsze pliki XML, które nie mają być dostępne nawet dla tych co mają przeglądarkę z XSLT można chronić na serwerze Linux chyba odpowiednim chmod-em?

Hmm, czy rzeczywiście jest aż tak źle?
- MSIE od dawna obsługuje XSLT, a silnik XML w zależności od zainstalowanej w systemie wesji MSXML jest coraz szybszy
- Mozilla od którejś tam wersji ma chyba dobre wsparcie XSLT i innych technologii około-XML-owych
- Opera 8 też ma procesor XSLT

Tak więc wsparcie jest. Co do kompatybilności, nie może być chyba źle, bo XSLT jest językiem starym i w gruncie rzeczy dosyć prostym.

Z tego co wiem obsługuje, ale nie domyślnie - trzeba doinstalować wtyczkę. Mam złe informacje?

Owszem. IE ma obecnie chyba najlepszy procesor XSL ze wszystkich przeglądarek i to miał go zdaje się jako pierwszy. No i oczywiście nie trzeba nic doinstalowywać.
Mogło Cię zmylić to, że ten procesor można sobie ściągnąć niezależnie od przeglądarki i używać go w swoich programach.

loginy i kodowane hasła można trzymać np. w pliku php zabezpieczonym chociażby die(); i też będzie dobrze. zawsze można stworzyć do pliku dynamiczny parser i dopiero potem przetwarzać całość na XML.


ale nie rozumiem z jakich?

DEXTER_c - ale i tak uważam, że dobrze zrobiłeś i popieram Twój pomysł.