Łańcuchy akcji Opcje

[splatch]

Witam serdecznie.

Jakiś czas temu zacząłem się zastanawiać nad łańcuchami. W OPB widziałem ActionChain, gdzieś indziej FilterChain i cały czas mnie zastanawia czy słowo łańcuch jest na miejscu, czy nie lepiej pasuje stos?

Gdy rozrysowałem sobie przykładowy łańcuch wyglądał on tak:

Kod

Wpisz token  -> Wypełnij formularz -> Wpisz kod aktywacyjny
                                                      \ onError = break

Domyślnie, kiedy akcja zwróci wartość true jest wywoływane kolejne ogniwo. Gdy zwróci false jest powtarzana. Atrybut onError mówi co zrobić, gdy wystąpi błąd. Tak więc wymyśliłem następujące zapisy:

Kod

onError = stop - zatrzymuje akcję (domyślnie)
onError = back - poprzednia akcja
onError = break - przerywa łańcuch

Odwołania do danych, które zostały podane wcześniej można realizować poprzez sesję, w której zapisywane są wartości pochodzące z formularzy.
Myślę też nad zastosowaniem czegoś na kształt beanów z javy, które byłyby przesyłane poprzez sesje.

Moje pytanie brzmi, czy ktoś miał styczność z taką interpretacją łańcucha, czy istnieje jakaś inna nazwa na to (akcje wiązane?) i w końcu co o tym sądzicie? Zapraszam do dyskusji. :]

[Vengeance]

Wg mnie łańcuchy nie są potrzebne.

A co do ActionChain i FilterChain to dwie różne rzeczy :] FilterChain zarządza filtrami.

[splatch]

@Vee wiem co robi ActionChain i FilterChain, chodzi mi o to, że działają one nie jak łańcuch a jak stos

[Kas]

Nie wiem czy dobrze rozumiem...
Ale to jest poprostu wykonywanie kolejnych kroków alogrytmu?

[splatch]

Dokładnie z tą różnicą, że są to odmienne akcje, które mogą robić różne rzeczy. Aby zachować przejrzystość każda akcja to oddzielny plik i klasa. Jeśli znasz prado był tam komponent Wizzard.

Przykładowo - pierwsza akcja generuje formularz i obrazek z napisem, następnie sprawdza czy przesłany formularz był poprawny (wygenerowany napis==napis wpisany w formularzu), jeśli tak to zwraca true i wyświetla formularz z polami login, hasło itp, następnie go sprawdza, jeśli wszystko dobrze to to generuje email z kodem aktywacyjnym i zwraca true. Po tym jest wyświetlana ostatnia strona, która oczekuje na poprawny klucz.
Gdy użytkownik wpisze odpowiedni klucz ostatnia akcja zwraca true i system zamyka łańcuch poprzez redirect to zdefiniowanej strony.

[NuLL]

No dobra - mamy ten tam sobie łańcuch. Są 3 akcje - Są w nich operacje na bazie. W 3 akcji coś na bazie się zwali. Co teraz ? A 3 akcja nie może działać bez wykonania zapytanie w akcji trzeciej i otrzymania od niej wyniku ? Macie pomysł jak to wrócić ?

[splatch]

Kto mówi, że wszystko musi być zapisywane w bazie? Ostatnia akcja, która finalizuje łańcuch zczytuje wartości z odpowiednich beanów, rozpoczyna transakcję i wrzuca do bazy co trzeba, jeśli coś się zwali to transakcja zostanie automatycznie przerwana. Nie tracimy danych, bo cały czas mamy beany z poprzednich akcji i możemy do nich bez problemu wrócić.

[squid]

Kto mówi, że wszystko musi być zapisywane w bazie? Ostatnia akcja, która finalizuje łańcuch zczytuje wartości z odpowiednich beanów, rozpoczyna transakcję i wrzuca do bazy co trzeba, jeśli coś się zwali to transakcja zostanie automatycznie przerwana. Nie tracimy danych, bo cały czas mamy beany z poprzednich akcji i możemy do nich bez problemu wrócić.

Dokladnie
Tylko takie rozwiazanie moze byc kosztowne pamieciowo, testowales cos takiego? naraz 1000 uzytkowniko zainicjalizuje te sam lancuch akcji i kazde wywolanie ma trzymac w pamieci (w bean'ach) miedzy poczatkiem a koncem lancucha, co wtedy?

Uwielbiam prostote, u siebie domyslnie mam zawsze tylko jedna akcje ale jesli jej zadania sa rozbudowane to w zasadzie dziala jak appControler rozdzielajac zadania na mniejsze akcje, a miare mozliwosci tylko ona (ta glowna) operuje na bazie danych choc nie musi.
Moge tez zwrocic nazwe nastepnej akcji jaka ma byc wykonana wtedy mam lancuch "tradycyjny".

Ale nie rozumiem czemu chcesz nazwac swoje rozwiazanie stosem, musialbys stworzyc sobie lancuch i wykonywac go od tylu ( FILO ) zeby to bylo stosem

Ten post edytował squid 10.08.2005, 12:12:02

[splatch]

@squid nie testowałem, to rozwiązanie jest cały czas w fazie projektowania. Fakt, użycie pamięci może skoczyć, ale przecież nie za każdym razem wszystkie beany będą używane. Myślę, żeby można było ustawić scope'a dla każdego, który pośrednio by definiował długość życia beana. To znaczy:

Kod

scope=request --- tylko jedno rządanie
scope=session -- sesja
scope=application -- zserializowany obiekt zapisany w pliku

Swojego rozwiązania nie nazywam stosem, ponieważ stos jest prosty nie można z jednego stosu wywołać drugiego, tzn. przerywam jeden ActionChain i zaczynam drugi. IMO FilterChain i ActionChain to nic innego jak stos z wzorcem kompozytu (?) gdzie idzie foreach - $item->execute();.
Łańcuch ma przetrwać dłużej niż jeden request. Pośrednio chodzi o wykonywanie akcji w określonej kolejności, z tym, że jest ona definiowana w pliku konfiguracyjnym, a nie przez same akcje i fallbacki.

Ten post edytował splatch 10.08.2005, 12:25:16