Moze to i gdzies bylo ale jesli tak to mi umknelo
W sumie moj obecny sposob rozumienia i przechowywania akcji jest taki:
akcja to jedna metoda danej klasy metody w tej klasie wykonuja podobne zadania np. wyswietlanie newsow, artykulow. Wszytkie akcje/metody o podobnym dzialaniu grupuje w kasy ale nie ejstem pewnien slusznosci tego rozwiaania. U mnie akcje sa kompleksowe, to znaczy ze jedna akcja wykonuje wszytkie operacje jednego requesta, nie mam lancucha akcji ale moze go wprowadze.
I zasadnioczo moje pytanie brzmi czy jedna akcja to powinna byc jedna klasa? jesli mialbym lancuch akcji to spowalnialo by to kod bo bym musial np. 10 inludow robic. Jesli zrezygnuje z lancuchow akcji i pozwole jednej akcji utworzyc dane dla widoku to wtedy strategia jedna klasa jedna akcja moze przyniesc przyspieszenie interpretacji kodu.
Jak Wy to robicie? Gdzie umieszczacie akcje i jak je grupujecie?

U mnie każda akcja to oddzielna klasa spełniająca dany interfejs.
A grupować moge to dowolnie (najczęściej nie grupuje w ogole, albo korzystam z katalogów) dzięki omawianemu tu __autoload().

Pozatym przy dobrze rozdzielonych zadaniach w framework uważam iż zmiana sposobu tworzenia akcji (z takiego gdzie akcja to klasa, lub metoda klasy) nie powinno zająć wiele czasu :]

ja stosuje podobnie tzn klasy sa hermetyczne sluza do konkretnych celow, oddzielna dla artow, newsow, produktow itp. wewnatrz danej klasy sa metody (akcje) wykonujace zadania, hermetyczne dlatego ze np. caly modul newsy zamkniety jest w konkretnej klasie i tylko ona jest potrzebna do dzialania newsow

Widze bawimy się w moduły tak nie ja jedyny wykorzystuję MVC po swojemu.
A mnie głowna klasa modułu pełni rolę minikotrolera który może uruchomić tylko konkretne akcje - ot, cała filozofia
Z kodowniczego punktu punktu widzenia trochę głupio zamykać każdą akcję w konkretny plik ale jest to rozwiązanie za pan brat z wydajnością - co jeśli klasa, której motedy są akcja ma 150 kb :?:
Tak więc akcja to klasa, a moduł to taki mały kontroler

Null, tak tez mozna. FrontController wybiera odpowiedni ApplicationController (np. dla newsow, artow, forum) ktory z kolei wywoluje dostepne akcje :]

Cos ala jak w tym przykladzie:
http://www.phppatterns.com/index.php/artic...cleview/19/1/1/

to jest tak: jesli nie ma lancucha akcji to znaczy ze jedna akacja robi wszystko i tutaj zamkniecie jednej akcji w jednej klasie moze miec troche sensu bo nie wczytujemy duzej klasy tylko kawalek potrzebnego kodu.
Ale jest jeszcze jedna kwestia: staram sie aby to co robi akcja bylo w miare atamowe tzn. a kcja wie o co poprosci obiekt danych i jakie operacje na tych danych wykonac a jesli potrzeba wykonac cos jeszcze to w klasie umieszczam dodatkowe metody tym razem opatrzone operatorem protected (w sumie mozna je rozpatrywac jako akcje) ktore robia cos dodatkowego, grupujac akcje o podobnych funkcjach w jednej klasie moge w roznych akcjach wykozystywac te sama akcje pomocnicza co poprawia spojnosc kodu i zmniejsza liczbe includow.
Chyba sam sobie odpowiedzialm na pytanie Raczej zostane przy swoim pomysle:
klasa = kilka akcji o podobnych funkcjach + wspolne akcje pomocnicze.

@squid - osobiście nie podoba mi się ten pomysł z akcjami pomocniczymi - pokaże kod i chyba będzie najłatwiej

[PHP] pobierz, plaintext 
<?php
 
class newsAdd implements iAdministrateAction
{
	public function perform(iContext $context)
	{
	//w tym miejscu dostajemy cały kontekst i trzeba wyczyść treść z tagów HTML co nas
ępuje
	$tresc=componentManager::get('DataFilterManager')->prepareFilter('htmlTags')->execute($context->get('tresc'));
	}
}
 
?>
[PHP] pobierz, plaintext 

i mamy juz oczyszczona tresc newsa pobrana z kontekstu i akcji pomocniczych brak Rozwiązanie jak dla mnie zdecydowanie lesze jakoże dany filtr można wykorzystać gdzie sę chce Pozatym ładniejsze

Jakieś wytłumaczenie - u mnie największe klasy mają nazwę komponentu. Tutaj jest wyciągany filtr danych czy też zmiennych i on wykonuje całą robotę za Ciebie.

A po co podział interfejsow na administracyjne? Akcja to akcja, a interfejs jest uogólnieniem więc w ogóle nie powinno go obchdzić jakiego to typu akcja.

Co najwyżej zrobić abstrakcyjną klasę akcji admistracyjnych, jeżeli dla nich ma być zawsze wykonywane coś nadzwyczajnego :]

@Bela_666: to było pisane z palca - pierwsza myśl. FilterManager napisano, a o panelu admina jeszcze nie myślałem

@NuLL jak dobrze rozumiem to sugerujesz aby moje "akcje pomocnicze" pogrupowac w klasy-komponenty wywolywane statycznie tak?
pomysl nawet ciekawy tylko znowu liczba dolaczanych plikow mi sie inkrementuje a mam juz ich ok 10 cos trzebaby z tym zrobic.
Po za tym pomysl komponentow sie nie sprawdzi jesli ta dodatkowa akcja ma byc cos specyficznego dla danej grupu akcji/operacji np. w kasie administracyjnej mam metode, ktora tworzy opcje dla menu admina nie ma tu sensu umieszczac jej jako komponent bo nikgdzie indziej nie bedzie uzywana i nawet nie powinna.

Jezu, ludzie, przeciez nie oto chodzi by do wszystkiego miec po tysiac klas :] Sposob Squid-a nie jest zly.

Mozesz sobie zrobic klase News z metodami. Gdy metoda zaczyna sie (jej nazwa) od prefixu action_ to jest mozliwa do wywolania przez kontroler. Wszystkie inne metody moga sluzyc po prostu odpowiedniemu podzialowi zadan, tak by w ciele jednej metody nie zamieszczac wszystkiego. Ja tak kiedys robilem i jest OK.

Zreszta to samo gdy akcja jest oddzielna klasa. Mozesz porobic sobie pomocnicze metody i luuzik.

@NuLL: zastanawiam sie nad tym Twoim componentManager'em i mam pyanie: co przemawia za tm zeby uzywac czegos takiego zamiast autoloadera ( taki mam pomysl aby autoloader zajmowal sie ladowaniem wszystkiego zarodno niejawinie jak i jawnie jak w wypadku componentManagera ).

Inny moj pomysl polega na tym zeby w konfiguracji lub czesciowo automatycznie ladowac wszystkie pliki z klasami ( lacznie z komponentami ) na starcie skryptu przez autoloader (oczywiscie tylko te klasy ktore sa potrzebne do obsluzenia danej akcji) i udosepniac ich interfejsy poprzez kontroler ( chocciaz to moze byc problematyczne przy dodawaniu nowych parametow do metod wiec mozna przekazywac referencje do obiektu ). Co Wy na to?

Osobiście kocham porządek w aplikacji. Autoloader powoduje ogromny śmietnik w aplikacji wbrew pozorom. ComponentManager również wykorzystuje autoloader bo nie ma w nim żadnejgo includa czy czegokolwiek podobbnego. A napisany jest po to żeby był i tyle.

@NuLL czy kontekst tworzy i wypełnia (na podstwie GET'a i POST'a) kontroler i przekazuje do akcji? A potem ten sam obiekt context wykorzystuje widok?

Trochę tak i trochę nie. Podziału na widok i model nie ma, bo mi się nie podoba i jest niewygodne IMHO. Więc kontekst jest przekazywany tylko do samej akcji.

Co do kontekstu a mnie dane z pasku adresu są pobierane z klasy która parsuje adres a z tablicy $_GET.

EDIT: Ja osobiście uważam, że kontekst lepiej spełnia swoje zadanie aniżeli kilka osobnych klas.

@ebe czemu chcesz uzyc kontekstu, nie lepiej klase requesta zrobic na singletonie i odwolywac sie z dowolnego mmiejsca w kodzie do parametrow?

Tzn. badam różne rozwiązania. Zobaczyłem kawałek kodu NuLL'a i rozbudziło to moją ciekawość. W tej chwili mam, że w akcji biorę instancję requesta, ale chcę wiedzieć jak rozwiązał to NuLL za pomocą wzroca Context.

To jest taki wzorzec ? UU - nie wiedziałem - dla mnie inspiracją był phiend2. Nie wiem co tam powiada wzorzec o tym. Ale u mnie składa się on z POST, danych z URL-a oraz ciastek - nic więcej. U mnie np. sesja nie należy do kontekstu, jest singletonem. Tak samo zmienne serwerowe

Z założenia context to taki wewnętrzny 'protokół' komunikacji między obiektami, ja go wykorzystuję w komunikacji akcja-widok, dzięki czemu nie assignuję niczego. Dlatego zastanawiałem się jak tego użyłeś.

PS gdzie można dorwać najnowszego phienda2, z tego co widać coś się ruszyło i może jest już coś nowego?

ebe: Chyba z akcji i tak musisz jakies dane do twojego Context wlozyc, zanim poslesz je do widoku? Czy to nie to samo co Assign? hyh

@Vee - IMHO to zależy od punktu widzenia. Dla mnie context jest żądaniem które się nie zmienia. Akcja go dostaje i wykorzustuje nie modyfikując go. Ale można też jak Ty czyli ładować to co lata między widokiem i modelem wrzucić do context'u

Tak robi ebe... nie ja :] A pytanie było do ebe również....

Prosze mi nei przypisywać czyiść sposobów i idei ;]

Tak, ale u siebie traktuję templaty jako widoki, tj. nie mam akcji widoku. A assignując musiałbym tworzyć takie akcje. W akcji coś tam robię z modelem i zwracam samą nazwę widoku, który potem wywołuje kontroler.
Wybrałem context jako komunikację akcja-widok, w tej chwili raczej się bawię mvc i analizuję różne rozwiązania...

Ja tam assignuje do wlasnych TPLow (ale interfejs jak w smarty) centralnie z Akcji :] Dla mnie tez oddzielne klasy dla widokow (standardowo)to bezsens. Mozna sobie porobic gdy potrzeba, ale nie zeby za kazda akcja :]

jesli chodzi o te assigny to obecnie w moim frameworku gdy akcja przetworzy juz dane to zapisuje je tak:

[PHP] pobierz, plaintext 
<?php
$this->data['nazwa_zmiennej'] = $wartosc;
?>
[PHP] pobierz, plaintext 

a specjalna akcja z klasy po korej dziedzicze zajmuje sie wyslaniem calej tablicy $data do widoku, dzieki czemu nie mam zadnych aasignow i widok na podstawie parametru viewtype z URL okresla format wyjsciowy danych (XHTML, PDF, TEXT...) dzieki czemu to rozwiazanie jest bardzo wygodne i elastyczne.

@Vengeance jak uzywasz assignow w akcji to zmiena formatu na pdf i to w kazdej akcji troche Ci zajmie