[OT] aplikacja internetowa w Delphi
darekm
Udało mi się przenieść aplikację z Delphi/Win32 na przeglądarkę .
dema dostępne po adresami (to są warianty aplikacji)
http://emadar.eu:8001
http://emadar.eu:8002
http://emadar.eu:8003
Do pobrania również wersje instalacyjne/wykonawcze.
Dane techniczne:
aplikacja pracuje autonomicznie, nie wymaga odrębnego serwera
wersja tworzona dla na platformę windows jak i linux (oczywiście via FPC)
transport oparty o Synapse
Jak ktoś będzie zainteresowany to opiszę bardziej.
Jak również mogę udostępnić moduły odpowiedzialne za część serwerową.
Darek
pl.regionalne.gorny-slask
> Chciałem się pochwalić.
> Udało mi się przenieść aplikację z Delphi/Win32 na przeglądarkę .
>
>
> Do pobrania również wersje instalacyjne/wykonawcze.
>
> Dane techniczne:
> aplikacja pracuje autonomicznie, nie wymaga odrębnego serwera
> wersja tworzona dla na platformę windows jak i linux (oczywiście via FPC)
>
> transport oparty o Synapse
>
> Jak ktoś będzie zainteresowany to opiszę bardziej.
> Jak również mogę udostępnić moduły odpowiedzialne za część serwerową.
>
> Darek
...czyli, mając plik exe napisany w Delphi, mogę go umieścić na
serwerze WWW i działa z poziomu przeglądarki ? ? ?
darekm
>
>
> ...czyli, mając plik exe napisany w Delphi, mogę go umieścić na
> serwerze WWW i działa z poziomu przeglądarki ? ? ?
Można pobrać instalkę, zainstalować i uruchomić u siebie, otworzy się
okno DOS. A następnie otworzyć przeglądarkę i wpisać adres: 127.0.0.1:8001
Pod Linuxem analogicznie
Darek
abc
Nie sądzę żeby to było "okno DOS" - zapewne chodzi o okienko KONSOLOWE.
wloochacz
>> Można pobrać instalkę, zainstalować i uruchomić u siebie, otworzy się
>> okno DOS. A następnie otworzyć przeglądarkę i wpisać adres:
>> 127.0.0.1:8001
>
> Nie sądzę żeby to było "okno DOS" - zapewne chodzi o okienko KONSOLOWE.
Czepiasz się; tak czy siak, ja nie mogę tego uruchomić, bo:
Błąd!
Limit czasu bramy HTTP został przekroczony
Próbujesz odwiedzić adres http://emadar.eu:8003/, który jest w tej
chwili niedostępny. Upewnij się, czy adres został wpisany poprawnie, a
następnie spróbuj ponownie wczytać stronę.
--
wloochacz
darekm
> Limit czasu bramy HTTP został przekroczony
>
> Próbujesz odwiedzić adres http://emadar.eu:8003/, który jest w tej
> chwili niedostępny. Upewnij się, czy adres został wpisany poprawnie, a
> następnie spróbuj ponownie wczytać stronę.
Muszę sprawdzić dlaczego nie mogłeś się zalogować.
Np na IE musi być podane http://
Darek
Rafał Wójcik
Czy to jest zrobione za pomoca IntraWeb?
Pozdrawiam
RW
Użytkownik "darekm" <dar...@emadar.com> napisał w wiadomości
news:g2odls$obf$1...@nemesis.news.neostrada.pl...
darekm
> Witam.
>
> Czy to jest zrobione za pomoca IntraWeb?
>
Synapse + własny framework
Inaczej nie chodzi pod linuxem.
Darek
Adam Siwoń
> Chciałem się pochwalić.
> Udało mi się przenieść aplikację z Delphi/Win32 na przeglądarkę .
>
> dema dostępne po adresami (to są warianty aplikacji)
> http://emadar.eu:8001
> http://emadar.eu:8002
Fajne, tylko pod Operą edytory do wprowadzania użytkownika i hasła są
węższe od jednego znaku.
--
z pozdrowieniami
Adam Siwoń
darekm
> Fajne, tylko pod Operą edytory do wprowadzania użytkownika i hasła są
> węższe od jednego znaku.
musimy sprawdzić, do tej pory nie braliśmy Opery pod uwagę. Ale swoją
drogą niezgodności przeglądarek to niezłe piekło.
Darek
t0mek
> musimy sprawdzić, do tej pory nie braliśmy Opery pod uwagę. Ale swoją
> drogą niezgodności przeglądarek to niezłe piekło.
Robisz dla Opery i Ff (bo obie sa zgodne ze standardami), a potem doczepiasz
hacki dla MSIE i jest ok.
Pozdrawiam,
t0mek
Sławomir Niedziela
Do kompletu: pod konquerorem po wpisaniu loginu nic się nie dzieje.
--
Sławek
Jarosław Kołton
Użytkownik "darekm" <dar...@emadar.com> napisał w wiadomości
news:g2odls$obf$1...@nemesis.news.neostrada.pl...
Ale w takim razie opisz krok po kroku jak uruchomić dowolny program exe
Jarek
darekm
>> Dane techniczne:
>> aplikacja pracuje autonomicznie, nie wymaga odrębnego serwera
>> wersja tworzona dla na platformę windows jak i linux (oczywiście via FPC)
>>
>> transport oparty o Synapse
>>
>>
>> Jak ktoś będzie zainteresowany to opiszę bardziej.
>> Jak również mogę udostępnić moduły odpowiedzialne za część serwerową.
>>
>> Darek
>
> Ale w takim razie opisz krok po kroku jak uruchomić dowolny program exe
do tego służy tryb terminalowy, a pod Linuxem WINE i FREE NX do
zdalnego dostępu.
Może chodzi o przerobienie programu w Delphi?
Do tego potrzebne było
A. Klony obiektów tControl, tForm, tEdit, które wyglądają podobnie jak w
VCL (mają to samo API) ale ich zadaniem jest generowanie kodu HTML.
Powyższe obiekty robią rendering strony, podobnie jak to robi windows.
Ponieważ nazewnictwo jest takie samo, większość dotychczasowego kodu
można podłączyć na nowe drzewo obiektów. To jest najbardziej
pracochłonna część, szczególnie w dopracowaniu szczegółów wyglądu
komponentów, ale to tak jakby ustalać wygląd klawisza piksel po pikselu
Tu ważna jest kompilacja warunkowa. Te same moduły w zależności od
potrzeb kompilowane są ze standardową biblioteką VCL albo z moją
(nazwijmy XVCL)
B.Ponieważ program pracuje w trybie serwerowym, to jedną z większych
zmian jest umożliwienie jednoczesnej pracy wielu użytkownikom w jednej
aplikacji.Aby tego dokonać ustaliłem następującą architekturę:
1. Każda użytkownik pracuje we własnej "instancji" aplikacji, czyli
sesji , która pracuje w jednym wątku - w zwykłej aplikacji win32 jest
tak samo
2. Komunikacja z internetem, serwer HTTP, pracuje w innym wątku, co
więcej, na każdy komunikat (odebraną ramkę) inicjowany jest nowy wątek.
Tu też rozpoznawana jest (na podstawie cookie) wymagana sesja
3.Komunikacja między wątkami:
a) wielowątkowa kolejka FIFO komunikatów
b) wątek główny instancji przetwarza komunikat (podobnie jak to robi
winproc w windowsie)
c) jak przetwarzanie zostanie ukończone wątek komunikacyjny wysyła
bieżącą stronę do przeglądarki
Może to i skomplikowane, ale uzyskałem największe zbliżenie charakteru
pracy pomiędzy trybem win32 a przeglądarkowym. Ale w sumie to tylko
jeden moduł.
C. Część przeglądarkowa została skonstruowana przy następujących
założeniach:
1. Całość obliczeń "robiona" jest na serwerze, po stronie klienta tak
mało jak się tylko da - każde wpisanie danych do formatki przenoszone
jest na serwer.
2. Strony wysyłane tylko Ajaxem, jak można zauważyć w przeglądarce nie
pojawi się inny adres poza głównym, dzięki temu unika się problemów gdy
użytkownik przeładuje stronę albo wykona polecenie cofnij - zawsze
dostanie aktualny wygląd strony
3.Rendering strony, jak można zauważyć, oparty o siatkę tabelki,
większość wyglądu zapisane w CSS
4. Teoretycznie można to zobaczyć na palmtopach ale aby efekty były
zadowalające to musimy jeszcze trochę popracować. Choć będzie coraz to
łatwiej gdyż nowe wersje przeglądarek pracują już prawie tak jak te z
desktopów.
Darek
Andrzej Kmicic
> http://emadar.eu:8001
> http://emadar.eu:8002
> http://emadar.eu:8003
Nie wiem czy identycznie ale mój plugin do notepada++ oparłem tez na
module synapse i służy do komunikacji
apliakcja <-> serwer synapse <-> przegladarka.
Poniewaz nie mogę wejść na podane wyżej linki nie mogę nic na te temat
powiedzieć. Ale interesuj mnie czy uzyłes biblioteki synapse czy już
złozonego komponentu wisual synapse.
Interesuję sie metoda ponieważ od dawna w swoich aplikacjach wkładam
jezyk skryptowy PHP którego biblioteki, dostępność żródeł daja
nieograniczone możliwosci aplikacjom.
Wiele modułów korzysta z komunikacji aplikacja delphi <-> przeglądarka w
sposób zaskakująco skuteczny. Myslę ze to znakomity pomysł i nalezy go
rozwijać.
Już kilka lat temu pisałem ze przesadą jest uzywanie do raportów
komponentów do raportowania skoro przegladarki oferują naprawdę
skuteczne sposoby wykonywania raportów.
> Jak ktoś będzie zainteresowany to opiszę bardziej.
> Jak również mogę udostępnić moduły odpowiedzialne za część serwerową.
>
jeżeli można chętnie zapoznabym sie z Twoimi modułami, z pewnością są
one bardziej rozbudowane niż mój moduł. Np nie rozwiązałem jeszcze
obsługi ciasteczek i sesji. Tymczasowo ciasteczka obsługuje po stronie
przeglądarki używając pluginów JQuery. Nawiasem mówiąc jQuery daje
przegladarce troche mozliwosci odciążenia serwera i troche ozywia
kontrolki przegladarek.
Uzywam serwera w dll na hoscie lokalnym ale sparwdzałem też w sieci
działa bezbłednie.
Temat mnie interesuje i chetnie zapoznam się z Twoimi rozwiązaniami.
pozdrawiam
AK
zpksoft
> sposób zaskakująco skuteczny. Myslę ze to znakomity pomysł i nalezy go
> rozwijać.
>
Też tak sądzę. Od dawna boksuję się z różnym podejściem do aplikacji
Internetowych (od ISAPI począwszy na ASP.NET skończywszy) i wreszcie
zdecydowałem się zerwać z gotowymi rozwiązaniami w których zawsze coś
było nie tak. Już na finiszu mam projekt o następującej architekturze:
- baza FB
- usługa na serwerze komunikująca się po TCP z FB (oczywiście sql) i
przesyłająca odpowiedzi w spakowanym i zaszyfrowanym XML.
i teraz dwie możliwości:
- klient zdalny w postaci aplikacji Win32 komunikujący się po TCP z
usługą na serwerze, lub
- serwer HTTP (także jako usługa na tym samym (lub odległym) serwerze)
komunikujący się z serwerem TCP i przeglądarką
Do komunikacji z przeglądarką także wykorzystuję Ajaxa (żeby
niepotrzebnie nie przeładowywać całych stron).
Nie stosuję cookies do identyfikacji klienta tylko własny mechanizm
sesji. Jeśli będzie zainteresowanie, mogę go opisać.
Cały model już działa, obecnie szifuję go.
Serwer HTTP właściwie obsługuje pętlę komunikatów z przeglądarki,
trochę podobnie jak w app Win32.
Najważniejsze, że wszystko jest w Delphi, bez żadnych protez (.NET lub
tp.)
Pozdrawiam- Paweł Krzyżanowski
darekm
> usługą na serwerze, lub
> - serwer HTTP (także jako usługa na tym samym (lub odległym) serwerze)
> komunikujący się z serwerem TCP i przeglądarką
>
> Do komunikacji z przeglądarką także wykorzystuję Ajaxa (żeby
> niepotrzebnie nie przeładowywać całych stron).
trudno zrobić inaczej wyskakujące okienko i wiele innych rzeczy
> Nie stosuję cookies do identyfikacji klienta tylko własny mechanizm
> sesji. Jeśli będzie zainteresowanie, mogę go opisać.
Ja jestem ciekaw.
>
> Cały model już działa, obecnie szifuję go.
> Serwer HTTP właściwie obsługuje pętlę komunikatów z przeglądarki,
> trochę podobnie jak w app Win32.
> Najważniejsze, że wszystko jest w Delphi, bez żadnych protez (.NET lub
> tp.)
>
kilka moich plików:
www.emadar.com/fpc/xlapp.pas
i dalej w tym katalogu:
xlmainsyn.pas
xlcontrols.pas
xlstdctrls.pas
xlcomctrls.pas
xldialog.pas
Darek
wloochacz
>> usługą na serwerze, lub
>> - serwer HTTP (także jako usługa na tym samym (lub odległym) serwerze)
>> komunikujący się z serwerem TCP i przeglądarką
> Przeglądarka o niebo bardziej przyszłościowa
A jedynym wyjściem są rozwiązania typu XUL czy WPF.
Bo, póki co to web jest może i ładny, ale do funkcjonalności to mu
daleeeeko. A Ajax, imo, to jak polska reprezentacja; na początku było
dobrze, były duże nadzieje i buńczuczne zapowiedzi, a teraz okazuje się
że jest OK, ale nie wszędzie i nie do wszystkiego. A na pewno nie jest
panaceum na wszystko.
Szczególnie tragikomicznie wyglądają Ajaxowe emulacje GUI grubego
windowsa. To jest prawie podobne, ale prawie robi wielką różnicę.
>>
>> Do komunikacji z przeglądarką także wykorzystuję Ajaxa (żeby
>> niepotrzebnie nie przeładowywać całych stron).
> i nie tylko to,
> trudno zrobić inaczej wyskakujące okienko i wiele innych rzeczy
>
>> Nie stosuję cookies do identyfikacji klienta tylko własny mechanizm
>> sesji. Jeśli będzie zainteresowanie, mogę go opisać.
> Ja jestem ciekaw.
>
>>
>> Cały model już działa, obecnie szifuję go.
>> Serwer HTTP właściwie obsługuje pętlę komunikatów z przeglądarki,
>> trochę podobnie jak w app Win32.
>> Najważniejsze, że wszystko jest w Delphi, bez żadnych protez (.NET lub
>> tp.)
Co to jest tp?
Pytania do Was obu :)
Czy pisze się miksując HTML z czymś?
Czy dynamicznie generuje się kod za pomocą tych klas?
Czy na wyjściu, obligatoryjnie generowany jest HTML? Czy może XHTML? A
może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
transformowany do XHTML?
No i mam małe pytanie do Pawła.
Dlaczego tylko FB?
Dlaczego własny system komunikacji (a nie np. XML-RPC czy SOAP)?
Dlaczego nie np. DataAbstract + REMObjectsSDK (cobyś nie napisał, to
jesteś sam a ich jest dużo; poza tym bawią się w to od dawna, poza tym -
to jest naprawdę dobre)?
Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
--
wloochacz
darekm
>> Przeglądarka o niebo bardziej przyszłościowa
> Pod warunkiem, że w końcu będzie dostępny interfejs a'la WindowsForms.
> A jedynym wyjściem są rozwiązania typu XUL czy WPF.
na przeglądarkę to pewnie wydajność będzie lepsza ale funkcjonalność
ograniczona.
> Bo, póki co to web jest może i ładny, ale do funkcjonalności to mu
> daleeeeko. A Ajax, imo, to jak polska reprezentacja; na początku było
> dobrze, były duże nadzieje i buńczuczne zapowiedzi, a teraz okazuje się
> że jest OK, ale nie wszędzie i nie do wszystkiego. A na pewno nie jest
> panaceum na wszystko.
należy właściwie się do niego dobrać. Jednym z problemów jest podejście:
piszemy w Ajaxie a wg mnie część pisana w javascript powinna być
mikroskopijna
> Szczególnie tragikomicznie wyglądają Ajaxowe emulacje GUI grubego
> windowsa. To jest prawie podobne, ale prawie robi wielką różnicę.
Tu narzuca się analogia przejścia z Dos na Win, na początku była
emulacja dopiero potem wypracowaną własną filozofię komunikacji z
użytkownikiem. Docelowo chodzi o to aby program również chodził na
palmtopach i mniejszych i większych urządzeniach, wystarczy że będzie
obecna przeglądarka
Moje pytanie: dlaczego rozwiązania terminalowe nie zamierzają wyprzeć
przeglądarki z rynku, przecież bez zmiany kodu programu otrzymuje się
pełny działający program o szybkości działania porównywalnej z
przeglądarkami. Zamiast tego bogatsza część świata promuje aplikacje
webowe: google map, zope.com
> Czy dynamicznie generuje się kod za pomocą tych klas?
Oczywiście
> Czy na wyjściu, obligatoryjnie generowany jest HTML?
Tak
Czy może XHTML? A
Na Firefoxie przeczytałem że na dzień dzisiejszy najlepsze rozwiązanie
to html v. 4.1
> może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
> transformowany do XHTML?
1. Po co
2. jak zejść do poziomu 100 ms czasu reakcji po modyfikacji strony,
jeżeli samej przeglądarce transformacja zajmie więcej (a gdzie czas dla
serwera i transmisję)
> Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
>
Oprócz ciekawej zabawy z "jądrem" reszta absolutnie bez zmian (to wina
mojego frameworka, ale jest to już jego czwarty system)
Darek
wloochacz
>>> Przeglądarka o niebo bardziej przyszłościowa
>> Pod warunkiem, że w końcu będzie dostępny interfejs a'la WindowsForms.
>> A jedynym wyjściem są rozwiązania typu XUL czy WPF.
> To nie jest dobre wyjście (o ile wiem o co chodzi) gdy tak dużo zrzucimy
> na przeglądarkę to pewnie wydajność będzie lepsza ale funkcjonalność
> ograniczona.
wykonaniu WPF) jest nieograniczona. Taka aplikacja może być hostowana
przez przeglądarkę, lub bu uruchomiona jak zwykła app.
>> Bo, póki co to web jest może i ładny, ale do funkcjonalności to mu
>> daleeeeko. A Ajax, imo, to jak polska reprezentacja; na początku było
>> dobrze, były duże nadzieje i buńczuczne zapowiedzi, a teraz okazuje
>> się że jest OK, ale nie wszędzie i nie do wszystkiego. A na pewno nie
>> jest panaceum na wszystko.
> Bo to nie o Ajax chodzi tylko o HTML. A ten jest całkiem dobry tylko
> należy właściwie się do niego dobrać. Jednym z problemów jest podejście:
> piszemy w Ajaxie a wg mnie część pisana w javascript powinna być
> mikroskopijna
Jest całkiem dobry, ale do tworzenie DOKUMENTÓW.
A nie aplikacji.
>> Szczególnie tragikomicznie wyglądają Ajaxowe emulacje GUI grubego
>> windowsa. To jest prawie podobne, ale prawie robi wielką różnicę.
>
> Tu narzuca się analogia przejścia z Dos na Win, na początku była
> emulacja dopiero potem wypracowaną własną filozofię komunikacji z
> użytkownikiem. Docelowo chodzi o to aby program również chodził na
> palmtopach i mniejszych i większych urządzeniach, wystarczy że będzie
> obecna przeglądarka
>
> Moje pytanie: dlaczego rozwiązania terminalowe nie zamierzają wyprzeć
> przeglądarki z rynku, przecież bez zmiany kodu programu otrzymuje się
> pełny działający program o szybkości działania porównywalnej z
> przeglądarkami. Zamiast tego bogatsza część świata promuje aplikacje
> webowe: google map, zope.com
Ciężko mi nazwać google.map aplikacją to raczej przeglądarka.
Co innego google eartch; dlaczego google zrobiło "normalną app"?
Dlaczego? Dlatego,że przy obecnej technologii (głównie chodzi o ten
najlepszy html 4.1), nie ma możliwości zastąpienia zwykłej app we
wszystkich zastosowaniach. Oczywiście są radykałowie, którzy twierdzą
inaczej, ale to piękna katastrofa jest a nie rozwiązanie.
>> Czy dynamicznie generuje się kod za pomocą tych klas?
> Oczywiście
>> Czy na wyjściu, obligatoryjnie generowany jest HTML?
> Tak
> Czy może XHTML? A
> Na Firefoxie przeczytałem że na dzień dzisiejszy najlepsze rozwiązanie
> to html v. 4.1
Tzn. że Firefox ma monopol na rację?
>> może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
>> transformowany do XHTML?
> 1. Po co
Jak to "po co"?
Po to, żeby uniezależnić się od warstwy prezentacji.
Po to, że odpowiedni adapter generuje z tego np. HTML 4.1, a inny app
windowsową w Delphi a jeszcze inny...
> 2. jak zejść do poziomu 100 ms czasu reakcji po modyfikacji strony,
> jeżeli samej przeglądarce transformacja zajmie więcej (a gdzie czas dla
> serwera i transmisję)
Transformację to robić powinien silnik po stronie serwera, a nie
przeglądarka.
>> Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
>>
> Oprócz ciekawej zabawy z "jądrem" reszta absolutnie bez zmian (to wina
> mojego frameworka, ale jest to już jego czwarty system)
Co to dokładnie znaczy - reszta praktycznie bez zmian?
I - gdzie mogę zobaczyć demo, za pomocą którego mogę wyklikać prostą app
bazodanową? ;)
Czasem coś by się przydało napisać w www, ale odrzuca mnie jak widzę te
wszystkie JS, HTML, PHP, CSS i co tam jeszcze wymyślą.
Sorry, ale takiego burdelu to chyba nie ma nigdzie.
--
wloochacz
zpksoft
>
> Czy pisze się miksując HTML z czymś?
> Czy dynamicznie generuje się kod za pomocą tych klas?
> Czy na wyjściu, obligatoryjnie generowany jest HTML? Czy może XHTML? A
> może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
> transformowany do XHTML?
U mnie strony są traktowane podobnie jak okna aplikacji. Tak jak
projektując aplikację Win32 układasz na formatce kontrolki, tak u mnie
tworzysz strony w zwykłym html-u.
Serwer http reagując na żądania klienta przesyła mu odpowiednią
stronę, po odpowiedniej modyfikacji oczywiście (analogicznie jak w app
kontrolki wypełniane są treścią). Co do XML-a to nie gloryfikowałbym.
Każde rozwiązanie ma swój sens we właściwych ramach. XML wykorzystuję
do przekazywania danych z bazy (od serwera TCP) do pytacza (serwer
HTTP lub zdalna app). Po co mam przesyłać XML+XSLT do przeglądarki aby
ta mozolnie zrobiła z tego HTML jak mogę przesłać jej gotowca?
>
> No i mam małe pytanie do Pawła.
> Dlaczego tylko FB?
FB to baza danych. I tyle. Mogła by być dowolna inna, ale FB lubię :)
> Dlaczego własny system komunikacji (a nie np. XML-RPC czy SOAP)?
> Dlaczego nie np. DataAbstract + REMObjectsSDK (cobyś nie napisał, to
> jesteś sam a ich jest dużo; poza tym bawią się w to od dawna, poza tym -
> to jest naprawdę dobre)?
Nie wymyślam koła. Oparłem się na podstawowej komunikacji opracowanej
w Indy. To działa szybko i sprawnie. Reszta to logika aplikacji, a to
już tylko :) Delphi. Pod uwagę należało oczywiście wziąć nieciągłość
komunikacji i rozpracować sposób identyfikacji klienta.
Zrobiłem to b. prosto i działa szybko i dobrze.
>
> Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
Jak w Delphi :), tylko trochę trudniej- ale jak obuduje się wszystko w
odpowiednie obiekty to stopień trudności właściwie będzie taki sam,
Pozdrawiam- PAweł Krzyżanowski
darekm
> [ciach]
>>>> Przeglądarka o niebo bardziej przyszłościowa
>>> Pod warunkiem, że w końcu będzie dostępny interfejs a'la WindowsForms.
>>> A jedynym wyjściem są rozwiązania typu XUL czy WPF.
>> To nie jest dobre wyjście (o ile wiem o co chodzi) gdy tak dużo
>> zrzucimy na przeglądarkę to pewnie wydajność będzie lepsza ale
>> funkcjonalność ograniczona.
> No to nie wiesz o co chodzi. Bo właśnie funkcjonalność (zwłaszcza w
> wykonaniu WPF) jest nieograniczona. Taka aplikacja może być hostowana
> przez przeglądarkę, lub bu uruchomiona jak zwykła app.
Do jednego worka wrzuciłeś WPF i XUL a to zupełnie dwie różne idee.
Nieograniczona ? Jeżeli to ma chodzić przez przeglądarkę to jest nią
ograniczona. I ma wszystkie jej niedostatki plus własne.
>
>>> Bo, póki co to web jest może i ładny, ale do funkcjonalności to mu
>>> daleeeeko. A Ajax, imo, to jak polska reprezentacja; na początku było
>>> dobrze, były duże nadzieje i buńczuczne zapowiedzi, a teraz okazuje
>>> się że jest OK, ale nie wszędzie i nie do wszystkiego. A na pewno nie
>>> jest panaceum na wszystko.
>> Bo to nie o Ajax chodzi tylko o HTML. A ten jest całkiem dobry tylko
>> należy właściwie się do niego dobrać. Jednym z problemów jest
>> podejście: piszemy w Ajaxie a wg mnie część pisana w javascript
>> powinna być mikroskopijna
> Jest całkiem dobry, ale do tworzenie DOKUMENTÓW.
> A nie aplikacji.
Co nazywasz tworzeniem dokumentów bo chyba nie rozumiem porównania.
A co do aplikacji, to jeżeli sie uporam ze stabilnością, a wszystko
wskazuje że tak, to raczej nie widzę przeciwwskazań.
>
>>> Szczególnie tragikomicznie wyglądają Ajaxowe emulacje GUI grubego
>>> windowsa. To jest prawie podobne, ale prawie robi wielką różnicę.
Najpierw należy sobie odpowiedzieć na pytanie: "czy pisać pod
przeglądarkę" a dopiero potem jak.
>>
>> Tu narzuca się analogia przejścia z Dos na Win, na początku była
>> emulacja dopiero potem wypracowaną własną filozofię komunikacji z
>> użytkownikiem. Docelowo chodzi o to aby program również chodził na
>> palmtopach i mniejszych i większych urządzeniach, wystarczy że będzie
>> obecna przeglądarka
>>
>> Moje pytanie: dlaczego rozwiązania terminalowe nie zamierzają wyprzeć
>> przeglądarki z rynku, przecież bez zmiany kodu programu otrzymuje się
>> pełny działający program o szybkości działania porównywalnej z
>> przeglądarkami. Zamiast tego bogatsza część świata promuje aplikacje
>> webowe: google map, zope.com
> Ciężko mi nazwać google.map aplikacją to raczej przeglądarka.
> Co innego google eartch; dlaczego google zrobiło "normalną app"?
> Dlaczego? Dlatego,że przy obecnej technologii (głównie chodzi o ten
> najlepszy html 4.1), nie ma możliwości zastąpienia zwykłej app we
> wszystkich zastosowaniach. Oczywiście są radykałowie, którzy twierdzą
> inaczej, ale to piękna katastrofa jest a nie rozwiązanie.
We wszystkich nie. Z pewnością CAD i inne graficzne będzie ciężko, ale
wiekszość "bazodanowych" powinna się dać. Bo jeżeli da się zrobić coś
ala Word (patrz zope) to czemu nie dało by sie zrobić. I nie jest
właściwym pytanie "> Co innego google eartch; dlaczego google zrobiło
"normalną app"?" - tak zrobiłby każdy. Właśnie Google Map jest jedną z
pierwszych/popularniejszych bardziej zaawansowanych aplikacji webowych
i niejako stanowi proof of concept.
>
>>> Czy dynamicznie generuje się kod za pomocą tych klas?
>> Oczywiście
>>> Czy na wyjściu, obligatoryjnie generowany jest HTML?
>> Tak
>> Czy może XHTML? A
>> Na Firefoxie przeczytałem że na dzień dzisiejszy najlepsze rozwiązanie
>> to html v. 4.1
> Tzn. że Firefox ma monopol na rację?
Monopol nie, ale za nim stoi duuuże doświadczenie, w końcu sami piszą
obsługę.
>
>>> może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
>>> transformowany do XHTML?
>> 1. Po co
> Jak to "po co"?
> Po to, żeby uniezależnić się od warstwy prezentacji.
> Po to, że odpowiedni adapter generuje z tego np. HTML 4.1, a inny app
> windowsową w Delphi a jeszcze inny...
Marzenie ściętej głowy. Patrz: są problemy pomiędzy złym wyświetlaniem
tego samego kodu HTML na różnych przeglądarkach a Ty chcesz to uzyskać
na różnych adapterach. Jakie problemy są z wine, qt, gtk a to są
projekty tworzone od wielu, wielu lat.
>
>> 2. jak zejść do poziomu 100 ms czasu reakcji po modyfikacji strony,
>> jeżeli samej przeglądarce transformacja zajmie więcej (a gdzie czas
>> dla serwera i transmisję)
> Transformację to robić powinien silnik po stronie serwera, a nie
> przeglądarka.
Po stronie serwera mapujesz obiekty na HTML, w zasadzie nie ma problemu
aby to było XML - tylko po co (sam mówisz że jest problem z
funkcjonalnością - ja to odczytuje jako problem z uzyskaniem
odpowiedniego wyglądu/zachowania komponentu, a tu każdy pośrednik
nakłada własny gorset.
>
>>> Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
>>>
>> Oprócz ciekawej zabawy z "jądrem" reszta absolutnie bez zmian (to wina
>> mojego frameworka, ale jest to już jego czwarty system)
> Co to dokładnie znaczy - reszta praktycznie bez zmian?
Dosłownie. Zmieniam coś (dodaję nową funkcjonalność) bo potrzebuje dla
zwykłej aplikacji, potem kompiluję wersję webową i tam również to mam.
Zasada z FPC: jeden kod, natywna kompilacja na różne platformy.
> I - gdzie mogę zobaczyć demo, za pomocą którego mogę wyklikać prostą app
> bazodanową? ;)
Ja nie posiadam, w końcu nie jestem dostawcą narzędzi dla developerów.
> Czasem coś by się przydało napisać w www, ale odrzuca mnie jak widzę te
> wszystkie JS, HTML, PHP, CSS i co tam jeszcze wymyślą.
> Sorry, ale takiego burdelu to chyba nie ma nigdzie.
>
Nikt Ci nie każde.
Darek
Przemyslaw Osmanski
> Do jednego worka wrzuciłeś WPF i XUL a to zupełnie dwie różne idee.
Jak odmienne? Realizuja to samo zadanie. WPF, a uscislajac WPFE czyli
SilverLight daje dosc dowolne mozliwosci wykorzystania tego co
udostepnia (jesli chodzi o samo GUI). W tym konkretnym przykladzie XUL
to bardziej XAML, czyli jedna z czesci WPF/E.
Pozatym XUL ma wade (jak dla mnie) ze dziala tylko na mozillowych
przegladarkach. Na szczescie WPF/E dziala zarowno na IE jak i na
mozillowatych.
> "normalną app"?" - tak zrobiłby każdy. Właśnie Google Map jest jedną z
> pierwszych/popularniejszych bardziej zaawansowanych aplikacji webowych
> i niejako stanowi proof of concept.
Hmm... Ja jednak tez optowałbym za tym ze GoogleMap jest raczej
przegladarka niz webaplikacja.
pozdrawiam,
Przemek O.
zpksoft
> > sesji. Jeśli będzie zainteresowanie, mogę go opisać.
>
> Ja jestem ciekaw.
>
Psze bardzo:
- początek: serwer otrzymuje pytanie od klienta bez identyfikatora
sesji (lub z identyfikatorem nieaktualnym). Serwer zwraca stronę
logowania.
- gdy parametry logowania są poprawne, serwer zwraca stronę startową
zawierającą identyfikator sesji.
- user odpytuje po raz kolejny. Serwer sprawdza identyfikator sesji.
Jeżeli jest OK to reaguje właściwie, podając odpowiednią stronę (ew. z
danymi) zawierającą NOWY identyfikator sesji, jeżeli nie to powrót do
strony logowania z info, że sesja wygasła.
Taraz ów identyfikator:
- Nie stosuję cookies, więc nie ma zapisu na dysk klienta,
- Serwer nie pamięta identyfikatorów sesji, całe potrzebne info w nich
się zawiera.
- identyfikator sesji jest to zaszyfrowany i spakowany łańcuch znaków,
zawierający m. in:
-- znacznik czasu wygenerowania
-- identyfikator strony do której był podpięty
I tyle. Działa to znakomicie i jest odporne na hakerskie poczynania.
Jeżeli jakąś myśl miałbym rozszerzyć to pytaj.
Pozdrawiam,
Paweł Krzyżanwski
wloochacz
>> Czy pisze się miksując HTML z czymś?
>> Czy dynamicznie generuje się kod za pomocą tych klas?
>> Czy na wyjściu, obligatoryjnie generowany jest HTML? Czy może XHTML? A
>> może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
>> transformowany do XHTML?
>
> U mnie strony są traktowane podobnie jak okna aplikacji. Tak jak
> projektując aplikację Win32 układasz na formatce kontrolki, tak u mnie
> tworzysz strony w zwykłym html-u.
> Serwer http reagując na żądania klienta przesyła mu odpowiednią
> stronę, po odpowiedniej modyfikacji oczywiście (analogicznie jak w app
> kontrolki wypełniane są treścią). Co do XML-a to nie gloryfikowałbym.
> Każde rozwiązanie ma swój sens we właściwych ramach. XML wykorzystuję
> do przekazywania danych z bazy (od serwera TCP) do pytacza (serwer
> HTTP lub zdalna app). Po co mam przesyłać XML+XSLT do przeglądarki aby
> ta mozolnie zrobiła z tego HTML jak mogę przesłać jej gotowca?
dodatkowej warstwy, po stronie serwera, pomiędzy Klasa formatki (czy jak
to zwać) -> HTML.
Przenieść/wydzielić/odseparować funkcjonalność generowania HTMLa, tak
żeby można było wygenerować coś innego niż hmtl... Beż żadnych zmian.
>> No i mam małe pytanie do Pawła.
>> Dlaczego tylko FB?
>
> FB to baza danych. I tyle. Mogła by być dowolna inna, ale FB lubię :)
No co Ty nie powiesz, a ja myślałem że to skrót od FromBehind...
A poważnie - a co w przypadku jeśli potencjalny klient nie lubi FB?
Nic, idziemy gdzie indziej - ok, może być... ale...
>> Dlaczego własny system komunikacji (a nie np. XML-RPC czy SOAP)?
>> Dlaczego nie np. DataAbstract + REMObjectsSDK (cobyś nie napisał, to
>> jesteś sam a ich jest dużo; poza tym bawią się w to od dawna, poza tym -
>> to jest naprawdę dobre)?
>
> Nie wymyślam koła. Oparłem się na podstawowej komunikacji opracowanej
> w Indy.
Czyli jak? Sockety?
> To działa szybko i sprawnie.
Nie jest szpecem od indyków, ale z tego co wiem to indy !=
szybko_i_sprawnie.
Z ciekawości się zapytam - robiłeś testy regresyjne? Jak wyszły?
> Reszta to logika aplikacji, a to
> już tylko :) Delphi. Pod uwagę należało oczywiście wziąć nieciągłość
> komunikacji i rozpracować sposób identyfikacji klienta.
> Zrobiłem to b. prosto i działa szybko i dobrze.
>
>> Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
>
> Jak w Delphi :), tylko trochę trudniej- ale jak obuduje się wszystko w
> odpowiednie obiekty to stopień trudności właściwie będzie taki sam,
Ooook... załóżmy, że tak jest. Czy to rozwiązanie pozwala na napisanie,
za jednym zamachem app Win32 i Web?
--
wloochacz
wloochacz
> wloochacz pisze:
>> [ciach]
>>>>> Przeglądarka o niebo bardziej przyszłościowa
>>>> Pod warunkiem, że w końcu będzie dostępny interfejs a'la WindowsForms.
>>>> A jedynym wyjściem są rozwiązania typu XUL czy WPF.
>>> To nie jest dobre wyjście (o ile wiem o co chodzi) gdy tak dużo
>>> zrzucimy na przeglądarkę to pewnie wydajność będzie lepsza ale
>>> funkcjonalność ograniczona.
>> No to nie wiesz o co chodzi. Bo właśnie funkcjonalność (zwłaszcza w
>> wykonaniu WPF) jest nieograniczona. Taka aplikacja może być hostowana
>> przez przeglądarkę, lub bu uruchomiona jak zwykła app.
>
> Do jednego worka wrzuciłeś WPF i XUL a to zupełnie dwie różne idee.
> Nieograniczona ? Jeżeli to ma chodzić przez przeglądarkę to jest nią
> ograniczona. I ma wszystkie jej niedostatki plus własne.
Na pewno wiesz jak działa WPF i SilverLight?
Albo inaczej - co mają ograniczenia przeglądarki do WPF/E.
Ale jescze inaczej - jakie ograniczenia masz na myśli, bo już nie wiem o
co cho...
>>>> Bo, póki co to web jest może i ładny, ale do funkcjonalności to mu
>>>> daleeeeko. A Ajax, imo, to jak polska reprezentacja; na początku
>>>> było dobrze, były duże nadzieje i buńczuczne zapowiedzi, a teraz
>>>> okazuje się że jest OK, ale nie wszędzie i nie do wszystkiego. A na
>>>> pewno nie jest panaceum na wszystko.
>>> Bo to nie o Ajax chodzi tylko o HTML. A ten jest całkiem dobry tylko
>>> należy właściwie się do niego dobrać. Jednym z problemów jest
>>> podejście: piszemy w Ajaxie a wg mnie część pisana w javascript
>>> powinna być mikroskopijna
>
>> Jest całkiem dobry, ale do tworzenie DOKUMENTÓW.
>> A nie aplikacji.
> Co nazywasz tworzeniem dokumentów bo chyba nie rozumiem porównania.
> A co do aplikacji, to jeżeli sie uporam ze stabilnością, a wszystko
> wskazuje że tak, to raczej nie widzę przeciwwskazań.
Dokument to, jak sama nazwa wskazuje, HTML;
Cała reszta, to próba uczynienia z wielbłąda konia.
Poziom interakcji aplikacji www, NIE opartej na idei XAML jest, wybacz,
mizerny; a problemów z tą transformacją wielbłąda w konia jest naprawdę
nieciekawie sporo.
No to zdefiniuj proszę "aplikacja webowa", bo ja jej w Google maps wiele
nie widzę.
>>>> Czy dynamicznie generuje się kod za pomocą tych klas?
>>> Oczywiście
>>>> Czy na wyjściu, obligatoryjnie generowany jest HTML?
>>> Tak
>>> Czy może XHTML? A
>>> Na Firefoxie przeczytałem że na dzień dzisiejszy najlepsze
>>> rozwiązanie to html v. 4.1
>> Tzn. że Firefox ma monopol na rację?
> Monopol nie, ale za nim stoi duuuże doświadczenie, w końcu sami piszą
> obsługę.
>>
>>>> może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
>>>> transformowany do XHTML?
>>> 1. Po co
>> Jak to "po co"?
>> Po to, żeby uniezależnić się od warstwy prezentacji.
>> Po to, że odpowiedni adapter generuje z tego np. HTML 4.1, a inny app
>> windowsową w Delphi a jeszcze inny...
> Marzenie ściętej głowy. Patrz: są problemy pomiędzy złym wyświetlaniem
> tego samego kodu HTML na różnych przeglądarkach a Ty chcesz to uzyskać
> na różnych adapterach. Jakie problemy są z wine, qt, gtk a to są
> projekty tworzone od wielu, wielu lat.
Widzisz, problemy z interpretacją na różnych przeglądarkach, wydaje się
być idealną propozycją do załatwienia za pomocą takich właśnie adapterów.
>>> 2. jak zejść do poziomu 100 ms czasu reakcji po modyfikacji strony,
>>> jeżeli samej przeglądarce transformacja zajmie więcej (a gdzie czas
>>> dla serwera i transmisję)
>> Transformację to robić powinien silnik po stronie serwera, a nie
>> przeglądarka.
> Po stronie serwera mapujesz obiekty na HTML, w zasadzie nie ma problemu
> aby to było XML - tylko po co (sam mówisz że jest problem z
> funkcjonalnością - ja to odczytuje jako problem z uzyskaniem
> odpowiedniego wyglądu/zachowania komponentu, a tu każdy pośrednik
> nakłada własny gorset.
>>
>>>> Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
>>>>
>>> Oprócz ciekawej zabawy z "jądrem" reszta absolutnie bez zmian (to
>>> wina mojego frameworka, ale jest to już jego czwarty system)
>> Co to dokładnie znaczy - reszta praktycznie bez zmian?
> Dosłownie. Zmieniam coś (dodaję nową funkcjonalność) bo potrzebuje dla
> zwykłej aplikacji, potem kompiluję wersję webową i tam również to mam.
> Zasada z FPC: jeden kod, natywna kompilacja na różne platformy.
Czyli piszemy jedną i tą samą aplikację, a potem wybieramy tylko i
wyłącznie cel (windows/web) gdzie to ma działać?
Czy tak? Żadnego babarania się w htmlu, javascripcie i czym tam jeszcze?
>> I - gdzie mogę zobaczyć demo, za pomocą którego mogę wyklikać prostą
>> app bazodanową? ;)
> Ja nie posiadam, w końcu nie jestem dostawcą narzędzi dla developerów.
To nagraj za pomocą winka :)
>> Czasem coś by się przydało napisać w www, ale odrzuca mnie jak widzę
>> te wszystkie JS, HTML, PHP, CSS i co tam jeszcze wymyślą.
>> Sorry, ale takiego burdelu to chyba nie ma nigdzie.
>>
> Nikt Ci nie każde.
Każe może nie, ale czasem prosi ;)
--
wloochacz
darekm
>> ograniczona. I ma wszystkie jej niedostatki plus własne.
> Na pewno wiesz jak działa WPF i SilverLight?
> Albo inaczej - co mają ograniczenia przeglądarki do WPF/E.
> Ale jescze inaczej - jakie ograniczenia masz na myśli, bo już nie wiem o
> co cho...
Jeżli piszemy dla przeglądarki to komunikujemy się z nią via
HTML+CSS+JavaScript. I tak robi każdy: PHP, WPF czy cokolwiek. jeżeli
ktoś potrafi coś wyswietlić/animować, a do tego sprowadza się pisanie
aplikacji, to musi to zrobić via HTML... i może to również zrobić jego,
powiedzmy konkurent. A z warstwami pośredniczącymi jest tak że nie
zawsze wszystko potrafią.
A ograniczenia, głównie wynikają z idei działania przeglądarki. Przede
wszystkim jest ona bezstanowa, bez połączeniowa (tak jak protokół HTTP)
i to doskwiera w bardzo wielu momentach (np. okienka modalne typu dialog
tak/nie). Po drugie trochę ograniczone jest manipulowanie elementami
graficznymi, choć jak zobaczyłem edytor tekstowy typu WYSIWYG via
przeglądarka to może się jednak da.
>
>>>>> Bo, póki co to web jest może i ładny, ale do funkcjonalności to mu
>>>>> daleeeeko. A Ajax, imo, to jak polska reprezentacja; na początku
>>>>> było dobrze, były duże nadzieje i buńczuczne zapowiedzi, a teraz
>>>>> okazuje się że jest OK, ale nie wszędzie i nie do wszystkiego. A na
>>>>> pewno nie jest panaceum na wszystko.
>>>> Bo to nie o Ajax chodzi tylko o HTML. A ten jest całkiem dobry tylko
>>>> należy właściwie się do niego dobrać. Jednym z problemów jest
>>>> podejście: piszemy w Ajaxie a wg mnie część pisana w javascript
>>>> powinna być mikroskopijna
>>
>>> Jest całkiem dobry, ale do tworzenie DOKUMENTÓW.
>>> A nie aplikacji.
>> Co nazywasz tworzeniem dokumentów bo chyba nie rozumiem porównania.
>> A co do aplikacji, to jeżeli sie uporam ze stabilnością, a wszystko
>> wskazuje że tak, to raczej nie widzę przeciwwskazań.
> Dokument to, jak sama nazwa wskazuje, HTML;
> Cała reszta, to próba uczynienia z wielbłąda konia.
> Poziom interakcji aplikacji www, NIE opartej na idei XAML jest, wybacz,
> mizerny; a problemów z tą transformacją wielbłąda w konia jest naprawdę
> nieciekawie sporo.
Tu się nie zgodzę. Oczywiście że nie da się zrobić interaktywnego GUI
na samym HTML, ale po to jest JavaScript aby tym "dokumentem" manipulować.
I dalej będę oponować przeciwko kolejnej warstwie. Przecież w Delphi
mamy jedną: VCL. Patrz ile musi być zrobione aby się tego równie łatwo
używało co rozszerzało. A to co jest generowane (VCL generuje do winapi,
LCL generuje do Gtk, QT, a moja biblioteka do HTML) to kwestia
biblioteki. Zamiana VCL na WPF czy cokolwiek innego to raczej założenie
gorsetu.
Wyłącznie na niniejsze potrzeby: interaktywne GUI wykraczające poza
wypełnienie pojedynczego formularza. I nie ma znaczenia czy to jest już
jest aplikacja czy też nie. Dla mnie ma znaczenie to, że jest tam
pokazany szereg koncepcji koniecznych do budowy pełnokrwistych aplikacji.
A upieram się wyłącznie Google Map bo jest znane i często cytowane, nie
każcie mi go bronić. Zajrzyjcie proszę na zope, to również wg Was nie
jest aplikacja webowa? Ale też nie jestem ich adwokatem
>>>
>>>>> może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
>>>>> transformowany do XHTML?
>>>> 1. Po co
>>> Jak to "po co"?
>>> Po to, żeby uniezależnić się od warstwy prezentacji.
>>> Po to, że odpowiedni adapter generuje z tego np. HTML 4.1, a inny app
>>> windowsową w Delphi a jeszcze inny...
>> Marzenie ściętej głowy. Patrz: są problemy pomiędzy złym wyświetlaniem
>> tego samego kodu HTML na różnych przeglądarkach a Ty chcesz to uzyskać
>> na różnych adapterach. Jakie problemy są z wine, qt, gtk a to są
>> projekty tworzone od wielu, wielu lat.
> Widzisz, problemy z interpretacją na różnych przeglądarkach, wydaje się
> być idealną propozycją do załatwienia za pomocą takich właśnie adapterów.
W cuda to ja nie wierzę. Dlaczego taki adapter (nowy) miałby działać
lepiej niż podstawa (tworzona od np.10 lat).
>>>>> Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
>>>>>
>>>> Oprócz ciekawej zabawy z "jądrem" reszta absolutnie bez zmian (to
>>>> wina mojego frameworka, ale jest to już jego czwarty system)
>>> Co to dokładnie znaczy - reszta praktycznie bez zmian?
>> Dosłownie. Zmieniam coś (dodaję nową funkcjonalność) bo potrzebuje dla
>> zwykłej aplikacji, potem kompiluję wersję webową i tam również to mam.
>> Zasada z FPC: jeden kod, natywna kompilacja na różne platformy.
> Czyli piszemy jedną i tą samą aplikację, a potem wybieramy tylko i
> wyłącznie cel (windows/web) gdzie to ma działać?
> Czy tak? Żadnego babarania się w htmlu, javascripcie i czym tam jeszcze?
Tak
>
>>> I - gdzie mogę zobaczyć demo, za pomocą którego mogę wyklikać prostą
>>> app bazodanową? ;)
>> Ja nie posiadam, w końcu nie jestem dostawcą narzędzi dla developerów.
> To nagraj za pomocą winka :)
Jak coś wykroję to pokażę.
Darek
darekm
>>> Nie stosuję cookies do identyfikacji klienta tylko własny mechanizm
>>> sesji. Jeśli będzie zainteresowanie, mogę go opisać.
>> Ja jestem ciekaw.
> - Nie stosuję cookies, więc nie ma zapisu na dysk klienta,
> - Serwer nie pamięta identyfikatorów sesji, całe potrzebne info w nich
> się zawiera.
> - identyfikator sesji jest to zaszyfrowany i spakowany łańcuch znaków,
> zawierający m. in:
> -- znacznik czasu wygenerowania
> -- identyfikator strony do której był podpięty
Darek
darekm
> [ciach]
>>> Czy pisze się miksując HTML z czymś?
>>> Czy dynamicznie generuje się kod za pomocą tych klas?
>>> Czy na wyjściu, obligatoryjnie generowany jest HTML? Czy może XHTML? A
>>> może bezpośrednio (ja bym tak zrobił ;-) do XML, który jest
>>> transformowany do XHTML?
>>
>> U mnie strony są traktowane podobnie jak okna aplikacji. Tak jak
>> projektując aplikację Win32 układasz na formatce kontrolki, tak u mnie
>> tworzysz strony w zwykłym html-u.
możesz przesłać taki jeden moduł aby się zorientować jak to jest zrobione?
>> Serwer http reagując na żądania klienta przesyła mu odpowiednią
>> stronę, po odpowiedniej modyfikacji oczywiście (analogicznie jak w app
>> kontrolki wypełniane są treścią). Co do XML-a to nie gloryfikowałbym.
>> Każde rozwiązanie ma swój sens we właściwych ramach. XML wykorzystuję
>> do przekazywania danych z bazy (od serwera TCP) do pytacza (serwer
>> HTTP lub zdalna app). Po co mam przesyłać XML+XSLT do przeglądarki aby
>> ta mozolnie zrobiła z tego HTML jak mogę przesłać jej gotowca?
> Przez Was obu zostałem zrozumiany opacznie; chodziło mi o wprowadzenie
> dodatkowej warstwy, po stronie serwera, pomiędzy Klasa formatki (czy jak
> to zwać) -> HTML.
> Przenieść/wydzielić/odseparować funkcjonalność generowania HTMLa, tak
> żeby można było wygenerować coś innego niż hmtl... Beż żadnych zmian.
>
Napisałem w poprzednim poście: taką warstwą jest VCL, a właściwie jego API.
Darek
zpksoft
Rodzaj bazy to nie problem. Poza tym wszyscy moi klienci lubią FB :))
> Nie jest szpecem od indyków, ale z tego co wiem to indy !=
> szybko_i_sprawnie.
> Z ciekawości się zapytam - robiłeś testy regresyjne? Jak wyszły?
Nie robiłem żadnych testów. Moje aplikacje przesyłają duże ilości
informacji (dokumenty) a tego już nie zoptymalizuję. Internet jaki
jest każdy widzi:) Nie widzę więc sensu szukania dziury w całym
optymalizując np. inicjowanie wysyłki, kiedy sam proces transportu
prze Internet jest o wiele dłuższy (i nezależny od zastosowanej
technologii)
> Czy to rozwiązanie pozwala na napisanie,
> za jednym zamachem app Win32 i Web?
Nie. Uniwersalność kończy się na serwerze TCP generującym XML-e.
Dalej jest albo Win32 albo serwer http.
Wybacz, ale łączenie tych rzeczy jest absolutnie bez sensu. To jakby
tworzenie jednej uniwersalnej linii produkcyjnej dla samochodów i
samolotów.
Paweł
zpksoft
> >> U mnie strony są traktowane podobnie jak okna aplikacji. Tak jak
> >> projektując aplikację Win32 układasz na formatce kontrolki, tak u mnie
> >> tworzysz strony w zwykłym html-u.
>
> możesz przesłać taki jeden moduł aby się zorientować jak to jest zrobione?
Przesłać moduł to może nie :) ale mogę opisać jak to działa. Bardzo
prosto:
serwer http w zdarzeniu CommandGet obsługuje "pętlę komunikatów":
procedure TForm1.IdHTTPServer1CommandGet(AThread: TIdPeerThread;
ARequestInfo: TIdHTTPRequestInfo; AResponseInfo:
TIdHTTPResponseInfo);
begin
...
//odczytuję zwrócony identyfikator sesji:
oldIDS:=ARequestInfo.Params.Values['IDS'];
//sprawdzam identyfikator sesji, jeśli niewłaściwy, np przeterminowany
to wywołanie okna logowania)
if not checkIDS(oldIDS) then html_result:=windowLog(ARequestInfo)
else if okno='menu' then html_result:=windowMenu(ARequestInfo)
else if okno='...
...
//tworzę nowy identyfikator sesji:
newIDS:=IDS;
//uzupełniam html o ten identyfikator:
updateParam(html_result, 'IDS', newIDS);
//i odsyłam do przeglądarki:
AResponseInfo.ContentText:=html_result;
end;
a teraz przykładowe tworzenie okna, szablon jest już gotowy w html-u:
function TForm1.windowMenu(ARequestInfo: TIdHTTPRequestInfo): string;
begin
...
result:=loadStringFromFile('html\menu.htm'); //inicjacja okna
//uwzględnienie tego co user zwrócił:
updateParamsReq(result, ARequestInfo);
//ew. dodanie czegoś od siebie :)
...
end;
I tyle. Proste jak drut :). Oczywiście zamiast czytania gotowca z
pliku można go tworzyć ad hoc ale po co?
Czytającym ten post zwrócę jeszcze uwagę na jedną rzecz: w tym
rozwiązaniu nie potrzeba definiować roota, budować uprawnień do
podfolderów, instalować IIS czy Apache itp. To program zwany serwerem
http przez określony port komunikuje się z klientem (przeglądarką) i
daje mu to, co uważa za stosowne. W tym ujęciu jesteśmy bliżej Win32
niż serwera www.
Pozdrawiam- Paweł Krzyżanowski
zpksoft
> > - Nie stosuję cookies, więc nie ma zapisu na dysk klienta,
> > - Serwer nie pamięta identyfikatorów sesji, całe potrzebne info w nich
> > się zawiera.
>
> to skąd wie z której sesji przychodzi zapytanie?> -
A po co mu taka informacja?. Początkowo sądziłem, że serwer musi
pamiętać listę uruchomionych sesji. Doszedłem jednak szybko do
wniosku, że nie jest to mu do niczego potrzebne.
Identyfikator sesji z każdą odpowiedzią serwera jest inny (chociażby z
tej przyczyny, że znacznik czasu jest uaktualniany). Wysłany
identyfikator do serwera jest zwracany wraz z kolejnym pytaniem.
Serwer weryfikuje ów zwrócony identyfikator.
identyfikator sesji jest to zaszyfrowany i spakowany łańcuch znaków,
> > zawierający m. in:
> > -- znacznik czasu wygenerowania
> > -- identyfikator strony do której był podpięty
>
> Czy ten identyfikator zapisywany jest w linii URL?
W obecnej chwili tak (jest to jeden z parametrów). Ale to tylko sprawa
techniczna. Chcę uzyskać efekt stałego adresu. Początkowo chciałem
zrobić ramkę na całą stronę ale podsunąłeś mi inny pomysł :) -
wykorzystanie Ajaxa.
Paweł
darekm
>>> - Nie stosuję cookies, więc nie ma zapisu na dysk klienta,
>>> - Serwer nie pamięta identyfikatorów sesji, całe potrzebne info w nich
>>> się zawiera.
>> to skąd wie z której sesji przychodzi zapytanie?> -
>
> A po co mu taka informacja?. Początkowo sądziłem, że serwer musi
> pamiętać listę uruchomionych sesji. Doszedłem jednak szybko do
> wniosku, że nie jest to mu do niczego potrzebne.
pamiętanym stanem wszystkich okien
> Identyfikator sesji z każdą odpowiedzią serwera jest inny (chociażby z
> tej przyczyny, że znacznik czasu jest uaktualniany). Wysłany
> identyfikator do serwera jest zwracany wraz z kolejnym pytaniem.
> Serwer weryfikuje ów zwrócony identyfikator.
>
> identyfikator sesji jest to zaszyfrowany i spakowany łańcuch znaków,
>>> zawierający m. in:
>>> -- znacznik czasu wygenerowania
>>> -- identyfikator strony do której był podpięty
>> Czy ten identyfikator zapisywany jest w linii URL?
>
> W obecnej chwili tak (jest to jeden z parametrów). Ale to tylko sprawa
Tak widziałem że jest robione w WT toolkit, ale tylko jeżeli
przeglądarka nie obsługuje cookie
> techniczna. Chcę uzyskać efekt stałego adresu. Początkowo chciałem
> zrobić ramkę na całą stronę ale podsunąłeś mi inny pomysł :) -
> wykorzystanie Ajaxa.
jak chcesz to skorzystaj z mojego modułu
emadar.eu:8001/ajax1.js
do niego wysyła się dane do podmiany ekranu w postaci
identyfikator pola || zawartosc innerhtml <|>identyfikator pola ||
zawartosc innerhtml <|>identyfikator pola || zawartosc innerhtml <|>
itd.
oczywiście jest już kilka innych wariantów: podmiana całego ekranu, okno
wyskakujące itp
Darek
darekm
>>>> U mnie strony są traktowane podobnie jak okna aplikacji. Tak jak
>>>> projektując aplikację Win32 układasz na formatce kontrolki, tak u mnie
>>>> tworzysz strony w zwykłym html-u.
>> możesz przesłać taki jeden moduł aby się zorientować jak to jest zrobione?
>
> Przesłać moduł to może nie :) ale mogę opisać jak to działa. Bardzo
> prosto:
>
> serwer http w zdarzeniu CommandGet obsługuje "pętlę komunikatów":
>
> procedure TForm1.IdHTTPServer1CommandGet(AThread: TIdPeerThread;
> ARequestInfo: TIdHTTPRequestInfo; AResponseInfo:
> TIdHTTPResponseInfo);
> begin
to robię tak samo, tyle że przerobiłem na synapse bo lepiej działało
> ...
> //odczytuję zwrócony identyfikator sesji:
> oldIDS:=ARequestInfo.Params.Values['IDS'];
> ...
> result:=loadStringFromFile('html\menu.htm'); //inicjacja okna
A to jest generowane automatycznie na podstawie utworzonych elementów
a'la VCL
ręczny HTML jest tylko w menu głównym i logowaniu
Darek
wloochacz
>> A poważnie - a co w przypadku jeśli potencjalny klient nie lubi FB?
>
> Rodzaj bazy to nie problem. Poza tym wszyscy moi klienci lubią FB :))
pełnego ORMa. A nie masz, bo piszesz w Delphi...
No chyba, że ta baza to kilka tabel na krzyż, to wtedy faktycznie nie
problem...
>> Nie jest szpecem od indyków, ale z tego co wiem to indy !=
>> szybko_i_sprawnie.
>> Z ciekawości się zapytam - robiłeś testy regresyjne? Jak wyszły?
>
> Nie robiłem żadnych testów. Moje aplikacje przesyłają duże ilości
> informacji (dokumenty) a tego już nie zoptymalizuję. Internet jaki
> jest każdy widzi:) Nie widzę więc sensu szukania dziury w całym
> optymalizując np. inicjowanie wysyłki, kiedy sam proces transportu
> prze Internet jest o wiele dłuższy (i nezależny od zastosowanej
> technologii)
>
>> Czy to rozwiązanie pozwala na napisanie,
>> za jednym zamachem app Win32 i Web?
>
> Nie. Uniwersalność kończy się na serwerze TCP generującym XML-e.
> Dalej jest albo Win32 albo serwer http.
OK. Z tego co widzę napisałeś coś, co jest podobne do DataAbstract i
REMObjects SDK + IntraWeb.
Hmm...
> Wybacz, ale łączenie tych rzeczy jest absolutnie bez sensu. To jakby
> tworzenie jednej uniwersalnej linii produkcyjnej dla samochodów i
> samolotów.
Bez sensu? Powiedz to Twórcom Magica.
Twórcom, przez wielkie T.
Bez sensu, imo, jest klepanie tego samego dwukrotnie, z wykorzystaniem
różnych technologii, tylko dlatego że ma działać w przeglądarce i jako
desktop.
No, ale (chyba) ja mam specyficzne wymagania.
--
wloochacz
wloochacz
>>> Nieograniczona ? Jeżeli to ma chodzić przez przeglądarkę to jest nią
>>> ograniczona. I ma wszystkie jej niedostatki plus własne.
>> Na pewno wiesz jak działa WPF i SilverLight?
>> Albo inaczej - co mają ograniczenia przeglądarki do WPF/E.
>> Ale jescze inaczej - jakie ograniczenia masz na myśli, bo już nie wiem
>> o co cho...
>
> Jeżli piszemy dla przeglądarki to komunikujemy się z nią via
> HTML+CSS+JavaScript. I tak robi każdy: PHP, WPF czy cokolwiek. jeżeli
> ktoś potrafi coś wyswietlić/animować, a do tego sprowadza się pisanie
> aplikacji, to musi to zrobić via HTML... i może to również zrobić jego,
> powiedzmy konkurent. A z warstwami pośredniczącymi jest tak że nie
> zawsze wszystko potrafią.
>
> A ograniczenia, głównie wynikają z idei działania przeglądarki. Przede
> wszystkim jest ona bezstanowa, bez połączeniowa (tak jak protokół HTTP)
> i to doskwiera w bardzo wielu momentach (np. okienka modalne typu dialog
> tak/nie). Po drugie trochę ograniczone jest manipulowanie elementami
> graficznymi, choć jak zobaczyłem edytor tekstowy typu WYSIWYG via
> przeglądarka to może się jednak da.
Chciałbyś mieć IDE w przeglądarce? W życiu, chyba że wywali się tego
htmla... Ale to będzie bardziej przypominać XAMla lub TSRemoteAPP.
>>>>>> Bo, póki co to web jest może i ładny, ale do funkcjonalności to mu
>>>>>> daleeeeko. A Ajax, imo, to jak polska reprezentacja; na początku
>>>>>> było dobrze, były duże nadzieje i buńczuczne zapowiedzi, a teraz
>>>>>> okazuje się że jest OK, ale nie wszędzie i nie do wszystkiego. A
>>>>>> na pewno nie jest panaceum na wszystko.
>>>>> Bo to nie o Ajax chodzi tylko o HTML. A ten jest całkiem dobry
>>>>> tylko należy właściwie się do niego dobrać. Jednym z problemów jest
>>>>> podejście: piszemy w Ajaxie a wg mnie część pisana w javascript
>>>>> powinna być mikroskopijna
>>>
>>>> Jest całkiem dobry, ale do tworzenie DOKUMENTÓW.
>>>> A nie aplikacji.
>>> Co nazywasz tworzeniem dokumentów bo chyba nie rozumiem porównania.
>>> A co do aplikacji, to jeżeli sie uporam ze stabilnością, a wszystko
>>> wskazuje że tak, to raczej nie widzę przeciwwskazań.
>> Dokument to, jak sama nazwa wskazuje, HTML;
>> Cała reszta, to próba uczynienia z wielbłąda konia.
>> Poziom interakcji aplikacji www, NIE opartej na idei XAML jest,
>> wybacz, mizerny; a problemów z tą transformacją wielbłąda w konia jest
>> naprawdę nieciekawie sporo.
> Tu się nie zgodzę. Oczywiście że nie da się zrobić interaktywnego GUI
> na samym HTML, ale po to jest JavaScript aby tym "dokumentem" manipulować.
Wg mojej opinii, to JS jest czymś co właśnie z wielbłąda ma zrobić
konia. To po prostu jest zlepek technologii, które nie były projektowane
do działania wspólnie. Im szybciej to umrze, tym lepiej - ale chyba
nieprędko.
> I dalej będę oponować przeciwko kolejnej warstwie. Przecież w Delphi
> mamy jedną: VCL. Patrz ile musi być zrobione aby się tego równie łatwo
> używało co rozszerzało. A to co jest generowane (VCL generuje do winapi,
> LCL generuje do Gtk, QT, a moja biblioteka do HTML) to kwestia
> biblioteki. Zamiana VCL na WPF czy cokolwiek innego to raczej założenie
> gorsetu.
Eeeh... to że coś działa jak w Delphi, nie znaczy że tak jest dobrze.
A VCL to był dobry, ale 10 lat temu (albo i 15). Co się zmieniło w VCL
od 10 lat?
I między innymi z tego powodu, że w Delphi jest jedna warstwa, powstały
takie hocki klocki jak IntraWeb... Na marginesie, zupełnie nie rozumiem
dlaczego DFMy są zapisane w czymś takim, a nie np. w XMLu? Który łątwo
parsować i generować go jak i na jego podstawie.
Co do gorsetu - ok, to Twój projekt. Uważam zupełnie inaczej i widzę, że
nie bardzo się rozumiemy - ale nie szkodzi.
Mam wrażenie że nie rozumiesz mnie zupełnie...
Nie nowy, w sensie kodu, tylko nowy w sensie idei działania, czyli coś
na kształt tego:
TAdapterVCL = class(TInterfacedObjects, IGUIAdapter);
TAdapterWWW = class(TInterfacedObjects, IGUIAdapter);
TServer = class;
property : Adapter : IGUIAdapter;
i tak dalej...
>>>>>> Generalnie idea ciekawa i jestem ciekaw jak się w tym pisze :)
>>>>>>
>>>>> Oprócz ciekawej zabawy z "jądrem" reszta absolutnie bez zmian (to
>>>>> wina mojego frameworka, ale jest to już jego czwarty system)
>>>> Co to dokładnie znaczy - reszta praktycznie bez zmian?
>>> Dosłownie. Zmieniam coś (dodaję nową funkcjonalność) bo potrzebuje
>>> dla zwykłej aplikacji, potem kompiluję wersję webową i tam również to
>>> mam. Zasada z FPC: jeden kod, natywna kompilacja na różne platformy.
>> Czyli piszemy jedną i tą samą aplikację, a potem wybieramy tylko i
>> wyłącznie cel (windows/web) gdzie to ma działać?
>> Czy tak? Żadnego babarania się w htmlu, javascripcie i czym tam jeszcze?
> Tak
O!
>>>> I - gdzie mogę zobaczyć demo, za pomocą którego mogę wyklikać prostą
>>>> app bazodanową? ;)
>>> Ja nie posiadam, w końcu nie jestem dostawcą narzędzi dla developerów.
>> To nagraj za pomocą winka :)
>
> Jak coś wykroję to pokażę.
Czekam z niecierpliwością :)
--
wloochacz
zpksoft
> > pamiętać listę uruchomionych sesji. Doszedłem jednak szybko do
> > wniosku, że nie jest to mu do niczego potrzebne.
>
> wg mnie jest potrzebne, po prostu sesja to jakby samodzielna aplikacja z
> pamiętanym stanem wszystkich okien
Właśnie z tego zrezygnowałem. Po co pamiętać stan wszystkich okien?
Należy tak napisać app aby to nie było potrzebne :)
W każdym razie zostawiłem sobie furtkę na przypadek, gdybym jednak
tego potrzebował.
>...
> > Chcę uzyskać efekt stałego adresu. Początkowo chciałem
> > zrobić ramkę na całą stronę ale podsunąłeś mi inny pomysł :) -
> > wykorzystanie Ajaxa.
>
> jak chcesz to skorzystaj z mojego modułu
> emadar.eu:8001/ajax1.js
chętnie spojrzę, dzięki :)
>...
> oczywiście jest już kilka innych wariantów: podmiana całego ekranu, okno
> wyskakujące itp
Osobiście nienawidzę wyskakujący okien, więc ich nie stosuję :)
Paweł
zpksoft
> [ciach]>> A poważnie - a co w przypadku jeśli potencjalny klient nie lubi FB?
>
> > Rodzaj bazy to nie problem. Poza tym wszyscy moi klienci lubią FB :))
>
> W bajki to ja nie wierzę. Wiesz kiedy to nie problem? Wtedy kiedy masz
> pełnego ORMa. A nie masz, bo piszesz w Delphi...
> No chyba, że ta baza to kilka tabel na krzyż, to wtedy faktycznie nie
> problem...
>
yhm
>
> OK. Z tego co widzę napisałeś coś, co jest podobne do DataAbstract i
> REMObjects SDK + IntraWeb.
> Hmm...
Do IntraWeb podchodziłem 2x (!) i odrzuciłem z dwóch powodów:
- strona w przeglądarce nie wygląda tak jak w IDE, tzn. rozjeżdża się.
- nie mam pełnej kontroli nad kodem
Poza tym IntraWeb to CGI lub ISAPI, wymaga IIS, Apache lub tp. W moim
przypadku jest to autonomiczny serwer HTTP.
>...
Pozdrawiam- Paweł Krzyżanowski
zpksoft
> konia. To po prostu jest zlepek technologii, które nie były projektowane
> do działania wspólnie. Im szybciej to umrze, tym lepiej - ale chyba
> nieprędko.
zauważ że mowe technologie, jak ASP.NET właśnie opierają się głównie
na JS. Nawet MS spłodził specjalnie dla JS rozszerzenia typu
XMLHttpRequest(),
z czego wynika, że JS raczej się rozwinie (i bardzo dobrze :)
Paweł
darekm
>> wszystkim jest ona bezstanowa, bez połączeniowa (tak jak protokół
>> HTTP) i to doskwiera w bardzo wielu momentach (np. okienka modalne
>> typu dialog tak/nie). Po drugie trochę ograniczone jest manipulowanie
>> elementami graficznymi, choć jak zobaczyłem edytor tekstowy typu
>> WYSIWYG via przeglądarka to może się jednak da.
> Jaki jest poziomi usability tego w porównaniu ze "zwykłym" edytorem.
> Chciałbyś mieć IDE w przeglądarce? W życiu, chyba że wywali się tego
> htmla... Ale to będzie bardziej przypominać XAMla lub TSRemoteAPP.
Najprościej było by uruchomić sesje terminalowe, przecież to działa i
nic nie trzeba robić. Pytanie dlaczego się nie przyjęło
>> Tu się nie zgodzę. Oczywiście że nie da się zrobić interaktywnego GUI
>> na samym HTML, ale po to jest JavaScript aby tym "dokumentem"
>> manipulować.
> Wg mojej opinii, to JS jest czymś co właśnie z wielbłąda ma zrobić
> konia. To po prostu jest zlepek technologii, które nie były projektowane
> do działania wspólnie. Im szybciej to umrze, tym lepiej - ale chyba
> nieprędko.
j.w.
ale mamy to co mamy i ekosystem wokół przeglądarek rozwija się w tempie
wykładniczym
>
>> I dalej będę oponować przeciwko kolejnej warstwie. Przecież w Delphi
>> mamy jedną: VCL. Patrz ile musi być zrobione aby się tego równie łatwo
>> używało co rozszerzało. A to co jest generowane (VCL generuje do
>> winapi, LCL generuje do Gtk, QT, a moja biblioteka do HTML) to kwestia
>> biblioteki. Zamiana VCL na WPF czy cokolwiek innego to raczej
>> założenie gorsetu.
> Eeeh... to że coś działa jak w Delphi, nie znaczy że tak jest dobrze.
> A VCL to był dobry, ale 10 lat temu (albo i 15). Co się zmieniło w VCL
> od 10 lat?
Z jednej stroni nic z drugiej wszystko. Przecież wiesz ile różnych
programów/komponentów zrobiono w Delphi, sam też pewnie uważasz że
Delphi to jedno z najlepszych narzędzi do programów z GUI, a to oparte
jest o VCL. Z resztą wiele innych bibliotek ma podobną strukturę.
> I między innymi z tego powodu, że w Delphi jest jedna warstwa, powstały
> takie hocki klocki jak IntraWeb... Na marginesie, zupełnie nie rozumiem
wg tego co wiem (choć niewiele sprawdzałem) to idea IntraWeb jest
podobna do mojej, czyli komponenty z API analogicznym do VCL ale
generują kod HTML. Tyle że jest to jeszcze cięższe od Indy, a jakie jest
Indy to wiemy.
> dlaczego DFMy są zapisane w czymś takim, a nie np. w XMLu? Który łątwo
> parsować i generować go jak i na jego podstawie.
Byłem przekonany że są w XML, przynajmiej nowsze(nie wiem bo nie używam)
> Co do gorsetu - ok, to Twój projekt. Uważam zupełnie inaczej i widzę, że
> nie bardzo się rozumiemy - ale nie szkodzi.
Inaczej nie było by dyskusji.
>>
>> W cuda to ja nie wierzę. Dlaczego taki adapter (nowy) miałby działać
>> lepiej niż podstawa (tworzona od np.10 lat).
> Mam wrażenie że nie rozumiesz mnie zupełnie...
> Nie nowy, w sensie kodu, tylko nowy w sensie idei działania, czyli coś
> na kształt tego:
>
> TAdapterVCL = class(TInterfacedObjects, IGUIAdapter);
> TAdapterWWW = class(TInterfacedObjects, IGUIAdapter);
>
> TServer = class;
> property : Adapter : IGUIAdapter;
>
> i tak dalej...
Ale to trzeba napisać i to bezbłędnie. Znasz coś bardziej
skomplikowanego co tak działa, jakieś dobre wieloplatformowe bibioteki,
które bez problemu i identycznie działają na wszystkich wspieranych
obszarach. Podałem całą serię (wine, qt, gtk, lazarus, X) ale żadne nie
działa perfekcyjnie.
Darek
darekm
>>> Początkowo sądziłem, że serwer musi
>>> pamiętać listę uruchomionych sesji. Doszedłem jednak szybko do
>>> wniosku, że nie jest to mu do niczego potrzebne.
>> wg mnie jest potrzebne, po prostu sesja to jakby samodzielna aplikacja z
>> pamiętanym stanem wszystkich okien
>
> Właśnie z tego zrezygnowałem. Po co pamiętać stan wszystkich okien?
> Należy tak napisać app aby to nie było potrzebne :)
Duża aplikacja bez stanu okien ....?
>> ...
>> oczywiście jest już kilka innych wariantów: podmiana całego ekranu, okno
>> wyskakujące itp
>
> Osobiście nienawidzę wyskakujący okien, więc ich nie stosuję :)
czasami są potrzebne np. okno z raportem w PDF które powinno sie
otwierać obok
tworzę też okienka nałożone np. pytanie tak nie nałożone na środku okna
i takie tam
Darek
wloochacz
> zauważ że mowe technologie, jak ASP.NET właśnie opierają się głównie
> na JS. Nawet MS spłodził specjalnie dla JS rozszerzenia typu
> XMLHttpRequest(),
> z czego wynika, że JS raczej się rozwinie (i bardzo dobrze :)
To jest nowy (już nie nowy, XMLHttpRequest jest od dawna raczej...)
sposób na zrobienia wielbłąda koniem.
Nowa technologia to np. WPF/E, imo.
--
wloochacz
wloochacz
>>> Przede wszystkim jest ona bezstanowa, bez połączeniowa (tak jak
>>> protokół HTTP) i to doskwiera w bardzo wielu momentach (np. okienka
>>> modalne typu dialog tak/nie). Po drugie trochę ograniczone jest
>>> manipulowanie elementami graficznymi, choć jak zobaczyłem edytor
>>> tekstowy typu WYSIWYG via przeglądarka to może się jednak da.
>> Jaki jest poziomi usability tego w porównaniu ze "zwykłym" edytorem.
>> Chciałbyś mieć IDE w przeglądarce? W życiu, chyba że wywali się tego
>> htmla... Ale to będzie bardziej przypominać XAMla lub TSRemoteAPP.
>
> Najprościej było by uruchomić sesje terminalowe, przecież to działa i
> nic nie trzeba robić. Pytanie dlaczego się nie przyjęło
IMO technologie terminalowe mają się bardzo dobrze i dobrze sie
rozwijają. Wystarczy popatrzeć na features Terminal Services 2008.
Problem polega na czym innym, a mianowicie na kosztach - TS jest po
prostu dość drogi w naszych realiach, dla małego klienta.
Z drugiej strony, takie technologie jakie proponujecie tańsze nie są, bo
przecież rozwój tego sam się nie robi, no ale klient nie musi wydać
dodatkowo XXX tyś na licencje za terminale...
>>> Tu się nie zgodzę. Oczywiście że nie da się zrobić interaktywnego
>>> GUI na samym HTML, ale po to jest JavaScript aby tym "dokumentem"
>>> manipulować.
>> Wg mojej opinii, to JS jest czymś co właśnie z wielbłąda ma zrobić
>> konia. To po prostu jest zlepek technologii, które nie były
>> projektowane do działania wspólnie. Im szybciej to umrze, tym lepiej -
>> ale chyba nieprędko.
> j.w.
> ale mamy to co mamy i ekosystem wokół przeglądarek rozwija się w tempie
> wykładniczym
>
>
>>
>>> I dalej będę oponować przeciwko kolejnej warstwie. Przecież w Delphi
>>> mamy jedną: VCL. Patrz ile musi być zrobione aby się tego równie
>>> łatwo używało co rozszerzało. A to co jest generowane (VCL generuje
>>> do winapi, LCL generuje do Gtk, QT, a moja biblioteka do HTML) to
>>> kwestia biblioteki. Zamiana VCL na WPF czy cokolwiek innego to raczej
>>> założenie gorsetu.
>> Eeeh... to że coś działa jak w Delphi, nie znaczy że tak jest dobrze.
>> A VCL to był dobry, ale 10 lat temu (albo i 15). Co się zmieniło w VCL
>> od 10 lat?
> Z jednej stroni nic z drugiej wszystko.
A konkret jakiś?
NIC się nie zmieniło, poza kosmetyką.
> Przecież wiesz ile różnych
> programów/komponentów zrobiono w Delphi, sam też pewnie uważasz że
> Delphi to jedno z najlepszych narzędzi do programów z GUI, a to oparte
> jest o VCL. Z resztą wiele innych bibliotek ma podobną strukturę.
Tak/Nie.
Tak - ma podobną.
Nie - nie chodzi mi o to co widać w VCL, ale o to czego nie widać.
Temat najprostszy - obsługa wszystkich zdarzeń jako model delegacyjny,
podobnie jak w .NET
Klepaczom ta zmiana się do niczego nie przyda, ale komuś kto buduje duże
systemy przez agregację istniejącego kodu, jest wręcz niezbędna.
>> I między innymi z tego powodu, że w Delphi jest jedna warstwa,
>> powstały takie hocki klocki jak IntraWeb... Na marginesie, zupełnie
>> nie rozumiem
> wg tego co wiem (choć niewiele sprawdzałem) to idea IntraWeb jest
> podobna do mojej, czyli komponenty z API analogicznym do VCL ale
> generują kod HTML. Tyle że jest to jeszcze cięższe od Indy, a jakie jest
> Indy to wiemy.
>> dlaczego DFMy są zapisane w czymś takim, a nie np. w XMLu? Który łątwo
>> parsować i generować go jak i na jego podstawie.
> Byłem przekonany że są w XML, przynajmiej nowsze(nie wiem bo nie używam)
Nie są i nigdy nie były; bodajże od D6 można zapisywać w wersji
tekstowej. Ale to nie jest XML. A z drugiej strony producent IDE nie
udostępnia odpowiedniego parsera.
A wszyscy na MS narzekają...
>> Co do gorsetu - ok, to Twój projekt. Uważam zupełnie inaczej i widzę,
>> że nie bardzo się rozumiemy - ale nie szkodzi.
> Inaczej nie było by dyskusji.
>
>>>
>>> W cuda to ja nie wierzę. Dlaczego taki adapter (nowy) miałby działać
>>> lepiej niż podstawa (tworzona od np.10 lat).
>> Mam wrażenie że nie rozumiesz mnie zupełnie...
>> Nie nowy, w sensie kodu, tylko nowy w sensie idei działania, czyli coś
>> na kształt tego:
>>
>> TAdapterVCL = class(TInterfacedObjects, IGUIAdapter);
>> TAdapterWWW = class(TInterfacedObjects, IGUIAdapter);
>>
>> TServer = class;
>> property : Adapter : IGUIAdapter;
>>
>> i tak dalej...
> Ale to trzeba napisać i to bezbłędnie. Znasz coś bardziej
> skomplikowanego co tak działa, jakieś dobre wieloplatformowe bibioteki,
> które bez problemu i identycznie działają na wszystkich wspieranych
> obszarach. Podałem całą serię (wine, qt, gtk, lazarus, X) ale żadne nie
> działa perfekcyjnie.
Ale przecież nie chodzi o to końcową implementację, tylko o sposób
realizacji tego zadania. Taki jak podałem jest dla mnie
najnaturalniejszy i najbardziej elastyczny.
Przecież możesz mieć tylko jedną implementację dla IGUIAdapter, którą
de-facto masz :)
--
wloochacz
zpksoft
a dlaczego nie?
app obsługuje zdarzenia i tyle. Po co przechowywać widoki klienta?
>
> >> ...
> >> oczywiście jest już kilka innych wariantów: podmiana całego ekranu, okno
> >> wyskakujące itp
>
> > Osobiście nienawidzę wyskakujący okien, więc ich nie stosuję :)
>
> czasami są potrzebne np. okno z raportem w PDF które powinno sie
> otwierać obok
> tworzę też okienka nałożone np. pytanie tak nie nałożone na środku okna
> i takie tam
>
> Darek
Miałem na myśli reklamy :)
Szczególnie wredne są te których nie można zamknąć i płyną wraz ze
scrollowaniem strony uniemożliwiając jej czytanie. Po co to robią ?
Paweł.
wloochacz
>
> a dlaczego nie?
> app obsługuje zdarzenia i tyle. Po co przechowywać widoki klienta?
W ogóle nie rozumiem pytania :)
Załóżmy, że klient postawia jakieś parametry na oknie i nie chciałby ich
ustawiać znów, przy ponownym uruchomieniu tego okna.
Czyli, chciałby, że system zachował stan okna w kontekście użytkownika.
I co?
>>>> ...
>>>> oczywiście jest już kilka innych wariantów: podmiana całego ekranu, okno
>>>> wyskakujące itp
>>> Osobiście nienawidzę wyskakujący okien, więc ich nie stosuję :)
>> czasami są potrzebne np. okno z raportem w PDF które powinno sie
>> otwierać obok
>> tworzę też okienka nałożone np. pytanie tak nie nałożone na środku okna
>> i takie tam
Chyba na jedno wychodzi...
>> Darek
>
> Miałem na myśli reklamy :)
> Szczególnie wredne są te których nie można zamknąć i płyną wraz ze
> scrollowaniem strony uniemożliwiając jej czytanie. Po co to robią ?
Jak to po co? Dla pieniędzy oczywiście :)
--
wloochacz
marfi
news:6230b55e-40fc-436d...@f63g2000hsf.googlegroups.com...
Miałem na myśli reklamy :)
Szczególnie wredne są te których nie można zamknąć i płyną wraz ze
scrollowaniem strony uniemożliwiając jej czytanie. Po co to robią ?
W moim przypadku tylko po to aby nigdy na taką stronę nie zaglądać jeżeli
AdBlock sobie ze śmieciem nie poradzi :)
BTW: Pisz w jakimś formacie który pozwala zaznaczać cytowanie bo nie chce mi
się tego robić ręcznie..
--
marfi
darekm
>>>> A ograniczenia, głównie wynikają z idei działania przeglądarki.
>>>> Przede wszystkim jest ona bezstanowa, bez połączeniowa (tak jak
>>>> protokół HTTP) i to doskwiera w bardzo wielu momentach (np. okienka
>>>> modalne typu dialog tak/nie). Po drugie trochę ograniczone jest
>>>> manipulowanie elementami graficznymi, choć jak zobaczyłem edytor
>>>> tekstowy typu WYSIWYG via przeglądarka to może się jednak da.
>>> Jaki jest poziomi usability tego w porównaniu ze "zwykłym" edytorem.
>>> Chciałbyś mieć IDE w przeglądarce? W życiu, chyba że wywali się tego
>>> htmla... Ale to będzie bardziej przypominać XAMla lub TSRemoteAPP.
>>
>> Najprościej było by uruchomić sesje terminalowe, przecież to działa i
>> nic nie trzeba robić. Pytanie dlaczego się nie przyjęło
> A skąd twierdzenie, że się nie przyjęło?
znacznie większym tempie.
> IMO technologie terminalowe mają się bardzo dobrze i dobrze sie
> rozwijają. Wystarczy popatrzeć na features Terminal Services 2008.
> Problem polega na czym innym, a mianowicie na kosztach - TS jest po
> prostu dość drogi w naszych realiach, dla małego klienta.
również absolutny brak konieczności instalowania czegokolwiek u klienta.
> Z drugiej strony, takie technologie jakie proponujecie tańsze nie są, bo
> przecież rozwój tego sam się nie robi, no ale klient nie musi wydać
> dodatkowo XXX tyś na licencje za terminale...
Rozwijać i tak trzeba (bo jak sam wiesz klient tego chce a konkurencja
nie śpi), wiadomo koszty migracji są ale w dłuższym okresie się
minimalizują.
Już pisałem że dobrze by było aby CodeGear dodał coś do języka.
> Klepaczom ta zmiana się do niczego nie przyda, ale komuś kto buduje duże
> systemy przez agregację istniejącego kodu, jest wręcz niezbędna.
>
>>> dlaczego DFMy są zapisane w czymś takim, a nie np. w XMLu? Który
>>> łątwo parsować i generować go jak i na jego podstawie.
>> Byłem przekonany że są w XML, przynajmiej nowsze(nie wiem bo nie używam)
> Nie są i nigdy nie były; bodajże od D6 można zapisywać w wersji
> tekstowej. Ale to nie jest XML. A z drugiej strony producent IDE nie
> udostępnia odpowiedniego parsera.
OK, ale parser już się da napisać.
> A wszyscy na MS narzekają...
>
>>> Co do gorsetu - ok, to Twój projekt. Uważam zupełnie inaczej i widzę,
>>> że nie bardzo się rozumiemy - ale nie szkodzi.
>> Inaczej nie było by dyskusji.
>>
>>>>
>>>> W cuda to ja nie wierzę. Dlaczego taki adapter (nowy) miałby działać
>>>> lepiej niż podstawa (tworzona od np.10 lat).
>>> Mam wrażenie że nie rozumiesz mnie zupełnie...
>>> Nie nowy, w sensie kodu, tylko nowy w sensie idei działania, czyli
>>> coś na kształt tego:
>>>
>>> TAdapterVCL = class(TInterfacedObjects, IGUIAdapter);
>>> TAdapterWWW = class(TInterfacedObjects, IGUIAdapter);
>>>
>>> TServer = class;
>>> property : Adapter : IGUIAdapter;
>>>
>>> i tak dalej...
>> Ale to trzeba napisać i to bezbłędnie. Znasz coś bardziej
>> skomplikowanego co tak działa, jakieś dobre wieloplatformowe
>> bibioteki, które bez problemu i identycznie działają na wszystkich
>> wspieranych obszarach. Podałem całą serię (wine, qt, gtk, lazarus, X)
>> ale żadne nie działa perfekcyjnie.
> Ale przecież nie chodzi o to końcową implementację, tylko o sposób
> realizacji tego zadania. Taki jak podałem jest dla mnie
> najnaturalniejszy i najbardziej elastyczny.
> Przecież możesz mieć tylko jedną implementację dla IGUIAdapter, którą
> de-facto masz :)
Tyle że trzeba by było przebudować całą bibliotekę na co nie mam siły.
Poza tym gdzie tu masz kolejną warstwę (w takim sensie jak WPF),
przecież to tylko VCL zaimplementowany na interfejsach. Podobną
konstrukcję zastosowano w Lazarusie w LCL, może nie interfejsy, bo wtedy
jeszcze ich nie było w FPC ale coś ala.
Darek
zpksoft
>uuu... dziwne.
>W ogóle nie rozumiem pytania :)
>Załóżmy, że klient postawia jakieś parametry na oknie i nie chciałby ich
>ustawiać znów, przy ponownym uruchomieniu tego okna.
>Czyli, chciałby, że system zachował stan okna w kontekście >użytkownika.
>I co?
Właśnie do tego służy AJAX. Jeżeli chcesz coś dosłać do strony usera
bez przeładowywania mu jej to używasz j/w,
Poza tym uważam, że aplikacja przeglądarkowa to nie Win32 i nie należy
próbować tworzenia kopii z podobną funkcjonalnością. Dla mnie swego
rodzaju wzorcem są aplikacje bankowe. Potrzebuję tylko kilka
drobiazgów więcej, jak np. przesyłanie binarnych dokumentów w obie
strony.
darekm opierając się na AJAX-ie oparł się człkowicie na jednej
formatce. Można i tak, jednak uważam że można zapędzić się w kozi róg
zbytnio komplikując jedną formatkę.
> > Miałem na myśli reklamy :)
> > Szczególnie wredne są te których nie można zamknąć i płyną wraz ze
> > scrollowaniem strony uniemożliwiając jej czytanie. Po co to robią ?
>
> Jak to po co? Dla pieniędzy oczywiście :)
>
Oczywiście. Zadałem głupie pytanie :)
Paweł
zpksoft
> się tego robić ręcznie..
> --
> marfi
piszę bezpośrednio z Googli, więc to chyba u Ciebie jest coś nie tak,
bo u mnie każdy post inicjuje się automatycznie od cytatu zaznaczonego
">"
Paweł
marfi
Pewnie, Google rządzą... To włącz im jeszcze MIME tak jak ja i inni i
będzie OK :)
--
marfi
marfi
news:g3guqo$54n$1...@news.onet.pl...
> Pewnie, Google rządzą... To włącz im jeszcze MIME tak jak ja i inni i
> będzie OK :)
Przepraszam... nie sprawdziłem dokładnie i napisałem głupoty :(
Nie wiem dlaczego "Poczta systemu Windows" z Vista 64 nie potrafi
poprawnie zacytować Twoich listów...
--
marfi
PaSkol
>> Pisz w jakimś formacie który pozwala zaznaczać cytowanie bo nie chce mi
>> się tego robić ręcznie..
> piszę bezpośrednio z Googli, więc to chyba u Ciebie jest coś nie tak,
> bo u mnie każdy post inicjuje się automatycznie od cytatu zaznaczonego
Wszystkie "przeglądarkowe" programy pocztowe mają tę nieciekawą właściwość,
że kodują polskie znaki w "quoted-printable", a z tym nie radzi sobie od
dawien dawna ani Outlook Express, ani Windows Mail.
Quoted jest nadmiarowe - na jeden znak narodowy przypadają trzy znaki ASCII,
pomijam, że cały tekst musi być dodatkowo dopakowany specjalnymi
separatorami.
--
PaSkol
---=== Każdy usenetowy chwat z Netykietą za pan brat ===---
---=== http://www.pg.gda.pl/~agatek/netq.html ===---