🚀 go-pugleaf

On Wed, 13 Sep 2000 10:59:28 +0200, Andrzej Dmoch <and@step.pl> wrote:


>Marcin Jagodzinski wrote:
>
>> Dnia 12 Sep 00, o 18:01, Andrzej Dmoch zezna?(a):
>>
>>  > > To tylko ma?y fragmencik odbywa si? na serwerze.
>>  > Tak ale ten maly fragmencik moze calkowicie uniemozliwic pewne profesjonalne
>>  > zastosowania - na przyklad komputery klienckie bez TCP/IP.
>>  >
>>  > Przegladarka powinna pozwalac na przerzucenie dokladnie wszystkich operacji
>>  > na strone klienta. Serwery zas powinny umozliwiac serwowanie danych pod
>>  > kazdego klienta (XML enabled lub nie). Wiec uwazam, ze MSIE poszedl w dobra
>>  > strone, te mechanizmy skryptowe sa bardzo ciekawe i aplikowanie arkuszy
>>  > stylow takie jak trzy do jednego dokumentu jest tam mozliwe.
>>  >
>> Nie bardzo rozumiem, czemu nie na grupie, ale niech b?dzie.
>
>Przez pomylke :-). Teraz juz na grupe.
>
>> Co do mojego przyk?adu, to by? to tylko przyk?ad. Komputera klienckiego
>> bez TCP/IP szczerze mówi?c nie widzia?em i nie za bardzo rozumiem, o co
>> chodzi? ?e nie ma dost?pu do pliku przez http, tylko jako? inaczej?
>
>Oczywiscie! Na przyklad komputery ludzi wyswietlajacych dowolne elektroniczne
>dokumenty
>stworzone przez ich programy ksiegowe. Mieszkasz w Warszawie i obracasz sie w
>swiecie komputerowym, stad nie widziales komputera bez TCP/IP. W profesjonalnych
>zastosowaniach brak TCP/IP moze byc rzeczywisotscia.
>
>Sytuacja jest taka, ze masz plik XML na dysku i chcesz go objerzec jakims
>umowionym, przypisanym do rozszerzenia XSL-em. Odpadaja wtedy wszystkie metody
>serwerowe. Wtedy wszystko musi sie dziac po stronie klienta.
>
>Ponadto taka filozofia moze poskutkowac znacznym zmniejszeniem ruchu w sieci.
>Poprostu przegladarki beda programowalne i bedzie mozna wiecej operacji wykonywac u
>klienta.
>
>> Serwer sobie serwuje niezale?nie od klienta. Nie rozumiem, o co tu chodzi?
>
>To spojrzenie z drugiej strony. Jesli chcemy, zeby wszyscy uzytkownicy mieli dostep
>przy pomocy aktualnie dostepnych przegladarek, to musimy rozpoznawac typ
>przegladarki i w zaleznosci od tego serwowac pliki wynikowe i aplikowac odpowiedni
>XSL po stronie klienta.
>
>> Mechanizm, polegaj?cy na aplikowaniu jakiego? XSLa i potem modyfikowaniu
>> go za pomoc? DOM do innego XSL-a tylko po to, by zastosowa? wi?cej ni?
>> jeden XSL uwa?am za chory.
>
>Po pierwsze - o ile mi wiadomo, to zeby zastosowac rozne XSL-e w IE5.0 wcale nie
>trzeba uzywac przeksztalcen DOM. Trzeba tylko sparsowac obiekt DOM, sparsowac XSL-a
>i utworzyc nowy obiekt DOM i wyswietlic go.
>Po drugie - jesli by nawet tak bylo, to - dlaczego?
>
Przepraszam, że wszytko cytuję, ale zrobił się z tego potworny mętlik. Więc
może po kolei:

1. Nie jestem zdania, że użycie XSLT ma sens jedynie po stronie serwera. 

2. Proponowane przeze mnie rozwiązanie przetwarzało XML po stronie klienta.
3. Zgadzam się, że może to zmniejszyć ruch w sieci.

4. Pomysł z komputerami bez "TCP/IP" (chyba chodzi o http) uważam za
wydumany: proponuję wrócić do postu, który rozpoczął wątek. Nic tam nie
było o takiej sytuacji. Ale widocznie jestem warszawocentryczny, pewnie pół
prowincji siedzi przy komputerach bez TCP/IP i obrabia faktury w XML.
Jeżeli nie ma serwera, przetwarzanie po stronie serwera nie ma sensu.
Zgadzmi się. O to Ci chodziło? 

5. Jeżeli chcemy, żeby wszyscy użytkownicy mieli dostęp, to założenie, że
XSLT będzie użyte po stronie klienta niweczy nasze oczekiwania.

6. Co do szczegółów MSIE -- nie wypowiadam się. Być może istnieją inne
rozwiązania. Komentowałem to przedstawione na grupie. Uważam je dalej za
chore.

Marcin Jagodzinski
(or compatible)