🚀 go-pugleaf

>Mianowicie mowi sie czesto o XML-u w kontekscie porownan z
> HTML i jego zastosowaniu w tworzeniu stron WWW. Staralem sie znalezc jakis
> konkretny przyklad takiego zastosowania ale jak na razie bez rezultatow.

Jezeli masz IE 5.0 albo 5.5, to zobacz:
http://www.bayes.co.uk/xml/index.xml

Pozdrawiam,

Krzysiek

On Wed, 11 Oct 2000 14:37:17 +0200, Piotr Białasz wrote:
>Witam grupowiczów.
>Zaczynam swoja przygode z XML-em i co nieco o nim juz wiem. Frapuje mnie
>jedna kwestia. Mianowicie mowi sie czesto o XML-u w kontekscie porownan z
>HTML i jego zastosowaniu w tworzeniu stron WWW. Staralem sie znalezc jakis
>konkretny przyklad takiego zastosowania ale jak na razie bez rezultatow.
>Owszem znalazlem kod stron stworzonych na potrzeby WAP i wiem, ze tam XML
>znajduje juz zastosowanie. A co z WWW? Czy jest to zbyt nowa technologia ze
>jeszcze nie stosowana, czy nie do konca rozumiem idee i XML nie ma sluzyc do
>tworzenia stron zamiast HTML-a.
>Prosze o rozwianie moich watpliwosci i jesli istnieja strony napisane w
>XML-u to naprowadzcie mnie.

Mając składowany w specjalizowanej bazie XML jako backend serwisu WWW możesz
używając XSL konwertować go do dowolnego (X)HTML, WML, PDF i czego tam jeszcze
potrzebujesz, przy użyciu jednego polecenia. Globalne zmiany wyglądu serwisu to
kwestia jakichś poprawek w arkuszu XSL(T), a równicześnie masz do dyspozycji
całą funkcjonalność jaką daje XML (przetwarzanie treści oparte na jej
strukturze). Niektóre browsery już teraz zresztą obsługują XML+CSS, nie trzeba
konwertować.

>Pozdrawiam PB

-- 
Grzegorz Staniak <gstaniak@zagiel.pl>

Ponieważ mnie ostatnio nurtuje to samo co kolegę Piotra, to i ja dopytam się:

Grzegorz Staniak wrote:
> 
> Mając składowany w specjalizowanej bazie XML jako backend serwisu WWW

Co to znaczy 'specjalizowana baza XML'?
Jak się ma XML do typowych baz danych (SQL?)?
Dokumenty XML są przecież zapisane "na sztywno", w statycznych plikach
tekstowych. A dzisiejsze serwisy WWW są tak dynamiczne, że aż prosi się
o trzymanie wszystkiego co się da (treści: danych, czasem nawet tekstów)
w bazach danych.

> możesz używając XSL konwertować go do dowolnego (X)HTML, WML, PDF i czego
> tam jeszcze potrzebujesz, przy użyciu jednego polecenia.

No, aby treści zawarte w dokumencie XML przekonwertować na HTML, musisz
stworzyć specjalny XSL. Zeby do WML, kolejny XSL. Tak samo z PDF.
Razem - cztery pliki. Trzymając treści w jakiejś bazie, musisz zrobić
tylko trzy interfejsy...

Nie wiem, jestem dopiero lajkonikiem w sprawiach związanych z XML.

Ale staram się trzeźwo mysleć i np. do teraz zastanawiam się, do czego
tak naprawdę został użyty XML w serwisie http://www.chopin.pl/index.xml
Przecież ktoś to wpierw musiał zrobić w HTML, potem oddzielić
treść od stylu do .xml i .xsl potem jeszcze dodać obsługę
jakiejś bazy danych (?) i wszystko po to, żeby Cocoon spowrotem
skleil wszystko do htmla.

PS. czy ma ktoś podejrzenia jaką funkcję wykonują te parametry z którymi
wywoływane są tamte strony .xml?

-- 
Tomek

"Tomasz Nowak" <tnowak@tux.pl> wrote:
> Co to znaczy 'specjalizowana baza XML'?
> Jak się ma XML do typowych baz danych (SQL?)?

Nienajlepiej.
Najlepszymi bazami do "trzymania" informacji XML-owatej sa
bazu obiektowe.

> Dokumenty XML są przecież zapisane "na sztywno", w statycznych plikach
> tekstowych.

Alez niekoniecznie tak musi byc.
Moga byc spokojnie generowane "w locie" na podstawie calkiem
nie XML-owych danych.
XML powienien byc interfejsem do danych a dane moga byc
trzymane i uzyskiwane 'skolka ugodna'.

A dzisiejsze serwisy WWW są tak dynamiczne, że aż prosi się
> o trzymanie wszystkiego co się da (treści: danych, czasem nawet tekstów)
> w bazach danych.

I tak sie robi.
Tamino jest tu chyba jakims przykladem chociaz nie znam go
zupelnie z praktyki ale tylko ze "slyszenia".

> > możesz używając XSL konwertować go do dowolnego (X)HTML, WML,
> > PDF i czego tam jeszcze potrzebujesz, przy użyciu jednego polecenia.
>
> No, aby treści zawarte w dokumencie XML przekonwertować na HTML,
> musisz stworzyć specjalny XSL. Zeby do WML, kolejny XSL.
> Tak samo z PDF.
> Razem - cztery pliki. Trzymając treści w jakiejś bazie, musisz zrobić
> tylko trzy interfejsy...

Ale wlasnie o to chodzi. Robisz _tylko_ interfejsy
Dane zostaja zawsze te same i nie trzeba ich duplikowac
tyle razy ile roznych formatow.
Poza tym jesli przegladarki sa XML-friendly
czesc (lub wszytskie) rzeczy mozna rowniez zrobic po
stronie klienta posylajac mu XML i XSL osobno
lub nawet slac jedynei XML a do decyzji "klienta"
pozostawic co sobie z tym XML-em zrobi, czy
i ktorego (moze i nawet wlasnego, neiznanego
"serwerowi") XSL-a do tego uzyje.
I ja wlasnei tu widze najbardziej prawidlowe
wykorzystanie XML a nie po stronie serwera.
Przegladarka dostaje osobno dane i interface
i to ona decyduje co dalej z tym poczac majac
jednoczesnie pelna nieskazona konwersjami
czysta informacje (z pelnym dostepem do
kazdego jej  miejsca , mozliwoscia analizy,
 modyfikacji, decyzji) a nie tylko kolejny
"produkt finalny" jak w przypadku konwersji
po stronie serwera.

> Nie wiem, jestem dopiero lajkonikiem w sprawiach
> związanych z XML.

Ja tez . Dlatego jesli cos namotalem, poprawcie lub
uscislijcie prosze

--
Adam Karpierz
karpierz@alpha.pl

On Wed, 11 Oct 2000 18:55:08 +0200, Tomasz Nowak <tnowak@tux.pl> wrote:

>Dokumenty XML są przecież zapisane "na sztywno", w statycznych plikach
>tekstowych. A dzisiejsze serwisy WWW są tak dynamiczne, że aż prosi się
>o trzymanie wszystkiego co się da (treści: danych, czasem nawet tekstów)
>w bazach danych.

Wydaje Ci się, że są "tak dynamiczne" :-)

>> możesz używając XSL konwertować go do dowolnego (X)HTML, WML, PDF i czego
>> tam jeszcze potrzebujesz, przy użyciu jednego polecenia.
>
>No, aby treści zawarte w dokumencie XML przekonwertować na HTML, musisz
>stworzyć specjalny XSL. Zeby do WML, kolejny XSL. Tak samo z PDF.
>Razem - cztery pliki. Trzymając treści w jakiejś bazie, musisz zrobić
>tylko trzy interfejsy...
>
>Nie wiem, jestem dopiero lajkonikiem w sprawiach związanych z XML.

Liczba plików naprawdę nie jest tutaj dobrym wskaźnikiem...

>Ale staram się trzeźwo mysleć i np. do teraz zastanawiam się, do czego
>tak naprawdę został użyty XML w serwisie http://www.chopin.pl/index.xml
>Przecież ktoś to wpierw musiał zrobić w HTML, potem oddzielić
>treść od stylu do .xml i .xsl potem jeszcze dodać obsługę
>jakiejś bazy danych (?) i wszystko po to, żeby Cocoon spowrotem
>skleil wszystko do htmla.
>
>PS. czy ma ktoś podejrzenia jaką funkcję wykonują te parametry z którymi
>wywoływane są tamte strony .xml?

To jest ciekawe. I chore.

Marcin Jagodzinski
(or compatible)

Adam Karpierz wrote:
> 
> Alez niekoniecznie tak musi byc.
> Moga byc spokojnie generowane "w locie" na podstawie calkiem
> nie XML-owych danych.
> XML powienien byc interfejsem do danych a dane moga byc
> trzymane i uzyskiwane 'skolka ugodna'.

A mogłby mnie ktoś obdarzyć jakimś przykładem na to?
Powiedzmy, że mialby to być prosty dokument zawierający
dane o pacjencie pacjent.xml, np:

<pacjent>
  <id>0001</id>
  <imie>Jan</imie>
  <nazwisko>Kowalski</nazwisko>  
</pacjent>

i teraz mamy bazę SQL "szpital", tabele "pacjentci" gdzie każdy
pacjent ma swój rekord. I jak wygenerować taki pacjent.xml?id=0002 ?

To jest pytanie nr 1.

Pytanie #2:
A może lepiej trzymac to nie w bazie, a w samym pliku xml? tj:

<pacjent>
  <id>0001</id>
  <imie>Jan</imie>
  <nazwisko>Kowalski</nazwisko>
</pacjent>
<pacjent>
  <id>0002</id>
  <imie>Henryk</imie>
  <nazwisko>Wiśniewski</nazwisko>
</pacjent>
itd...

hm?

> A dzisiejsze serwisy WWW są tak dynamiczne, że aż prosi się
> > o trzymanie wszystkiego co się da (treści: danych, czasem nawet tekstów)
> > w bazach danych.
> 
> I tak sie robi.

To po co w końcu jest ten cały XML! :-)

> > > możesz używając XSL konwertować go do dowolnego (X)HTML, WML,
> > > PDF i czego tam jeszcze potrzebujesz, przy użyciu jednego polecenia.
> >
> > No, aby treści zawarte w dokumencie XML przekonwertować na HTML,
> > musisz stworzyć specjalny XSL. Zeby do WML, kolejny XSL.
> > Tak samo z PDF.
> > Razem - cztery pliki. Trzymając treści w jakiejś bazie, musisz zrobić
> > tylko trzy interfejsy...
> 
> Ale wlasnie o to chodzi. Robisz _tylko_ interfejsy

Ale ja mówie o intefacach do bazy danych, a nie do dokumentu XML!

> Dane zostaja zawsze te same i nie trzeba ich duplikowac
> tyle razy ile roznych formatow.

No dobra teraz napisze coś co mi nawet cięzko sformuować. Ale spróbuje.
Obecny popularnie stosowana jest metoda mniej więcej taka:
1. TREŚĆ (jako taka) trzymana jest w bazie danych. jest ona niezależna
   zarówno od logiki dokumentu, jak i jego formatu.
2. za LOGIKĘ dokumentu odpowiada html.
3. za FORMAT - arkusz css.

I teraz: chce wyświetlić to na innym urządzeniu. Muszę zmienić
interface od treści, czyli FORMAT i układ LOGICZNY dokumentu
(np nie można w telefonie otworzyć 'nowego okna'.. itd). Generalnie,
tworze plik .wml który odpowiada z a to co i jak bedzie wyswietlane
na teleofnie.

A teraz przypadek z XMLem. Dane (TREŚĆ) nie są w bazie, tylko w pliku
tekstowym otagowane XMLem. Dla przeglądarki WWW całość jest formatowana
co prawda jednym XSLem, ale decyduje on naraz o dwóch rzeczach - o LOGICE
wyświetlanego dokumentu oraz o FORMACIE. Jeżeli chcę zrobić z treścią
coś innego, niż robi obecny XSL, to i tak musze zrobić nowy XSL.
Czyli też robię nowy 'interface'. Gdzie tu ten zysk z XMLa w koncu? :>

Wracając jeszcze raz do tego, co napisałes:

> Dane zostaja zawsze te same i nie trzeba ich duplikowac
> tyle razy ile roznych formatow.

Gdy są w bazie danych - też tak jest. Zostaja zawsze te same
i nie trzeba ich duplikować. Natomiast dla każdego "urządzenia"
trzeba napisać osobny interface, tak samo jak dla każdego urządzenia
w wypadku XMLa trzeba napisac osobny formater/filterer/converter.

Albo zaczynam błądzić, albo czegoś tu jeszcze nie rozumiem...

PS. Jeżeli ktoś mógłby poświęcić chwilke czasu aby szczegółowo
    odpisać na moj post, to byłoby mi bardzo miło. Dzięki.

-- 
Tomek

"Marcin Jagodzinski" <pisz_na_adres_z_reply_to@webcorp.com.pl> wrote in
message news:hjm9usc73a0ctouq87oj3odskiqi0vt6l1@4ax.com...

> Wydaje Ci się, że są "tak dynamiczne" :-)

A moze niektore sa naprawde "tak dynamiczne" ? ;-)

> >No, aby treści zawarte w dokumencie XML przekonwertować na HTML, musisz
> >stworzyć specjalny XSL. Zeby do WML, kolejny XSL. Tak samo z PDF.
> >Razem - cztery pliki. Trzymając treści w jakiejś bazie, musisz zrobić
> >tylko trzy interfejsy...
> >
> >Nie wiem, jestem dopiero lajkonikiem w sprawiach związanych z XML.
>
> Liczba plików naprawdę nie jest tutaj dobrym wskaźnikiem...
>

Dokladne, po pierwsze latwa publikacja dokumentow XML, to tylko jedno z
zastosowan.
Po drugie wydaje mi sie, ze przy pomocy XML i XLS zrobi sie to latwiej, niz
w jakims jezyku np. C
Do tego mamy do czynienia z calkowita separacja danych od sposobu ich
wyswietlania,
a cyz to nie bylo od dawna marzeniem programistow analitykow itp ?
Po trzecie decydujesz sie na zmiane dostawcy technologii np. baz danych i
co?
Majac okreslona definicje dokumentu XML nie ma klopotu (zapewne
juz niedlugo wiekszosc szanujacych sie producentow w jakis sposob
zaimplementuje XML. )
A co sie bedzie dzialo gdy robisz to przy pomocy "tylko" trzech interfejsow
?
Prawdopodobnie trzeba bedzie przepisywac je od nowa.
I na koniec - czy majac interface do HTML (bez XML) bedziesz w stanie
przeslac ten dokument
(np. zamowienie) do swojego dostawcy, tak, zeby system automatycznie go
zaczytal ?


> >Ale staram się trzeźwo mysleć i np. do teraz zastanawiam się, do czego
> >tak naprawdę został użyty XML w serwisie http://www.chopin.pl/index.xml
>
> To jest ciekawe. I chore.
>

No nie wiem, moze to po prostu przygotowania do XHTML ?

Krzysiek

Krzysiek Skaskiewicz wrote:
> 
> Do tego mamy do czynienia z calkowita separacja danych od sposobu ich
> wyswietlania, a cyz to nie bylo od dawna marzeniem programistow analitykow
> itp ?

Przecież dane trzymane w bazie też są całkowicie odseparowane od sposobu
ich wyświetlania...

> Po trzecie decydujesz sie na zmiane dostawcy technologii np. baz danych i
> co?

Masz rację. Ale jak decydujesz się na zmianę dostawcy dokumentów XML,
to zapewnie też cie spotka przysłowiowe już zaskoczenie, ze nie
bedzie <faktura> tylko <invoice>...
Tak czy tak, musisz mieć coś, co opisuje strukture zapisu danych.
Czy to w bazie, czy w pliku tekstowym. Nie widzę różnicy.
(oprócz takiej, że danymi w bazie łatwiej operować)

> I na koniec - czy majac interface do HTML (bez XML) bedziesz w stanie
> przeslac ten dokument
> (np. zamowienie) do swojego dostawcy, tak, zeby system automatycznie go
> zaczytal ?

No nie, tu masz całkowitą rację. Ale to przecież już wychodzi poza
zastosowania "WWW", o których rozmawiamy w tym wątku.
 
> > >Ale staram się trzeźwo mysleć i np. do teraz zastanawiam się, do czego
> > >tak naprawdę został użyty XML w serwisie http://www.chopin.pl/index.xml
> >
> > To jest ciekawe. I chore.
> 
> No nie wiem, moze to po prostu przygotowania do XHTML ?

Gdzie XHTML a XML!...

-- 
Tomek

> > Mając składowany w specjalizowanej bazie XML jako backend serwisu WWW
> 
> Co to znaczy 'specjalizowana baza XML'?
> Jak się ma XML do typowych baz danych (SQL?)?
> Dokumenty XML są przecież zapisane "na sztywno", w statycznych plikach
> tekstowych. A dzisiejsze serwisy WWW są tak dynamiczne, że aż prosi się
> o trzymanie wszystkiego co się da (treści: danych, czasem nawet tekstów)
> w bazach danych.

Jest kilka produktów bazodanowych dedykowanych do obsługi XML (cokolwiek
mogłoby to znaczyć). Bliżej nie znam,  nie wyobrażam sobie bym 
w skończonej przyszłości używał.

> 
> > możesz używając XSL konwertować go do dowolnego (X)HTML, WML, PDF i czego
> > tam jeszcze potrzebujesz, przy użyciu jednego polecenia.
> 
> No, aby treści zawarte w dokumencie XML przekonwertować na HTML, musisz
> stworzyć specjalny XSL. Zeby do WML, kolejny XSL. Tak samo z PDF.
> Razem - cztery pliki. Trzymając treści w jakiejś bazie, musisz zrobić
> tylko trzy interfejsy...

Jest tak:

1) Dane możesz mieć w plikach XML (gdy są to raczej dokumenty,
artykuły...) albo w bazie danych i dynamicznie budować z nich XML -
podobnymi technikami, jak budujesz obecnie HTML.

2) Procesory (nie musi być to XSL ale często jest) przerabiają to na
różne sposoby prezentacji (HTML, PDF, WML, może jakis automatyczny
lektor - kto wie)

Wazne są nastepujące rzeczy:

- możesz ładnie odseparować przygotowanie informacji od ich prezentacji
- np. redaktor czy insza autora pisze artykuł w ustalonym dialekcie XML
a niezależnie od niego programista i grafik stroją procesor tak, by
seksownie ową treść zaprezentował (i nie mają możliwości sobie tego
nawzajem popsuć)
[ tego typu zalety są ponoć mocno odczuwalne gdy nad serwisem pracuje
parędziesiąt albo więcej osób ]

- raz przygotowane procesory możesz reużywać (tj. jeśli masz 100
artykułów czy 100 formularzy zrobionychw tym samy XML, powinieneś je
obsłużyć tymi samymi XSL-ami)

- mając gotowy serwis na XML możesz - nie tykając danych czy artykułów
ani logiki ich przetwarzania - dorobić nowy interfejs 

Dość rzeczowa dyskusja jest na stronie Cocoona -
http://xml.apache.org/cocoon/index.html

Jeśli chodzi o mnie - moja wiedza na temat budowania WWW przy użyciu XML
na razie wynika z interesowania się sprawą bez głębszych zastosowań,
serwisów WWW w XML (jeszcze?) nie buduję, natomiast np. bardzo chętnie
pisałbym dokumentację w jakimś DocBooku lub czymś podobnym - by móc ją
_z_jednego_źródła_ konwertować na wersje online i drukowane. 

--
http://www.mk.w.pl /
 Marcin.Kasperski | O CVS i zarządzaniu wersjami kodu:                
   @softax.com.pl |   http://www.mk.w.pl/narzedzia/narzedzia_cvs      
     @bigfoot.com  \

"Tomasz Nowak" <tnowak@tux.pl> wrote in message
news:39E57A1A.CEB59037@tux.pl...

> > Do tego mamy do czynienia z calkowita separacja danych od sposobu ich
> > wyswietlania, a cyz to nie bylo od dawna marzeniem programistow
analitykow
> > itp ?
>
> Przecież dane trzymane w bazie też są całkowicie odseparowane od sposobu
> ich wyświetlania...
>

Chyba nie do konca o to chodzilo....
Wezmy przyklad strony inetowej np. sklep
Mamy strone z jakims podzbiorem produktow:

1. Tradycyjne mozliwe podejscie (w uproszczeniu):
    jsp odwoluje sie do java bean, ktory wykonuje zapytanie sql.
    zwraca wynik (jaki ? - String, ResultSet ?)
    przy pomocy jsp konstruowana jest strona www:
    dla (i=1; i<ile;i++)
        wyswietl(<tr><td>costam_z_java_bean<td></tr>)
    itp itd...
    znaczniki html sa wbudowane w kod programu
    czy to jest przejrzyste ?
    czy to jest separacja danych od sposobu ich wyswietlania ?
    poza tym programista MUSI odwalic prace projektanta stron www

2. Przy pomocy XML (w uproszczeniu):
    jsp odwoluje sie do java bean
    java bean odwoluje sie do bazy danych i (caly czas ten sam java bean)
    konstruuje dokument XML (przy pomocy API, czyli dosc latwo)
    dokument xml jest zwracany do przegladarki, ktora interpretuje go przy
pomocy pliku XLS
    Otrzymujemy porcje danych i nie interesuje nas jak TO ma wygladac w
przegadarce.
    Zajmuje sie tym Web Designer.

Po 3 miesiacach Klient mowi Tobie:
    ta tabelka ma byc troche szersza ma byc inne tlo itp...
Wezmy 1. co robisz? - pracowicie przepisujesz strone jsp (praktycznie
piszesz ja od poczatku)
Przy 2. zmieniasz jedynie plik XLS (a wlasciwie designer)

Dane zwykle i tak sa trzymane w bazie danych (xml-enabled albo nie).
Natomiast latwiej jest pisac aplikacje, gdy mamy "o co sie zaczepc"
Istnieje XML API na pewno w javie, z tego co slyszalem, to takze w  VB, C++
i innych.

> > Po trzecie decydujesz sie na zmiane dostawcy technologii np. baz danych
i
> > co?
>
> Masz rację. Ale jak decydujesz się na zmianę dostawcy dokumentów XML,
> to zapewnie też cie spotka przysłowiowe już zaskoczenie, ze nie
> bedzie <faktura> tylko <invoice>...

pewnie :-) dlatego wazne jest opracowanie opisu standardowych dokumentow.
Takie iniciatywy sa juz podejmowane np.:
http://www.tieke.fi/ovt/xml/interim.htm#Order

Mozliwa jest tez nastepujaca sytuacja:
Mamy do czynienia z niezaleznym centrum "konwersji dokumentów XML"
Odbiorca wysyla swoje zamowienie we wlasnym formacie i odbiorca ma swoj
wlasny
(calkiem inny od dostawcy format)
Dokument przechodzi przez centrum, ktore dysponuje
opisem dokumentu odbiorcy i dostawcy i "w locie" konwertuje te dokumenty.

P.S. Pomysl nie jest moj - widzialem go na jakiejs stronie polskiej stronie
www.
Mam nadzieje, ze autor rozwiazania sie na mnie nie obrazi, ze je tutaj
przedstawiam.

> Tak czy tak, musisz mieć coś, co opisuje strukture zapisu danych.
> Czy to w bazie, czy w pliku tekstowym. Nie widzę różnicy.
> (oprócz takiej, że danymi w bazie łatwiej operować)

OK. Rozwazmy moze przesylanie danych z systemu obslugi sklepu do
programu ksiegowego.
I w jednym i w drugim programie mamy bay danych. Jezeli oba systemy pochodza
od jednego
dostawcy, to nie ma problemu, ale jezeli mamy obsluge sklepu z firmy SoftA
(dbf) a
program ksiegowy z firmy SoftE (access) ?
Co daje nam fakt, ze dane sa zapisane w pewnej strukturze ?
Czy nie lepiej przeslac te dane za pomoca dokumentu XML ?

> Gdzie XHTML a XML!...

w luznym tlumaczeniu cytuje za http://www.w3.org/TR/xhtml1/#xhtml :

"dokumenty XHTML sa oparte na XML"

Krzysiek

> A mogłby mnie ktoś obdarzyć jakimś przykładem na to?
> Powiedzmy, że mialby to być prosty dokument zawierający
> dane o pacjencie pacjent.xml, np:
> 
> <pacjent>
>   <id>0001</id>
>   <imie>Jan</imie>
>   <nazwisko>Kowalski</nazwisko>
> </pacjent>
> 
> i teraz mamy bazę SQL "szpital", tabele "pacjentci" gdzie każdy
> pacjent ma swój rekord. I jak wygenerować taki pacjent.xml?id=0002 ?


Normalnie. 
   SELECT id, imie, nazwisko FROM pacjent WHERE id=0002
   ...
   print
"<pacjent><id>$id</id><imie>$imie</imie><nazwisko>$nazwisko</nazwisko></pacjent>"
(albo budując drzewko DOM inkrementalnie jeśli kto woli)

> Pytanie #2:
> A może lepiej trzymac to nie w bazie, a w samym pliku xml? tj:
> 
> <pacjent>
>   <id>0001</id>
>   <imie>Jan</imie>
>   <nazwisko>Kowalski</nazwisko>
> </pacjent>
> <pacjent>
>   <id>0002</id>
>   <imie>Henryk</imie>
>   <nazwisko>Wiśniewski</nazwisko>
> </pacjent>

Dla przechowywania danych nie ma sensu (indeksowanie, przeszukiwanie,
równoległe zapisy, ...) - patrz Program Płatnika gdzie póki ludzie nie
przywykli ponoć nieraz się zdarzało że sobie nadmazywali te XML-owe
pliki.

Natomiast jest wysoce poręczne do _przekazywania_ danych. Żeby dać
konkretny przykład: biorę udział w projektach robionych dla pewnych
banków. W takowym banku stoi sobie system obsługi bankomatów,
komunikujący się z światem dziwacznym protokołem binarnym nad TCP/IP.
Stoi główny system bankowy obsługujący jeszcze dziwniejszy (inny)
protokół. Stoi interfejs do bankowości internetowej - jeszcze inaczej.
Stoi IVR... I jeszcze parę innych... A żeby to wszystko mogło z sobą
rozmawiać i nie wymagało pisania interfejsów między każdą parą z osobna,
musi być jakiś wspólny język. I mamy taki dialekcik XML w którym można -
np. - zaprezentować przelew. Przy każdym zewnętrznym systemie stoi
bramka tłumacząca między jego slangiem a naszym XML-kiem. Ba, nawet nowo
powstający interfejs przyjął ten XML jako język własny i w nim z nami
rozmawia... Oczywiście moglibyśmy opracować jakiś standard binarny (typu
pierwsze 4 bajty to A, drugie 4 to B, ...) ale wtedy dodanie nowego pola
czy nowego typu komunikatu wymagało by przerabiania i reinstalacji masy
programów - z których znaczna część owego nowego pola nie potrzebuje.

> > A dzisiejsze serwisy WWW są tak dynamiczne, że aż prosi się
> > > o trzymanie wszystkiego co się da (treści: danych, czasem nawet tekstów)
> > > w bazach danych.
> >
> > I tak sie robi.
> 
> To po co w końcu jest ten cały XML! :-)

Chyba już trochę popisałem....

> 
> > > > możesz używając XSL konwertować go do dowolnego (X)HTML, WML,
> > > > PDF i czego tam jeszcze potrzebujesz, przy użyciu jednego polecenia.
> > >
> > > No, aby treści zawarte w dokumencie XML przekonwertować na HTML,
> > > musisz stworzyć specjalny XSL. Zeby do WML, kolejny XSL.
> > > Tak samo z PDF.
> > > Razem - cztery pliki. Trzymając treści w jakiejś bazie, musisz zrobić
> > > tylko trzy interfejsy...
> >
> > Ale wlasnie o to chodzi. Robisz _tylko_ interfejsy
> 
> Ale ja mówie o intefacach do bazy danych, a nie do dokumentu XML!

A ja mówię, że XML jest językiem _pośrednim_, umożliwiającym
odseparowanie programów odpowiedzialnych za prezentację od bazy danych i
szczegółów biznesowych. Programista koduje CGI (czy co tam lubi) które
generuje XML na podstawie zawartości bazy danych, grafik stroi sobie
XSL-e robiąc bajeranckie interfejsy i nie wchodzą sobie nijak w drogę i
nie mogą sobie nawzajem popsuć roboty. W razie potrzeby bierzesz
drugiego grafika, który wydłubuje inny XSL (czy to robiący PDF-y, czy
inaczej wysmakowany HTML), on sobie robi a programista może chodzić po
Beskidach.


> > Dane zostaja zawsze te same i nie trzeba ich duplikowac
> > tyle razy ile roznych formatow.
> 
> No dobra teraz napisze coś co mi nawet cięzko sformuować. Ale spróbuje.
> Obecny popularnie stosowana jest metoda mniej więcej taka:
> 1. TREŚĆ (jako taka) trzymana jest w bazie danych. jest ona niezależna
>    zarówno od logiki dokumentu, jak i jego formatu.

To co jest w bazie danych to nie jest pełna treść tylko 'kawałki'
wymagane do jej złożenia. Z tablic klient, zamówienie, produkt, ...
jeszcze ni wynika, co dokładnie będzie wydrukowane na fakturze (tj. co
się na niej pojawi a co nie).

> 2. za LOGIKĘ dokumentu odpowiada html.

HTML odpowiada za prezentację. Po to te <b>, <i>, <h1>, ...
Trudno jest zinterpretować - np. - HTMLowe zamówienie - wyłuskując zeń
informację co i przez kogo zostało zamówione. Zarazem, nie bardzo jest
powód by dwa razy pisać program rejestrujący zamówienie, osobno gdy
przyszło z formularza HTML a osobno gdy WAP-em.

> 3. za FORMAT - arkusz css.

css to za mało. Do drukowania i tak potrzeba PDF. Do swobodnego
sterowania prezentacją znacznie więcej niż zarządzania czcionkami. Co
jeśli chcesz mieć dwa warianty prezentacji zamówień - z grafiką i bez
albo z sortowaniem po cenie i po nazwie albo z opisami szczegółowymi i
bez nich ...


--
http://www.mk.w.pl /
 Marcin.Kasperski | Sztuczki i kruczki w C++:                         
   @softax.com.pl |   http://www.mk.w.pl/porady/porady_cplusplus      
     @bigfoot.com  \

"Krzysiek Skaskiewicz" <splkrs@spl.sas.com> wrote in message
news:8s4253$il3$1@orfika.office.polbox.pl...
> > Przecież dane trzymane w bazie też są całkowicie odseparowane od sposobu
> > ich wyświetlania...
>
> Chyba nie do konca o to chodzilo....
> Wezmy przyklad strony inetowej np. sklep
> Mamy strone z jakims podzbiorem produktow:
>
> 1. Tradycyjne mozliwe podejscie (w uproszczeniu):
>     jsp odwoluje sie do java bean, ktory wykonuje zapytanie sql.
>     zwraca wynik (jaki ? - String, ResultSet ?)
>     przy pomocy jsp konstruowana jest strona www:
>     dla (i=1; i<ile;i++)
>         wyswietl(<tr><td>costam_z_java_bean<td></tr>)
>     itp itd...
>     znaczniki html sa wbudowane w kod programu
>     czy to jest przejrzyste ?

A gdyby tak zgodnie z zaleceniami SUNa:
<myShopTag:iterateProducts ...>
    <tr>
        <td><jsp:getProperty ... /></td>
    </tr>
</myShopTag:iterateProducts>

... i znaczniki HTML _nie_sa_ wbudowane w kod programu.

>     czy to jest separacja danych od sposobu ich wyswietlania ?

Jak najbardziej.

>     poza tym programista MUSI odwalic prace projektanta stron www

Absolutnie nie.

>2. Przy pomocy XML (w uproszczeniu):
> [to pozwolilem sobie ciachnac]

> Po 3 miesiacach Klient mowi Tobie:
>     ta tabelka ma byc troche szersza ma byc inne tlo itp...
> Wezmy 1. co robisz? - pracowicie przepisujesz strone jsp (praktycznie
> piszesz ja od poczatku)

Odpowiadam mu 'no problem' i poprawiam HTML'owy z wygladu plik JSP.
Nie znam sie na XSL'u, ale obstawiam, ze web designer szybciej poprawi plik
JSP niz XLS.
BTW, z tym przepisywaniem od poczatku to przesadziles :-)

> Przy 2. zmieniasz jedynie plik XLS (a wlasciwie designer)
> [to tez ciach az do konca]

Reasumujac: nie twierdze, ze XML/XLS nalezy wyrzucic do smieci, chcialem
tylko pokazac, ze JSP generujace tradycyjny HTML, ktorych uzyles jako
przykladu negatywnego, doskonale nadaja sie do odseparowania tresci od
prezentacji, jesli zostana umiejetnie uzyte.
Pozdrawiam,
Rafal

Marcin Kasperski wrote:
> 

No dobra, przekonaliście mnie. :-)
Jak zrobimy jakiś pierwszy serwis z dokumentami w XMLu to dam znać.

-- 
Tomek

"Rafal Smyka" <rsy@img.com.pl> wrote in message
news:8s4fvr$fn9$1@news.tpi.pl...

> > > Przecież dane trzymane w bazie też są całkowicie odseparowane od
sposobu
> > > ich wyświetlania...
> >
> > Chyba nie do konca o to chodzilo....
> >

Dyskusja o wyzszosci JSP nad XML tak na prawde nie ma sensu.
Mozna powiedziec, ze te technologie sie uzupelniaja.
W przykladzie jaki podalem nie chodzilo o to, zeby pokazac jakie JSP jest
zle
(uwazam wrecz odwrotnie !), ale o fakt, ze XML faktycznie oferuje taka
separacje i ze
pewne korzysci jednak z tego wynikaja.

> A gdyby tak zgodnie z zaleceniami SUNa:
> <myShopTag:iterateProducts ...>
>     <tr>
>         <td><jsp:getProperty ... /></td>
>     </tr>
> </myShopTag:iterateProducts>
>
> ... i znaczniki HTML _nie_sa_ wbudowane w kod programu.

sorki, ale o ile sie orientuje, to
<tr> jest znacznikiem HTML
<jsp: getProperty... /> mozna uznac za pewna instrukcje programowania ?

Jedna uwaga: W wiekszosci publikacji nt. JSP (ktore ja widzialem)
sposob dobierania sie do baz danych i publikacji ich zawartosci w HTMLu jest
bardzo podobny do tego, ktory zaprezentowalem.

> > Wezmy 1. co robisz? - pracowicie przepisujesz strone jsp (praktycznie
> > piszesz ja od poczatku)
>
> Odpowiadam mu 'no problem' i poprawiam HTML'owy z wygladu plik JSP.
> Nie znam sie na XSL'u, ale obstawiam, ze web designer szybciej poprawi
plik
> JSP niz XLS.

tutaj mam inne zdanie....
wydaje mi sie,ze tatwiej jest czlowiekowi, ktory dobrze zna HTML
zalapac o co chodzi w XLS niz w JSP.

> Reasumujac: nie twierdze, ze XML/XLS nalezy wyrzucic do smieci, chcialem
> tylko pokazac, ze JSP generujace tradycyjny HTML, ktorych uzyles jako
> przykladu negatywnego, doskonale nadaja sie do odseparowania tresci od
> prezentacji, jesli zostana umiejetnie uzyte.

Tutaj calkowicie sie z Toba zgadzam,

Krzysiek

"Krzysiek Skaskiewicz" <splkrs@spl.sas.com> wrote in message
news:8s4k60$23p$1@orfika.office.polbox.pl...
> Dyskusja o wyzszosci JSP nad XML tak na prawde nie ma sensu.
> Mozna powiedziec, ze te technologie sie uzupelniaja.

Jeszcze raz podkreslam, nie chodzi mi tu o wykazywanie wyzszosci niczego nad
niczym innym.
Chcialbym tylko, zebysmy oddali Bogu co boskie, a cesarzowi co cesarskie.

Zauwaz, ze nigdzie nie neguje kombinacji XML/XLS. Po prostu zareagowalem na
fakt wykazania koniecznosci uzycia XLS przez zestawienie go z brzydkim
przykladem generowania HTMLa za pomoca JSP.
Chcialem pokazac, ze za pomoca JSP mozna to jednak zrobic duzo eleganciej i
XLS nie jest tu jedyna mozliwoscia, a Twoj przyklad byl tendencyjny :-)

> W przykladzie jaki podalem nie chodzilo o to, zeby pokazac jakie JSP jest
> zle
> (uwazam wrecz odwrotnie !), ale o fakt, ze XML faktycznie oferuje taka
> separacje i ze
> pewne korzysci jednak z tego wynikaja.

A w moim dla odmiany chodzilo o to, ze podobna separacje _faktycznie_
oferuje porzadnie napisana JSP. Bo z Twojego wynikalo, ze jest to co
najmniej niemozliwe.

> > A gdyby tak zgodnie z zaleceniami SUNa:
> > <myShopTag:iterateProducts ...>
> >     <tr>
> >         <td><jsp:getProperty ... /></td>
> >     </tr>
> > </myShopTag:iterateProducts>
> >
> > ... i znaczniki HTML _nie_sa_ wbudowane w kod programu.
>
> sorki, ale o ile sie orientuje, to
> <tr> jest znacznikiem HTML
> <jsp: getProperty... /> mozna uznac za pewna instrukcje programowania ?

<jsp:getProperty  ... /> mowi pobierz dana i wstaw ja do wynikowego HTMLa.
Czy jest instrukcja programowania? Kwestia pewnej umowy. Jest to komenda
powodujaca _prezentacje_ danych przygotowanych przez programiste i jako taka
jak najbardziej jest tu na miejscu. Logika aplikacji jest natomiast ukryta
przed designerem, czyli _oddzielona_od_prezentacji_, a o tym przeciez
rozmawiamy.
Dla rownowagi: nie probujesz chyba powiedziec, ze XLS nie odwoluje sie do
danych, ktore ma prezentowac? :-)

> Jedna uwaga: W wiekszosci publikacji nt. JSP (ktore ja widzialem)
> sposob dobierania sie do baz danych i publikacji ich zawartosci w HTMLu
jest
> bardzo podobny do tego, ktory zaprezentowalem.

To sie niestety zgadza. Nawet Sun ignoruje swoje zalecenia i w wielu
przykladach uzywaja kodu javy w plikach JSP. :-)
Nie oznacza to jednak, ze inaczej sie nie da. Jest to jedynie kwestia
dobrego stylu.

> > > Wezmy 1. co robisz? - pracowicie przepisujesz strone jsp (praktycznie
> > > piszesz ja od poczatku)
> >
> > Odpowiadam mu 'no problem' i poprawiam HTML'owy z wygladu plik JSP.
> > Nie znam sie na XSL'u, ale obstawiam, ze web designer szybciej poprawi
> plik
> > JSP niz XLS.
>
> tutaj mam inne zdanie....
> wydaje mi sie,ze tatwiej jest czlowiekowi, ktory dobrze zna HTML
> zalapac o co chodzi w XLS niz w JSP.

Coz, Ty pewnie zostaniesz przy swoim, ja przy swoim.
Wydaje mi sie, ze podany przeze mnie przyklad byl dosc 'self-explanatory'
dla HTMLowca, i nawet jesli trzeba sie nauczyc kilku(nastu?) nowych tagow,
to nie stanowi to zadnego problemu i jest jednak latwiejsze, niz opanowanie
nowego narzedzia (XLS) od podstaw.

Uzywajac Twojego przykladu: jesli trzeba bedzie poszerzyc tabele, designer
znajdzie doskonale mu znany tag <table> i wstawi/poprawi atrybut width (lub
przeedytuje arkusz styli).
Przypominam co napisales: 'pracowicie przepisujesz strone jsp (praktycznie
piszesz ja od poczatku)', co nijak ma sie do rzeczywistosci.

Oczywiscie jako czlowiek skazony java, moge nie byc obiektywny. Moze
przygotujemy przyklad zrobienia tego samego w JSP i XLS i wypowie sie ktos
kto nie zna ani jednego ani drugiego, dobrze zna natomiast HTML?

Pozdrawiam,
Rafal

> Zauwaz, ze nigdzie nie neguje kombinacji XML/XLS. Po prostu zareagowalem
na
> fakt wykazania koniecznosci uzycia XLS przez zestawienie go z brzydkim
> przykladem generowania HTMLa za pomoca JSP.
> Chcialem pokazac, ze za pomoca JSP mozna to jednak zrobic duzo eleganciej
i
> XLS nie jest tu jedyna mozliwoscia, a Twoj przyklad byl tendencyjny :-)

I mial byc _tendencyjny_ :-)

> A w moim dla odmiany chodzilo o to, ze podobna separacje _faktycznie_
> oferuje porzadnie napisana JSP. Bo z Twojego wynikalo, ze jest to co
> najmniej niemozliwe.

NIGDZIE w moim poscie nie znajdziesz informacji, ze poslugujac sie JSP
nie jest mozliwe oddzielenie danych od sposobu ich prezentacji.

Mial byc to tylko przyklad pokazujacy O CO CHODZI w mieszaniu danych
i sposobu ich prezentacji.
NIE mial natomiast pokazac JAK to zrobic w JSP, zeby nie mieszac danych ze
sposobem ich prezentacji.

Juz w poprzednim poscie napisalem,
ze platforma dobrana do przykladu byc moze nie byla zbyt szczesliwa !
Pokazalem tylko przyklad (jeden z wielu mozliwych) JAK mozna to zrobic w
JSP.

Cytuje siebie:
>1. Tradycyjne mozliwe podejscie

Wydaje mi sie przyklad byl na tyle ogolny, ze mozna go odniesc do innych
jezykow programowania.
Na przyklad mozna bylo to przedstawic w ASP.
(ale tak na prawde nie wiem, bo nie znam dobrze ASP :-)

Wszystkich urazonych PRZEPRASZAM.
Nie to bylo moim zamiarem.

> > tutaj mam inne zdanie....
> > wydaje mi sie,ze tatwiej jest czlowiekowi, ktory dobrze zna HTML
> > zalapac o co chodzi w XLS niz w JSP.
>
> Coz, Ty pewnie zostaniesz przy swoim, ja przy swoim.
> Wydaje mi sie, ze podany przeze mnie przyklad byl dosc 'self-explanatory'
> dla HTMLowca, i nawet jesli trzeba sie nauczyc kilku(nastu?) nowych tagow,
> to nie stanowi to zadnego problemu i jest jednak latwiejsze, niz
opanowanie
> nowego narzedzia (XLS) od podstaw.

Takie jest zycie. Nie mozesz stanac w miejscu i stwierdzic:
juz wszystko umiem, nie musze wiecej sie uczyc.
Jak na razie wszystko wskazuje na to, ze jednak w niedalekiej przyszlosci
web designer bedzie musial znac nowe narzedzie jakim jest xls.

> Oczywiscie jako czlowiek skazony java, moge nie byc obiektywny. Moze
> przygotujemy przyklad zrobienia tego samego w JSP i XLS i wypowie sie ktos
> kto nie zna ani jednego ani drugiego, dobrze zna natomiast HTML?

Ja tworze strony przy uzyciu JSP i XML.
Nie przeszkadzaja sobie wzajemie :-).

BTW: HTML nie jest juz zalecanym standardem publikowania
w internecie: http://www.w3.org/MarkUp/


Pozdrawiam,

Krzysiek.

"Krzysiek Skaskiewicz" <splkrs@spl.sas.com> wrote in message
news:8s6lr8$ocu$1@orfika.office.polbox.pl...
> NIGDZIE w moim poscie nie znajdziesz informacji, ze poslugujac sie JSP
> nie jest mozliwe oddzielenie danych od sposobu ich prezentacji.

Noo, pomalu dochodzimy do konsensusu :-).
Twoj pierwszy mail odczytalem jako bardzo jednostronny: XLS sluzy do
oddzielenia prezentacji od danych, czego korzystajac z innych (nazwanych
przez Ciebie tradycyjnymi) technologii nie da sie uzyskac.
NIGDZIE w Twoim poscie nie znalazlem informacji, ze zrobienie tego jest
mozliwe.
Przeczytalem go jeszcze raz i dalej go tak odbieram.
Rozumiem, ze Twoje stanowisko nieco zlagodnialo :-)

> Mial byc to tylko przyklad pokazujacy O CO CHODZI w mieszaniu danych
> i sposobu ich prezentacji.
> NIE mial natomiast pokazac JAK to zrobic w JSP, zeby nie mieszac danych ze
> sposobem ich prezentacji.

Well, rownie dobrze mozna przedstawic przyklad XML/XLS, ktory _bedzie_
mieszal dane z prezentacja.
Wziecie tego co dobre z jednego i tego co zle z drugiego i powiedzenie, ze
wlasnie na tym polega roznica jes nieobiektywne. I tego sie wlasnie czepiam.

> Wszystkich urazonych PRZEPRASZAM.
> Nie to bylo moim zamiarem.

Ze to niby ja (ten urazony)? :-)
Tak tu sobie tylko dyskutujemy, czyz nie?

> > > tutaj mam inne zdanie....
> > > wydaje mi sie,ze tatwiej jest czlowiekowi, ktory dobrze zna HTML
> > > zalapac o co chodzi w XLS niz w JSP.
> >
> > Coz, Ty pewnie zostaniesz przy swoim, ja przy swoim.
> > Wydaje mi sie, ze podany przeze mnie przyklad byl dosc
'self-explanatory'
> > dla HTMLowca, i nawet jesli trzeba sie nauczyc kilku(nastu?) nowych
tagow,
> > to nie stanowi to zadnego problemu i jest jednak latwiejsze, niz
> opanowanie
> > nowego narzedzia (XLS) od podstaw.
>
> Takie jest zycie. Nie mozesz stanac w miejscu i stwierdzic:
> juz wszystko umiem, nie musze wiecej sie uczyc.

Nie, taka jest branza IT :-)
Ale juz sie nie upierasz, ze XLS jest latwiejszy niz JSP?

> Ja tworze strony przy uzyciu JSP i XML.
> Nie przeszkadzaja sobie wzajemie :-).

Ani przez chwile w to nie watpilem (tzn. ze sobie nie przeszkadzaja). JSP
nie jest w koncu przywiazana tylko do HTMLa.

Pozdrawiam,
Rafal

Tak sie popatrzylem, popatrzylem i.....
ups, caly czas mowimy o XLS.

Kiedy powinnismy o XSL :-)

ups,

Krzysiek

"Krzysiek Skaskiewicz" <splkrs@spl.sas.com> wrote in message
news:8s6u1j$vaj$1@orfika.office.polbox.pl...
> Tak sie popatrzylem, popatrzylem i.....
> ups, caly czas mowimy o XLS.
> Kiedy powinnismy o XSL :-)

Jako lajkonik dostosowalem sie do konwencji kolegi :-)
Pozdrawiam,
Rafal

"Krzysiek Skaskiewicz" <splkrs@spl.sas.com> wrote:
> Tak sie popatrzylem, popatrzylem i.....
> ups, caly czas mowimy o XLS.
>
> Kiedy powinnismy o XSL :-)

Bo latwiej najpierw lewy paluch potem prawy i znow lewy
niz dwa lewe i prawy :)

>
> Bo latwiej najpierw lewy paluch potem prawy i znow lewy
> niz dwa lewe i prawy :)
>

Nigdy nie myslalem o tym w ten sposob...... :-)

Krzysiek

> > Powiedzmy, że mialby to być prosty dokument zawierający
> > dane o pacjencie pacjent.xml, np:
> >
> > <pacjent>
> >   <id>0001</id>
> >   <imie>Jan</imie>
> >   <nazwisko>Kowalski</nazwisko>
> > </pacjent>
> >
> > i teraz mamy bazę SQL "szpital", tabele "pacjentci" gdzie każdy
> > pacjent ma swój rekord. I jak wygenerować taki pacjent.xml?id=0002 ?
>
>
> Normalnie.
>    SELECT id, imie, nazwisko FROM pacjent WHERE id=0002
>    ...
>    print
>
"<pacjent><id>$id</id><imie>$imie</imie><nazwisko>$nazwisko</nazwisko></pacj
ent>"
> (albo budując drzewko DOM inkrementalnie jeśli kto woli)
>
> > Pytanie #2:
> > A może lepiej trzymac to nie w bazie, a w samym pliku xml? tj:
> >
> > <pacjent>
> >   <id>0001</id>
> >   <imie>Jan</imie>
> >   <nazwisko>Kowalski</nazwisko>
> > </pacjent>
> > <pacjent>
> >   <id>0002</id>
> >   <imie>Henryk</imie>
> >   <nazwisko>Wiśniewski</nazwisko>
> > </pacjent>

1. nowy SQL serwer potrafi generować bezpośrednio XML jako wynik zapytania
do bazy... z pominięciem etapu - recordset ADO.

>
> Dla przechowywania danych nie ma sensu (indeksowanie, przeszukiwanie,
> równoległe zapisy, ...) - patrz Program Płatnika gdzie póki ludzie nie
> przywykli ponoć nieraz się zdarzało że sobie nadmazywali te XML-owe
> pliki.
>
> Natomiast jest wysoce poręczne do _przekazywania_ danych. Żeby dać
> konkretny przykład: biorę udział w projektach robionych dla pewnych
> banków. W takowym banku stoi sobie system obsługi bankomatów,
> komunikujący się z światem dziwacznym protokołem binarnym nad TCP/IP.
> Stoi główny system bankowy obsługujący jeszcze dziwniejszy (inny)
> protokół. Stoi interfejs do bankowości internetowej - jeszcze inaczej.
> Stoi IVR... I jeszcze parę innych... A żeby to wszystko mogło z sobą
> rozmawiać i nie wymagało pisania interfejsów między każdą parą z osobna,
> musi być jakiś wspólny język. I mamy taki dialekcik XML w którym można -
> np. - zaprezentować przelew. Przy każdym zewnętrznym systemie stoi
> bramka tłumacząca między jego slangiem a naszym XML-kiem. Ba, nawet nowo
> powstający interfejs przyjął ten XML jako język własny i w nim z nami
> rozmawia... Oczywiście moglibyśmy opracować jakiś standard binarny (typu
> pierwsze 4 bajty to A, drugie 4 to B, ...) ale wtedy dodanie nowego pola
> czy nowego typu komunikatu wymagało by przerabiania i reinstalacji masy
> programów - z których znaczna część owego nowego pola nie potrzebuje.
>
> > > A dzisiejsze serwisy WWW są tak dynamiczne, że aż prosi się
> > > > o trzymanie wszystkiego co się da (treści: danych, czasem nawet
tekstów)
> > > > w bazach danych.
> > >
> > > I tak sie robi.

2. Hmmm no owszem może i tak, ale ja prawdę mówiąc się co nieco na tym
przejechałem...
problem jest jeden - wydajność. Niestety obecnie z nieznanych mi bliżej
przyczyn panuje moda
na używanie XML'a po stronie serwera - dokonanie transformacji przez XSL też
na serwerze i wypisanie
otrzymanego stringa do przeglądarki.
Według mnie nie jest prawdą to co napisał jakiś tam pan z MS na pewnej
stronce w msdn...XML/XSL na serwerze jest szybsze od samego asp.
I tak na prawdę nawiększą korzysć odniesie się z XML jak go się przerzuci na
przeglądarkę i na nią zwali transformację...

> >
> > To po co w końcu jest ten cały XML! :-)

przyznam szczerze że po jakimś miesiącu zmagań z tematem uważam że nie
należy robić wcale tyle szumu wokół XMLa ile należy go robić na temat XSL'a
bo to jest potęga - nie znam sposobu na łatwiejsze szybsze i bardziej
eleganckie uzyskanie skomplikowanych przekształceń danych niż przez XSL
(mając
za alternatywy javę, i vbscript - asp/php itp....)
przykładami mogą być kody generujące wszelkiego typu menu hierarchiczne,
drzewka itp... obkodowane w javie mają po 0,7 kloca i są koszmarne - to samo
w XSL
można mieć w 50 linii i z głowy.

>
> Chyba już trochę popisałem....
>
> >
> > > > > możesz używając XSL konwertować go do dowolnego (X)HTML, WML,
> > > > > PDF i czego tam jeszcze potrzebujesz, przy użyciu jednego
polecenia.
> > > >
> > > > No, aby treści zawarte w dokumencie XML przekonwertować na HTML,
> > > > musisz stworzyć specjalny XSL. Zeby do WML, kolejny XSL.
> > > > Tak samo z PDF.
> > > > Razem - cztery pliki. Trzymając treści w jakiejś bazie, musisz
zrobić
> > > > tylko trzy interfejsy...
> > >
> > > Ale wlasnie o to chodzi. Robisz _tylko_ interfejsy
> >
> > Ale ja mówie o intefacach do bazy danych, a nie do dokumentu XML!
>
> A ja mówię, że XML jest językiem _pośrednim_, umożliwiającym
> odseparowanie programów odpowiedzialnych za prezentację od bazy danych i
> szczegółów biznesowych. Programista koduje CGI (czy co tam lubi) które
> generuje XML na podstawie zawartości bazy danych, grafik stroi sobie
> XSL-e robiąc bajeranckie interfejsy i nie wchodzą sobie nijak w drogę i
> nie mogą sobie nawzajem popsuć roboty. W razie potrzeby bierzesz
> drugiego grafika, który wydłubuje inny XSL (czy to robiący PDF-y, czy
> inaczej wysmakowany HTML), on sobie robi a programista może chodzić po
> Beskidach.
>
>
> > > Dane zostaja zawsze te same i nie trzeba ich duplikowac
> > > tyle razy ile roznych formatow.
> >
> > No dobra teraz napisze coś co mi nawet cięzko sformuować. Ale spróbuje.
> > Obecny popularnie stosowana jest metoda mniej więcej taka:
> > 1. TREŚĆ (jako taka) trzymana jest w bazie danych. jest ona niezależna
> >    zarówno od logiki dokumentu, jak i jego formatu.
>
> To co jest w bazie danych to nie jest pełna treść tylko 'kawałki'
> wymagane do jej złożenia. Z tablic klient, zamówienie, produkt, ...
> jeszcze ni wynika, co dokładnie będzie wydrukowane na fakturze (tj. co
> się na niej pojawi a co nie).
>
> > 2. za LOGIKĘ dokumentu odpowiada html.

a to co jest w tym wszystkim jeszcze najbardziej ciekawe jeżeli chodzi o
zastosowania XML'a to to że
dane w XML'u mogą przyjmować postać paskudnie hierarchicznych zestawów
danych których wyłuskanie SQL'em
jest co najmniej karkołomne... a w XML'u ze względu na jego hierarchiczną i
drzewiastą strukturę takie dane to normalka...

>
> HTML odpowiada za prezentację. Po to te <b>, <i>, <h1>, ...
> Trudno jest zinterpretować - np. - HTMLowe zamówienie - wyłuskując zeń
> informację co i przez kogo zostało zamówione. Zarazem, nie bardzo jest
> powód by dwa razy pisać program rejestrujący zamówienie, osobno gdy
> przyszło z formularza HTML a osobno gdy WAP-em.

no teoretycznie to oczywiście w takiej syuacji to się używa php, asp .... i
dzięki nim mieszamy dane z layoutem ale xsl jest ciekawszy i bardziej
"powerfull"


Pozdrowienia,

Marcin

>
> > 3. za FORMAT - arkusz css.
>
> css to za mało. Do drukowania i tak potrzeba PDF. Do swobodnego
> sterowania prezentacją znacznie więcej niż zarządzania czcionkami. Co
> jeśli chcesz mieć dwa warianty prezentacji zamówień - z grafiką i bez
> albo z sortowaniem po cenie i po nazwie albo z opisami szczegółowymi i
> bez nich ...
>
>
> --
> http://www.mk.w.pl /
>  Marcin.Kasperski | Sztuczki i kruczki w C++:
>    @softax.com.pl |   http://www.mk.w.pl/porady/porady_cplusplus
>      @bigfoot.com  \