Temat: komunikacja miedzy oknami

Witam ponownie
Pisze nie stronę a aplikacje działającą w przeglądarce Ciągnę z serwera dość dużo danych ajaxem
i wnerwia mnie trochę że jak z jednego okna otwieram link do drugiego okna to po pierwsze nie mogę (tzn może nie potrafię) przekazać jakichś parametrów bezpośrednio, po drugie boli mnie że nowe okno znowu musi "ciągnąć" dane które już na tym komputerze są.

Częściowo mogę to obejść robiąc pseudo okno ale nie zawsze mi to problem rozwiązuje.

Marzyła by mi się architektura 3warstwowa - coś ala lokalna hurtownia danych która ciągnie dane na komputer lokalny a wszystkie przeglądarki mają do niech dostęp.
Czy taki numer jest do zrobienia ?

Temat: komunikacja miedzy oknami

Może flashowe cookie pomoże? http://en.wikipedia.org/wiki/Local_shared_object

Albo Dojo Storage
http://pl.wikipedia.org/wiki/Dojo_Toolkit#Przechowywan...Karol Ciba edytował(a) ten post dnia 21.06.12 o godzinie 12:47

Temat: komunikacja miedzy oknami

WebStorage - trochę kulawe, ale do zaimplementowania
WebSockets - Socket.IO z Node.js (szczególnie do realtime apps)

Temat: komunikacja miedzy oknami

Wojciech Mazurek:

Marzyła by mi się architektura 3warstwowa - coś ala lokalna hurtownia danych która ciągnie dane na komputer lokalny a wszystkie przeglądarki mają do niech dostęp.
Czy taki numer jest do zrobienia ?

Lata temu miałem podobny problem. (Prezentowanie danych z maszyn z produkcji.) Napisałem własną przeglądarkę w QT. Dodałem komunikacje z serwerami (gdzieś rozrzucone po halach), a wyświetlane było za pomocą zwykłej strony. Inne dane były już przez zwykły serwer www (rozliczenia produkcji czy plany itp). Okna dokowalne w głównej aplikacji(tej od komunikacji), można sobie wsadzić gdzie się chce.
To rozwiązanie ma jedną wadę. Następna przeglądarka www w systemie. Tyle że inne przeglądarki zakładają pełną izolacje stron.
Kiedyś też popełniłem coś w rodzaju lokalnego proxy. Przeglądarki łączyły się lokalnie a resztę załatwiał serwis.

Temat: komunikacja miedzy oknami

Maurycy Mikulski:

Wojciech Mazurek:

Marzyła by mi się architektura 3warstwowa - coś ala lokalna hurtownia danych która ciągnie dane na komputer lokalny a wszystkie przeglądarki mają do niech dostęp.

Lata temu miałem podobny problem. (Prezentowanie danych z maszyn z produkcji.) Napisałem własną przeglądarkę w QT.

No ja mam podobnie;)
W tej chwili to się dopiero uczę tak pisania usług serwerowych (choć na razie mam prosty serwer wbudowany w aplikację) jak i JS i ogólnie programowania po stronie przeglądarki.
Na początek chcę mojego halla przenieść do przeglądarki ale docelowo ma ten los podzielić mój Golem OEE a ten jest na architekturze pseudo 3 warstwowej - tzn jest oddzielny serwer aplikacyjny który zasila klientów danymi - serwer SQL nie wyrabiał (notabene jak robiłem eksperymanty z odpytywaniem serwera SQL w tempie 10 zapisów i 100 odczytów na sekundę to zrozumiałem dlaczego przemysłowe bazy SQL są takie drogie i dla czego potrzebują tak silnych komputerów)
Jednak dla mnie sens migracji z aplikacją do przeglądarki jest między innymi wtedy kiedy nie będzie wymagana żadna interwencja w komputery klienckie - czyste przeglądarki bez żadnych dodatków - inaczej taka migracja traci sens - własny klient http/sql zawsze będzie 100 razy lepszy od przeglądarki ;)

Temat: komunikacja miedzy oknami

No to masz problem.
Z przeglądarką zrobisz wiele rzeczy ale nie zrobisz synoptyki.
Będziesz miał inne wskazania na sąsiednim komputerze ale i na tm samym w dwóch oknach.
Co do timerów masz też problem. W każdej działają inaczej a najgorzej co nie trudno zgadnąć w IE.
Słowem wszystko w przeglądarce ale nie synoptyki. Z definicji to co będzie pokazane jest jakimś stanem czegoś sprzed czegoś a nie bieżącym.

Coś czasu temu na zad. Pewien operator stwierdził ,że z nowego programu nie korzystają ale z mojego bo to tak jakby stare porshe zamienić na fiata pande. Stare ale wyścigowe , panda nowa ale nie ta klasa.
Chodziło o zmianę systemów. Część danych trafiła do nowego sytemu rozliczeń ( z trudem dającym sobie radę z wymianą danych co 1 min - stary dawał wymianę co parę sekund) ale nowy był oparty o przeglądarkę a więc lepszy.
Kontrahent do którego trafiały dane miał do mnie pretensję ,że czas nie ten ,że dane nie dają się porównać i parę innych. Tylko dla czego do mnie a nie do twórców nowego systemu. szczególnie ,że tam nie pracuje. (dlaczego nie to inna historia związana z prywatyzacją).

Słowem z przeglądarkami nie wiele zdziałasz choć pokibicuje.
Robiliśmy w podobnej dziedzinie. Ja byłem wcześniej i już przerobiłem dawno parę pomysłów (skutecznie i mniej).
Ty miałeś szczęście i możesz kontynuować.

Pozdrawiam i życzę szczęścia.

Wojciech Mazurek:

Maurycy Mikulski:

Wojciech Mazurek:

Marzyła by mi się architektura 3warstwowa - coś ala lokalna hurtownia danych która ciągnie dane na komputer lokalny a wszystkie przeglądarki mają do niech dostęp.

Lata temu miałem podobny problem. (Prezentowanie danych z maszyn z produkcji.) Napisałem własną przeglądarkę w QT.

No ja mam podobnie;)
W tej chwili to się dopiero uczę tak pisania usług serwerowych (choć na razie mam prosty serwer wbudowany w aplikację) jak i JS i ogólnie programowania po stronie przeglądarki.
Na początek chcę mojego halla przenieść do przeglądarki ale docelowo ma ten los podzielić mój Golem OEE a ten jest na architekturze pseudo 3 warstwowej - tzn jest oddzielny serwer aplikacyjny który zasila klientów danymi - serwer SQL nie wyrabiał (notabene jak robiłem eksperymanty z odpytywaniem serwera SQL w tempie 10 zapisów i 100 odczytów na sekundę to zrozumiałem dlaczego przemysłowe bazy SQL są takie drogie i dla czego potrzebują tak silnych komputerów)
Jednak dla mnie sens migracji z aplikacją do przeglądarki jest między innymi wtedy kiedy nie będzie wymagana żadna interwencja w komputery klienckie - czyste przeglądarki bez żadnych dodatków - inaczej taka migracja traci sens - własny klient http/sql zawsze będzie 100 razy lepszy od przeglądarki ;)

Temat: komunikacja miedzy oknami

jesli zrobisz popup, to jest to mozliwe (nie mowie o otworzeniu nowej zakladki) ;)

Temat: komunikacja miedzy oknami

Maurycy Mikulski:
No to masz problem.
Z przeglądarką zrobisz wiele rzeczy ale nie zrobisz synoptyki.
Będziesz miał inne wskazania na sąsiednim komputerze ale i na tm samym w dwóch oknach.

A to czemu? Przeglądarka nie ma robić żadnej logiki - może wstępną walidację przy wprowadzaniu danych i ewentualne "bajery".
Pisząc aplikację desktop czy nawet Client-Serwer ciężko zachować paradygmat rozdzielenia warstwy logiki od warstwy prezentacji. Tworzenie aplikacji działającej w przeglądarce niemal wymusza taki rozdział.

Co do timerów masz też problem. W każdej działają inaczej a najgorzej co nie trudno zgadnąć w IE.
Słowem wszystko w przeglądarce ale nie synoptyki. Z definicji to co będzie pokazane jest jakimś stanem czegoś sprzed czegoś a nie bieżącym.

Ale timery w przeglądarce są mi potrzebne tylko i wyłącznie do odświeżania widoków.
Dla przykładu wykresy trendów będą dostarczane do przeglądarki jako obrazki kreowane przez serwer aplikacyjny (to już mam) albo jako tablica gotowych danych które JS ma tylko odrysować.
Jako że wszystko w założeniu działa w sieci lokalnej a Ajax zwalnia nas od przeładowywania całej strony to odświeżanie widoku co sekundę nie stanowi żadnego problemu.

Inna rzecz że jeśli chodzi o mojego MESa to cała analiza pozostanie w gestii klasycznych programów. Zrobienie programu który by analizował dane, sporządzał raporty, wykresy, rozbił eksporty itp itd nadal i pewnie jeszcze długo będzie zdecydowanie większym wydatkiem - albo w sensie czasu na przygotowanie logiki i kodu JS albo w sensie zakupu odpowiednich komponentów - a powiem koledze że znalazłem już w sieci takie wynalazki do robienia np grafiki prezentacyjnej że szczęka opada - niestety - najbardziej przy cenie ;)))))

Poza tym no way - przyszłością produkcji i logistyki są tablety a przeniesienie części softu do przeglądarki wydaje się być najprostszym sposobem tworzenia aplikacji je wspierających.

Temat: komunikacja miedzy oknami

Zrobienie programu który by analizował dane, sporządzał raporty, wykresy, rozbił eksporty itp itd
nadal i pewnie jeszcze długo będzie zdecydowanie większym wydatkiem -

niekoniecznie. Jeśli chodzi o wykresy to masz darmowe Google Charts
https://developers.google.com/chart/

Druga opcja to rezygnacja z JavaScript i przejście na Flexa. Czyli ściągasz darmowy Flex SDK ze strony Adobe (bądź pobierasz Flash Builder, ale nie wiem jak z jego ceną). W każdym razie we Flexie jest wszystko - wykresy, samoaktualizujące się tabelki danych, komponenty do definiowania usług internetowych (a więc - de facto łączenia się z internetem, z tym, że jest to o wiele bardziej sprytne).

Pisząc aplikację desktop czy nawet Client-Serwer ciężko zachować paradygmat rozdzielenia
warstwy logiki od warstwy prezentacji. Tworzenie aplikacji działającej w przeglądarce niemal
wymusza taki rozdział.

No tak, ale kazanie serwerowi rysować wykres to właśnie złamanie tego rozdziału...

Dla przykładu wykresy trendów będą dostarczane do przeglądarki jako obrazki
kreowane przez serwer aplikacyjny (to już mam) albo jako tablica gotowych
danych które JS ma tylko odrysować.

Cóż...
Transfer: obrazek ~30kB. tablica gotowych danych w JSON: ~1kB.
Zasoby serwera:
tablica danych - koszt zapytania SQL
tworzenie wykresu po stronie serwera - koszt zapytania SQL + narysowanie obrazka

Dla mnie arytmetyka jest tutaj prosta.

Jako że wszystko w założeniu działa w sieci lokalnej a Ajax zwalnia nas od przeładowywania
całej strony to odświeżanie widoku co sekundę nie stanowi żadnego problemu.

jak działa w sieci lokalnej, to może by zrobić z tego projekt AIR i odpalać w ogóle bez przeglądarki, mając dostęp do lokalnych plików na dysku?
http://www.adobe.com/pl/products/air.html

Poza tym: "Adobe AIR includes a SQL-based relational database engine that runs within the runtime, with data stored locally in database files on the computer on which the AIR application runs (for example, on the computer's hard drive). Because the database runs and data files are stored locally, a database can be used by an AIR application regardless of whether a network connection is available."

I "The LocalConnection class enables communications between AIR applications, as well as among AIR applications and SWF content running in the browser."

Co chyba rozwiązuje ten problem:

Pisze nie stronę a aplikacje działającą w przeglądarce Ciągnę z serwera dość
dużo danych ajaxem i wnerwia mnie trochę że jak z jednego okna otwieram link do
drugiego okna to po pierwsze nie mogę (tzn może nie potrafię) przekazać jakichś parametrów
bezpośrednio, po drugie boli mnie że nowe okno znowu musi "ciągnąć" dane które już na tym
komputerze są.

Temat: komunikacja miedzy oknami

Łukasz Lityński:

Pisząc aplikację desktop czy nawet Client-Serwer ciężko zachować paradygmat rozdzielenia
warstwy logiki od warstwy prezentacji. Tworzenie aplikacji działającej w przeglądarce niemal
wymusza taki rozdział.

No tak, ale kazanie serwerowi rysować wykres to właśnie złamanie tego rozdziału...

Dla przykładu wykresy trendów będą dostarczane do przeglądarki jako obrazki
kreowane przez serwer aplikacyjny (to już mam) albo jako tablica gotowych
danych które JS ma tylko odrysować.

Cóż...
Transfer: obrazek ~30kB. tablica gotowych danych w JSON: ~1kB.
Zasoby serwera:
tablica danych - koszt zapytania SQL
tworzenie wykresu po stronie serwera - koszt zapytania SQL + narysowanie obrazka

Paradygmat to nie dogmat ;)))0
Dane i ich tworzenie jest oddzielone od ich prezentacji choć oczywiście w prezentacje zaangażowany jest też serwer. W życiu nic nie jest czarno białe...
Zresztą wiele profesjonalnych komponentów do prezentacji danych które używa HTML5 czy SilverLight ma też opcję kreowania widoków w jpegach dla słabych urządzeń.