🚀 go-pugleaf

On Fri, 1 Sep 2000 09:48:32 +0200, "Karol" <karsc@yoyo.pl> wrote:

>Mam dokument XML plus XSL i DTD. XSL jest tak stworzony, ze zawiera dwie
>ramki  (HTML). Do kazdej ramki w HTML trzeba ladować osobny dokument zatem
>musialem utworzyc trzy rozne pliki XSL ale czy musze w zwiazku z tym tworzyc
>trzy pliki XML z takimi samymi danymi czy moge skorzystac z jednego głownego
>pliku XML i dynamicznie ladowac odwołania do poszczegolnych plikow XSL.
>Jesli tak to w jaki sposob?
>
No i tu masz problem :-)

Wszyscy się zachwycają tym jak to XSL pozwala na podział na wygląd i treść,
tymczasem moim zdaniem jest tu spore nieporozumienie. Skoro w XML-u na
sztywno podajesz, jakim arkuszem zamierzasz go przetworzyć, to niby gdzie
jest ten podział? Chyba, że chodzi o podział na dwa dokumenty, ale to nie
jest jeszcze to.

Wracając do Twojego pytania: zależy czego używasz, jako engine do XSLa.
Musisz się zorientować, czy da się przekazać nazwę arkusza jako parametr. I
tyle.

Jeszcze lepsza jest zabawa jak masz np. jeden długi XML (powiedzmy książkę
podzieloną na rozdziały) i chcesz pokazywać po 1 rozdziale na raz. Czyli
masz 1 XML, 1 XSL -- ale z użyciem parametrów w tym drugim. Ciekawe... jak
do takiego procesora XSLT jaki jest w MSIE przekazać parametr...

Marcin Jagodzinski
(or compatible)

To moj pierwszy kontakt z pl.comp.xml, wiec witam wszystkich listowiczów.

A propos problemu z XSL: sadze, ze XSL (albo precyzyjniej: XSLT) moze okazac
sie srednio uzyteczny, gdy chcemy zeby to browser dokonywal przetwarzania
XSLT. Stad problemy, o ktorych piszecie. Natomiast uzyty wewnatrz aplikacji
Webowej, po stronie serwera, moze zdzialac cuda.
Oczywiscie, jesli to serwer wykonuje przetwarzanie XSLT, nie ma przeszkod,
by dynamicznie okreslic XSLT, ktory ma byc uzyty do transformacji. Malo
tego, poniewaz dokument XSLT jest rowniez dokumentem XML (ma drzewo DOM),
moze zostac latwo zmodyfikowany przed zastosowaniem (sposob na
parametryzacje). Procesor XSLT i tak zwykle "otrzymuje" dokument XSLT jako
serie zdarzen SAX albo drzewo DOM z parsera XML a nie jako dokument
tekstowy.
Jest tez bardziej elegancki sposob, ktory widzialem w dzialaniu: arkusz
XSLT, ktory jest uzywany do transformacji naszego XMLa z danymi jest
tworzony dynamicznie przez inna transformacje XSLT (w rzeczywistosci to ciag
kolejnych transformacji). W tym przypadku KOMPLETNA logika aplikacji jest
zapisana w XSLT! To na prawde dziala (OK, troche wolno).

To tyle tytulem "obrony" XSLT. Problem Karola wymaga dynamicznego okreslania
transformacji XSLT i wtedy oczywiscie dokument XML z danymi moze (i
powinien) byc jeden. W zaleznosci od stopnia zlozonosci na serwerze moze byc
jeden XSLT, trzy, albo wcale (!). Ale raczej bedzie to trudne uzywajac
mechanizmow MSIE (zwlaszcza, ze jego procesor XSLT jest, delikatnie mowiac,
taki sobie :-), ale...

...widzialem kiedys cos podobnego, wiec jesli koniecznie chesz... W MSIE
jest mozliwosc (nie znam szczegolow) dobrania sie do drzewa DOM arkusza XSL,
ktory jest uzywany do transformacji wyswietlanego aktualnie XMLa, z
mozliwoscia modyfikacji wezlow (specjalnie nie pisze XSLT, bo MSIE nie widzi
roznicy). Nie wiem, czy da sie to zrobic z JavaScripta. Zalozmy, ze tak -
inaczej mialo by ograniczony sens. Zatem ladujesz dokument XML z podlaczonym
na sztywno (zawsze tym samym) arkuszem XSL, ktory transformuje XML do HTML
wrzucajac do niego potrzebny kod JavaScript. Kod ten modyfikuje drzewo DOM
uzywanego XSL, tworzac (w pamieci rzecz jasna) wlasciwie nowy arkusz XSL -
usuwa wiekszosc wezlow (w szczegolnosci ten, ktory oryginalnie wstawial kod
JavaScript) i wstawia takie, jakie uwaza za potrzebne (dynamicznie! - inne
dla jednej ramki, inne dla drugiej itd.). Ta modyfikacja powoduje z kolei
zmiane HTMLa, ktory jest wyswietlany. Cool ;-) Ale uwaga, pokazywal to koles
z Microsofta ze Stanow, wiec nie mam pewnosci, czy ten mechanizm da sie
zastosowac w praktyce (bardzo watpie) Ale robilo wrazenie. :-)

Jesli uda Ci sie to zrobic, koniecznie sie pochwal.

Przetwarzanie po stronie przegladarki ma jeszcze jedna wade (zwlaszcza w
przykladzie Marcina z ksiazka). Kazda transformacja XSL wymaga zaladowania
do browsera calego dokumentu XML, ktory ma byc przetworzony. Troche bez
sensu ladowac cala ksiazke, gdy chcesz tylko pokazac spis tresci...

Pozdrowienia

Grzegorz Balnis

Marcin Jagodzinski napisał(a) w wiadomości: ...
>On Fri, 1 Sep 2000 09:48:32 +0200, "Karol" <karsc@yoyo.pl> wrote:
>
>>Mam dokument XML plus XSL i DTD. XSL jest tak stworzony, ze zawiera dwie
>>ramki  (HTML). Do kazdej ramki w HTML trzeba ladować osobny dokument zatem
>>musialem utworzyc trzy rozne pliki XSL ale czy musze w zwiazku z tym
tworzyc
>>trzy pliki XML z takimi samymi danymi czy moge skorzystac z jednego
głownego
>>pliku XML i dynamicznie ladowac odwołania do poszczegolnych plikow XSL.
>>Jesli tak to w jaki sposob?
>>
>No i tu masz problem :-)
>
>Wszyscy się zachwycaj? tym jak to XSL pozwala na podział na wygl?d i tre?ć,
>tymczasem moim zdaniem jest tu spore nieporozumienie. Skoro w XML-u na
>sztywno podajesz, jakim arkuszem zamierzasz go przetworzyć, to niby gdzie
>jest ten podział? Chyba, że chodzi o podział na dwa dokumenty, ale to nie
>jest jeszcze to.
>
>Wracaj?c do Twojego pytania: zależy czego używasz, jako engine do XSLa.
>Musisz się zorientować, czy da się przekazać nazwę arkusza jako parametr. I
>tyle.
>
>Jeszcze lepsza jest zabawa jak masz np. jeden długi XML (powiedzmy ksi?żkę
>podzielon? na rozdziały) i chcesz pokazywać po 1 rozdziale na raz. Czyli
>masz 1 XML, 1 XSL -- ale z użyciem parametrów w tym drugim. Ciekawe... jak
>do takiego procesora XSLT jaki jest w MSIE przekazać parametr...
>
>Marcin Jagodzinski
>(or compatible)

On Sat, 9 Sep 2000 14:24:52 +0200, "Grzegorz Balnis" <gbalnis@abc.com.pl>
wrote:

>...widzialem kiedys cos podobnego, wiec jesli koniecznie chesz... W MSIE
>jest mozliwosc (nie znam szczegolow) dobrania sie do drzewa DOM arkusza XSL,
>ktory jest uzywany do transformacji wyswietlanego aktualnie XMLa, z
>mozliwoscia modyfikacji wezlow (specjalnie nie pisze XSLT, bo MSIE nie widzi
>roznicy). Nie wiem, czy da sie to zrobic z JavaScripta. Zalozmy, ze tak -
>inaczej mialo by ograniczony sens. Zatem ladujesz dokument XML z podlaczonym
>na sztywno (zawsze tym samym) arkuszem XSL, ktory transformuje XML do HTML
>wrzucajac do niego potrzebny kod JavaScript. Kod ten modyfikuje drzewo DOM
>uzywanego XSL, tworzac (w pamieci rzecz jasna) wlasciwie nowy arkusz XSL -
>usuwa wiekszosc wezlow (w szczegolnosci ten, ktory oryginalnie wstawial kod
>JavaScript) i wstawia takie, jakie uwaza za potrzebne (dynamicznie! - inne
>dla jednej ramki, inne dla drugiej itd.). Ta modyfikacja powoduje z kolei
>zmiane HTMLa, ktory jest wyswietlany. Cool ;-) Ale uwaga, pokazywal to koles
>z Microsofta ze Stanow, wiec nie mam pewnosci, czy ten mechanizm da sie
>zastosowac w praktyce (bardzo watpie) Ale robilo wrazenie. :-)
>

Strasznie to skomplikowane.

Już chyba lepiej napisać te kilka arkuszy, a XML generować "dynamicznie".
Konkretnie tę jedną linijkę.

<?xml version='1.0'?>
<?xml-stylesheet href='/sciezka_do_arkuszy<!--#echo var="PATH_INFO" -->'?>
...

I możemy się odwoływać np. foo.xml/bar.xslt

Na pewno nie zadziała to na każdym serwerze, ale pewnie da się jakoś
zmodyfikować (używając PHP/ASP/whatever), żeby zadziałało.

>Przetwarzanie po stronie przegladarki ma jeszcze jedna wade (zwlaszcza w
>przykladzie Marcina z ksiazka). Kazda transformacja XSL wymaga zaladowania
>do browsera calego dokumentu XML, ktory ma byc przetworzony. Troche bez
>sensu ladowac cala ksiazke, gdy chcesz tylko pokazac spis tresci...
>
No niestety. Ale co zrobić...[1]

Marcin Jagodzinski
(or compatible)

[1] Może da się jakoś XLink wykorzystać, ale w tej chwili nie za bardzo
wiem jak.

Tak, wracamy wiec do koncepcji przetwarzania po stronie serwera, zatem ...
(patrz nizej)

Marcin Jagodzinski napisał(a) w wiadomości:
<8dekrscau4to80c0irt8lghp2enh619kd6@4ax.com>...
>On Sat, 9 Sep 2000 14:24:52 +0200, "Grzegorz Balnis" <gbalnis@abc.com.pl>
>wrote:
>
>Strasznie to skomplikowane.
>

Powiem wiecej, to dobre chyba tylko na prezentacje Microsofta. Osobiscie nie
poswiecilbym ani godziny na probowanie robienia czegos takiego. Ale to
jedyna (chyba) droga na zrobienie tego zadania po stronie przegladarki.
Niemniej pokazuje "power" XSL - korzysci z faktu, ze istnieje drzewo DOM dla
arkusza XSL, ktore mozna dynamicznie modyfikowac.

>Już chyba lepiej napisać te kilka arkuszy, a XML generować "dynamicznie".
>Konkretnie tę jedn? linijkę.
>
><?xml version='1.0'?>
><?xml-stylesheet href='/sciezka_do_arkuszy<!--#echo var="PATH_INFO" -->'?>
>...
>
>I możemy się odwoływać np. foo.xml/bar.xslt
>
Skoro zatem decydujemy sie na robienie "czegos" stronie serwera, mozna
wrocic do koncepcji przetwarzania XSLT po stronie serwera.

>Na pewno nie zadziała to na każdym serwerze, ale pewnie da się jakoś
>zmodyfikować (używając PHP/ASP/whatever), żeby zadziałało.

PHP nie znam, ktos pisal o parserze XML, nie wiem co z procesorem XSL. Jesli
ASP: OK, od biedy mozna w technologii Microsofta - jest parser XML, jest
procesor XSL (taki sobie). Java >= 1.1.8: super - jest xerces (parser XML) i
xalan (dawny LotusXSL IBMa) - to akurat pieknie dziala.

Dlaczego tak sie meczyc? Poniewaz nie zasmiecasz Twoich dokumentow znaczkami
<!--#costam--> i dzialaja na kazdym systemie. Zasadniczo dlatego wybierasz
XSLT - te same funkcje (transformacje XML->HTML) moze spelnic skrypt w Perlu
czy Omnimarku, ale XSLT jest standardem. Za chwile serwery WWW beda mialy
wbudowane parsery XML i procesory XSLT (patrz: Apache), co nie koniecznie
jest prawda w przypadku Perla czy PHP a na pewno nie jest prawda w przypadku
ASP czy Omnimarka.

Poza tym czasem jestes zmuszony skorzystac z Twojego dokumentu XML nie tylko
w celu wyswietlenia go w przegladarce i takie cuda (<!--#costam-->) sa
wyjatkowo wredne, ponieważ dla parsera XML nie znacza dokladnie nic - tylko
komentarz.

Oczywiscie to moje rozumienie pewnego kanonu tworzenia aplikacji, ktory
zasadniczo sprawdza sie w przypadku duzych systemow (wieloplatformowosc,
wielowarstwowosc, zastosowanie standardow itd.) i ekstra naklad pracy tam
sie oplaca. W wielu przypadkach zapewne lepsze jest prostsze i tansze
rozwiazanie, na przyklad takie, jakie zaproponowales.

>[1] Może da się jako? XLink wykorzystać, ale w tej chwili nie za bardzo
>wiem jak.

Trudno powiedziec jak i kiedy przegladarki zaimplementuja XLink/XPath. To
czysty futuryzm :-)

Pozdrowienia

Grzegorz Balnis, mailto:gbalnis@abc.com.pl

On Sat, 9 Sep 2000 16:54:24 +0200, "Grzegorz Balnis" <gbalnis@abc.com.pl>
wrote:

>>Już chyba lepiej napisać te kilka arkuszy, a XML generować "dynamicznie".
>>Konkretnie tę jedn? linijkę.
>>
>><?xml version='1.0'?>
>><?xml-stylesheet href='/sciezka_do_arkuszy<!--#echo var="PATH_INFO" -->'?>
>>...
>>
>>I możemy się odwoływać np. foo.xml/bar.xslt
>>
>Skoro zatem decydujemy sie na robienie "czegos" stronie serwera, mozna
>wrocic do koncepcji przetwarzania XSLT po stronie serwera.

Nie. Dlaczego. Jeżeli jadę taksówką na lotnisko i lecę do Stanów to
powiesz, że odbyłem podróż samochodowo-lotniczą? :-)

To tylko mały fragmencik odbywa się na serwerze.

>>Na pewno nie zadziała to na każdym serwerze, ale pewnie da się jakoś
>>zmodyfikować (używając PHP/ASP/whatever), żeby zadziałało.
>
>PHP nie znam, ktos pisal o parserze XML, nie wiem co z procesorem XSL. Jesli
>ASP: OK, od biedy mozna w technologii Microsofta - jest parser XML, jest
>procesor XSL (taki sobie). Java >= 1.1.8: super - jest xerces (parser XML) i
>xalan (dawny LotusXSL IBMa) - to akurat pieknie dziala.
>
>Dlaczego tak sie meczyc? Poniewaz nie zasmiecasz Twoich dokumentow znaczkami
><!--#costam--> i dzialaja na kazdym systemie. Zasadniczo dlatego wybierasz
>XSLT - te same funkcje (transformacje XML->HTML) moze spelnic skrypt w Perlu
>czy Omnimarku, ale XSLT jest standardem. Za chwile serwery WWW beda mialy
>wbudowane parsery XML i procesory XSLT (patrz: Apache), co nie koniecznie
>jest prawda w przypadku Perla czy PHP a na pewno nie jest prawda w przypadku
>ASP czy Omnimarka.

Podejrzewam, że działa to na Apache'u i na IISie. Wystarczy. Naprawdę to
dużo łatwiejsze niż instalowanie parsera po stronie serwera. I zupełnie
zmienia sposób przetwarzania XML-a (być może u każdego klienta jest inny
bar.xslt -- tej funkcjonalności na serwerze nie osiągniesz). 

>Poza tym czasem jestes zmuszony skorzystac z Twojego dokumentu XML nie tylko
>w celu wyswietlenia go w przegladarce i takie cuda (<!--#costam-->) sa
>wyjatkowo wredne, ponieważ dla parsera XML nie znacza dokladnie nic - tylko
>komentarz.

Gorzej: to przestaje być poprawny XML, komentarz jest wewnątrz tagu.

>Oczywiscie to moje rozumienie pewnego kanonu tworzenia aplikacji, ktory
>zasadniczo sprawdza sie w przypadku duzych systemow (wieloplatformowosc,
>wielowarstwowosc, zastosowanie standardow itd.) i ekstra naklad pracy tam
>sie oplaca. W wielu przypadkach zapewne lepsze jest prostsze i tansze
>rozwiazanie, na przyklad takie, jakie zaproponowales.
>
Masz rację. Ale przyznam, że jedyną wadą tego rozwiązania jest do, że kod
nie jest zgodny z XML. Zauważ, że jest to coś maksymalnie prostego. Można
to przecież zrobić np. kilkulinijkowcem w perlu, który dopisze
?xml-stylesheet do dokumentu (z odpowiednim parametrem). Owszem, jest to
przetwarzanie po stronie serwera. Ale w bardzo małym stopniu. Resztę robi
XSLT po stronie przeglądarki. 

Mam nadzieję, że po wyjściu Mozilli XSLT będzie standardem (tzn, że będzie
można mieć nadzieję, że użytkownik XSLT ma). Gdyby tylko MS dołączał do
swoich przeglądarek wersję w miarę zgodną ze specyfikacją...


Marcin Jagodzinski
(or compatible)

Marcin Jagodzinski napisał(a) w wiadomości: ...
>On Sat, 9 Sep 2000 16:54:24 +0200, "Grzegorz Balnis" <gbalnis@abc.com.pl>
>wrote:
>
>>Skoro zatem decydujemy sie na robienie "czegos" stronie serwera, mozna
>>wrocic do koncepcji przetwarzania XSLT po stronie serwera.
>
>Nie. Dlaczego. Jeżeli jadę taksówk? na lotnisko i lecę do Stanów to
>powiesz, że odbyłem podróż samochodowo-lotnicz?? :-)

No, raczej tak. Ale w tej analogii nie wiem, czy przetwarzanie po stronie
przegladarki kojarzyc z samolotem czy z samochodem :-)) Dla mnie to troche
jak podroz na omedze przez Atlantyk ;-))

>Podejrzewam, że działa to na Apache'u i na IISie. Wystarczy. Naprawdę to
>dużo łatwiejsze niż instalowanie parsera po stronie serwera. I zupełnie
>zmienia sposób przetwarzania XML-a (być może u każdego klienta jest inny
>bar.xslt -- tej funkcjonalno?ci na serwerze nie osi?gniesz).

Dlaczego? Przeciez dokument XSL i tak jest na serwerze. Mozesz zdecydowac,
ktory XSL komu podrzucic.

>>Poza tym czasem jestes zmuszony skorzystac z Twojego dokumentu XML nie
tylko
>>w celu wyswietlenia go w przegladarce i takie cuda (<!--#costam-->) sa
>>wyjatkowo wredne, ponieważ dla parsera XML nie znacza dokladnie nic -
tylko
>>komentarz.
>
>Gorzej: to przestaje być poprawny XML, komentarz jest wewn?trz tagu.

No, jesli inaczej nie da sie tego zapisac, to juz w ogole kaszana (nie znam
skladni PHP ani ASP ;-). To prowadzi do tworzenia wlasnego "XML", tzn.
uzywamy skladni XML tam, gdzie nam wygodnie i nazywamy to XML (dokladnie to
samo robi Microsoft).

>
>Masz rację. Ale przyznam, że jedyn? wad? tego rozwi?zania jest do, że kod
>nie jest zgodny z XML. Zauważ, że jest to co? maksymalnie prostego. Można
>to przecież zrobić np. kilkulinijkowcem w perlu, który dopisze
>?xml-stylesheet do dokumentu (z odpowiednim parametrem). Owszem, jest to
>przetwarzanie po stronie serwera. Ale w bardzo małym stopniu. Resztę robi
>XSLT po stronie przegl?darki.
>
>Mam nadzieję, że po wyj?ciu Mozilli XSLT będzie standardem (tzn, że będzie
>można mieć nadzieję, że użytkownik XSLT ma). Gdyby tylko MS doł?czał do
>swoich przegl?darek wersję w miarę zgodn? ze specyfikacj?...

Zasadniczo masz racje: proste jest piekne. Ale jak popatrzysz przez pryzmat
wymagan dla aplikacji, to jedno z pierwszych pytan bedzie: co z
przegladarkami, ktore nie maja procesora XSLT? Albo bedziesz musial
kaskadowo przetwarzac XSLT? Albo... itd. W wiekszosci przypadkow bedziesz
zmuszony zrobic przetwarzanie na serwerze. Slowem, chyba warto wczesniej
przetrzec szlaki. No, chyba, ze wiesz, ze nigdy Ci to nie grozi.

Na dzisiaj jakosc przetwarzania XML, nie mowiac juz o XSLT w MSIE jest tak
fatalna, ze trudno mowic o powaznym zastosowaniu go do bezposredniego
wyswietlania XML/XSL. Bez wielkiego trudu mozna napisac poprawny dokument
XML, ktory nie da sie pokazac a co dopiero z XSLT.

Pozdrowienia

Grzegorz Balnis, gbalnis@abc.com.pl