Dnia Thu, 20 Dec 2012 21:13:39 +0100, Marek napisał(a):

> Przykład przetwarzania formularza:
> (...)

Ale Ty chcesz najwyraźniej odtworzyć proces obsługi formularza w
narzędziu, które ma zupełnie inną filozofię działania. Widać to po tych
kombinacjach z przekierowaniami. Przyjmij, że masz do dyspozycji tylko
zapytanie-odpowiedź i świat stanie się prostszy.

> No wysyłam do modułu A ale ten w odpowiedzi nie może wygenerować
> przekierowania na inny URL bo wysłałby je nie do przeglądarki lecz do JS.

Zgadza się, więc całą logikę sterującą formularzem musisz zaszyć w JS (ew.
po prostu wyświetlać co zwraca serwer). Nie ma lekko, zachciało się
ajaksów, to trzeba cierpieć ;)

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

W dniu 2012-12-22 17:02, Tomasz Sowa pisze:
> On 2012.12.22 16:39, Marek wrote:
>
> Ja u siebie robie tak, normalne requesty:
> http://www.domain.tld/cos/gdzies
> a ajaxem dodaje sobie parametr:
> http://www.domain.tld/cos/gdzies/type:ajax
>
> i tutaj sobie zwracam albo jsona albo kawalek htmla z 'srodka' strony,
> no więc masz racje, te urle są różne ;)

Właśnie tak teraz sam zaczynam kombinować. Nawet pal sześć różne URLe
lecz wymaga to (tak jak pisaliśmy już) innego podejścia
programistycznego w obsłudze transakcji. De facto jeśli do tej pory URL
= moduł, to teraz 1 URL = 2 moduły (1 dla Ajaxa, a 2gi dla tradycyjnego
requesta) zachowujące się odmiennie z punktu widzenia systemu. Nie jest
istotne czy rozdzielisz "adresowanie" modułu URLem, parametrem czy
nagłówkiem. Wymagane jest oddzielna obsługa.

do góry

W dniu 2012-12-22 21:38, Borys Pogoreło pisze:

> Wystarczy pilnować nagłówka X-Requested-With, wiekszość bibliotek dodaje
> go automatycznie.

Nie sprawdzałem: goły Ajax też ustawia ten nagłówek? Nie stosuję
bibliotek. Metoda wydaje mi się sprytna i w tym kierunku pójdę. Dzięki
za podpowiedź :-)

do góry

W dniu 2012-12-22 21:42, Borys Pogoreło pisze:

> Ale Ty chcesz najwyraźniej odtworzyć proces obsługi formularza

Nooo... masz rację.

> w
> narzędziu, które ma zupełnie inną filozofię działania. Widać to po tych
> kombinacjach z przekierowaniami. Przyjmij, że masz do dyspozycji tylko
> zapytanie-odpowiedź i świat stanie się prostszy.

Musisz mi to na polski przełożyć :-) Prawie wszystko co robię to jest
formularz: wpisz imię, nazwisko etc. Oczywiście od strony Ajax'a nie
będę robił submitowania lecz będę zbierał mozolnie dane i wysyłał do
serwera, co ten może traktować jako dane z formularza właśnie. Odpowiedź
serwera odpowiednio po tym pseudo-formularzu będę dystrybuował.

Zależy mi na tym aby serwer zwracał HTML przede wszystkim. Chodzi o
możliwość budowania i modyfikowania wyglądu okien w edytorach WYSIWYG.
Zapewne dojdą inne formy komunikacji w miarę potrzeb ale bazą chcę
uczynić HTML.

Czy takie podejście może być jeszcze łatwiejsze? Czy nie utrudniam sobie
czegoś?

>
>> No wysyłam do modułu A ale ten w odpowiedzi nie może wygenerować
>> przekierowania na inny URL bo wysłałby je nie do przeglądarki lecz do JS.
>
> Zgadza się, więc całą logikę sterującą formularzem musisz zaszyć w JS (ew.
> po prostu wyświetlać co zwraca serwer). Nie ma lekko, zachciało się
> ajaksów, to trzeba cierpieć ;)

A pewnie, że tak :-) No i podpytuję teraz o minimalizację bólu :-D

do góry

W dniu 2012-12-22 19:37, Izaak Goldstein pisze:

> Cokolwiek robisz, robisz to źle. Serio i bez złośliwości.

No od tego zacząłem wątek bo czułem, że coś nie jest tak jak powinno.

> A po przeczytaniu całości dyskusji z Tomaszem stwierdzam, że nie
> potrafię ci pomóc :)
>

A szkoda. Ale wygląda na to, że Tomek i Borys mnie ukierunkowali. Parę
cennych uwag podsunęli.

do góry

P.S.
Przyszło mi do głowy coś jeszcze. Te nieszczęsne przeładowania stron
chyba być i tak muszą. Załóżmy, że jakaś strona to tabela HTML z danymi
wygenerowana przez PHP a Ajax to okienko, które potrafi zmodyfikować
kliknięty wiersz z tabeli. User klika sobie wiersz, coś tam zmienia i
zapisuje. Okno Ajaxa znika ale ta tabelka pod spodem pozostaje bez zmian
(bo to HTML). Aby ją wyświetlić zaktualizowaną i tak jakiś reload jest
potrzebny. Ajax raczej sam "wiedzieć" nie może jaki kształt ma przyjąć
zaktualizowany wiersz. Zresztą programistycznie byłoby trudno przysłać
tylko ten jeden poprawiony wiersz tabeli. bo być może jakieś
podsumowania trzeba będzie na nowo liczyć więc tym bardziej wydaje się
to odświeżenie konieczne. Czy dobrze kombinuję?

do góry

W dniu 2012-12-23 19:15, Marek pisze:
> P.S.
> Przyszło mi do głowy coś jeszcze. Te nieszczęsne przeładowania stron
> chyba być i tak muszą. Załóżmy, że jakaś strona to tabela HTML z danymi
> wygenerowana przez PHP a Ajax to okienko, które potrafi zmodyfikować
> kliknięty wiersz z tabeli. User klika sobie wiersz, coś tam zmienia i
> zapisuje.

Po zapisie, jak rozumiem requeście do serwera, z serwera wysyłasz
odpowiedź, czy zapis się powiódł, jeżeli nie, wyświetlasz komunikat o
błędzie. I teraz odpowiednio, w zależności od rodzaju odpowiedzi i
logiki programu, możesz:

> Okno Ajaxa znika

albo zostawić okno z formularzem do poprawy błędnych danych, czy
ponownej próby zapisu rekordu.

> ale ta tabelka pod spodem pozostaje bez zmian
> (bo to HTML).

Jak dostajesz komunikat z serwera o poprawnym zapisie, to:
a) dodajesz rekord do tabeli javascriptem
lub
b) ciągniesz z serwera rekord ajaxem i javascriptem wstawiasz go do tabeli
c) ciągniesz z serwera ajaxem (albo przeładowujesz stronę) całą tabelę z
dodanym rekordem.

> Aby ją wyświetlić zaktualizowaną i tak jakiś reload jest
> potrzebny.

Nie jest. Możesz to zrobić po stronie przeglądarki. Patrz pkt a) i b)

> Ajax raczej sam "wiedzieć" nie może jaki kształt ma przyjąć
> zaktualizowany wiersz.

Tu nie wiem co masz na myśli.

> Zresztą programistycznie byłoby trudno przysłać
> tylko ten jeden poprawiony wiersz tabeli. bo być może jakieś
> podsumowania trzeba będzie na nowo liczyć więc tym bardziej wydaje się
> to odświeżenie konieczne. Czy dobrze kombinuję?

Trudno czy nie, to zależy. Masz dwie warstwy: przeglądarkę klienta i serwer.
Możesz od razu javascriptem (dodany, czy poprawiony) rekord dopisać do
tabeli i javascriptem sobie przeliczyć podsumowanie - po stronie
klienta. Możesz ajaxem (albo zwykłym przeładowaniem strony) poprosić o
to serwer. Możesz mieszać metody, patrz punkt b) dodaj tylko
przeliczenie tabeli (javascriptem).

Pozdrawiam
Piotr

do góry

W dniu 2012-12-23 20:56, Kviat pisze:

> albo zostawić okno z formularzem do poprawy błędnych danych, czy
> ponownej próby zapisu rekordu.

Tak właśnie zamierzałem robić. Okna walidują się po stronie serwera,
wyświetlają komunikaty o błędach lub znikają gdy wszystko jest ok.
Wydaje mi się to najbardziej intuicyjne rozwiązanie.

>
>> ale ta tabelka pod spodem pozostaje bez zmian
>> (bo to HTML).
>
> Jak dostajesz komunikat z serwera o poprawnym zapisie, to:
> a) dodajesz rekord do tabeli javascriptem
> lub
> b) ciągniesz z serwera rekord ajaxem i javascriptem wstawiasz go do tabeli
> c) ciągniesz z serwera ajaxem (albo przeładowujesz stronę) całą tabelę z
> dodanym rekordem.

a) i b) to dość złożony wariant bo wtedy logika np. podsumowania jakiejś
kolumny musiałaby być zdublowana w Ajaxie. Zresztą to nie tylko
podsumowania. Jeśli zmianie ulega tylko wiersz po takiej operacji, to
pół biedy. Czasem jednak trzeba zmian dokonać w różnych miejscach
layoutu - wyświetlać oprócz podsumowań jakieś alerty, wyróżnienia itp.
Sądzę, że ten wariant z przeładowaniem będzie ok. A już w szczególności,
że łatwo można odtworzyć pozycję scrolli więc użytkownik może nawet nie
zorientować się, że było to przeładowanie.

>> Ajax raczej sam "wiedzieć" nie może jaki kształt ma przyjąć
>> zaktualizowany wiersz.
>
> Tu nie wiem co masz na myśli.

Np. jeśli Ajax spowoduje usunięcie jakiegoś wiersza, to inne rekordy w
całej tabeli się pojawią. A jakie - tego sam Ajax nie wymyśli. A może po
tej operacji jakiś inny wiersz będzie wyróżniony aby użytkownik na niego
zwrócił uwagę itp? Logika serwera bada jak ma wygenerować stronę
odpowiedzi i wysyła ją. Gdyby Ajax miał to robić to musiałby podmienić
wszystko: łącznie z headem, CSS, kodem JS itp. bo nie chcę zakładać
żadnych ograniczeń. Częściowo o tym poniżej wspominam.

>> Zresztą programistycznie byłoby trudno przysłać
>> tylko ten jeden poprawiony wiersz tabeli. bo być może jakieś
>> podsumowania trzeba będzie na nowo liczyć więc tym bardziej wydaje się
>> to odświeżenie konieczne. Czy dobrze kombinuję?
>
> Trudno czy nie, to zależy. Masz dwie warstwy: przeglądarkę klienta i
> serwer.
> Możesz od razu javascriptem (dodany, czy poprawiony) rekord dopisać do
> tabeli i javascriptem sobie przeliczyć podsumowanie - po stronie
> klienta.

Zaryzykowałbyś? :-) Po jakiejś aktualizacji przeglądarki coś przestanie
działać i leży podsumowywanie. Jestem zwolennikiem minimalizacji
funkcjonalności realizowanej po stronie przeglądarki.

do góry

Dnia Sun, 23 Dec 2012 18:40:48 +0100, Marek napisał(a):

>> Wystarczy pilnować nagłówka X-Requested-With, wiekszość bibliotek dodaje
>> go automatycznie.
>
> Nie sprawdzałem: goły Ajax też ustawia ten nagłówek? Nie stosuję
> bibliotek. Metoda wydaje mi się sprytna i w tym kierunku pójdę. Dzięki
> za podpowiedź :-)

ZTCP to ten nagłówek trzeba dodać samodzielnie, to chyba taki nieformalny
standard. Ale znacząco ułatwia identyfikację źrodła zapytania, bez
konieczności modyfikacji adresu.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

Dnia Sun, 23 Dec 2012 18:51:49 +0100, Marek napisał(a):

>> narzędziu, które ma zupełnie inną filozofię działania. Widać to po tych
>> kombinacjach z przekierowaniami. Przyjmij, że masz do dyspozycji tylko
>> zapytanie-odpowiedź i świat stanie się prostszy.
>
> Musisz mi to na polski przełożyć :-)

Mam wrażenie, że próbujesz wpleść do tej komunikacji elementy, które nie
powinny być jej częścią, jak właśnie reakcję na przekierowania. Przyjmij,
że z serwera zawsze dostaniesz jakieś czytelne dane. Jeśli ich nie ma, to
wystąpił błąd. A wszelkie dane o przekierowaniach, wynikach operacji, ew.
komunikatach lub wręcz cała nowa zawartość strony powinny być zawarte w
tych danych. I już dalej kod po stronie klienta niech sobie z tym radzi.

> Zależy mi na tym aby serwer zwracał HTML przede wszystkim. Chodzi o
> możliwość budowania i modyfikowania wyglądu okien w edytorach WYSIWYG.
> Zapewne dojdą inne formy komunikacji w miarę potrzeb ale bazą chcę
> uczynić HTML.

Kombinujesz z rozszerzeniem funkcjonalności edytora WYSIWYG czy operujesz
na edytowanej zawartości?

> Czy takie podejście może być jeszcze łatwiejsze? Czy nie utrudniam sobie
> czegoś?

Zawsze można poszukać gotowca ;)

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry