Źródło parametrów żądania Opcje

[Cysiaczek]

Ciężko zdefiniować ten problem, bo jest dość zakręcony. Postaram się przedstawić w miarę jasno o co chodzi. Zacznę od listingu.

Plik obcięty ze zbędnych tagów. Przedstawia definicję akcji i ich podstawowe relacje.
actions.xml

[XML] pobierz, plaintext 
<index>
      <subactions>
            <showCategory />
            <showNews />
      </subactions>
</index>
            
<showNews></showNews>
<showCategory></showCategory>
[XML] pobierz, plaintext 

Załóżmy, że wywołujemy żądanie o postaci index.php?action=index
Parser czytając ten plik XML odczyta subakcję i stworzy ciąg akcji do uruchomienia w postaci

showCategory
showNews
index

W przedstawionej kolejności zostaną te akcje wykonane. (np metodą execute())

Gdzie problem? Ano. np, index.php?action=index&id=3
Intencją programisty jest, że $id odnosi się do akcji showCategory, która na jej podstawie wybiera kategorię z bazy danych.
Niech teraz akcja showNews również wymaga przekazania jakichś argumentów, np. $category oraz $id. Nie może po prostu odczytać $id, bo ten jest pobierany przez inną akcję i może nie zawierać tego, co chcemy, a nawet na pewno nie zawiera.

Ktoś może powiedzieć, że w takim razie najlepiej stworzyć łańcuch
index.php?action=index?categoryId=7&newsId=5
Od razu odpowiem, że takie rozwiązanie jest kalekie, i w ogóle nie wchodzi w grę, bo związuje akcję z konkretną nazwą klucza, którą potem trzeba wszędzie powtarzać.

Ktoś inny może podsunąć pomysł ustawiania parametrów żądania przez poprzednią akcję. Owszem. Wiele frameworków robi to i czasami również zaleca uruchomienie, bądź wręcz uruchamia kolejna akcję. Można wówczas taki bajer zrobić
W ciele akcji showCatagory

[PHP] pobierz, plaintext 
<?php
setNextActionParams("1", "kolejny", "etc"); // albo jakoś inaczej, to nieistotne
?>
[PHP] pobierz, plaintext 

Co jednak, jeśli te akcje mogą zostać uruchomione w różnych kontekstach?
np. Stwórzmy nową akcję.

[XML] pobierz, plaintext 
<showMostPopularCategory>
      <subactions>
            <showCategory />
      </subactions>
</showMostPopularCategory>
[XML] pobierz, plaintext 

Jak widać, uruchomienie index?action=showMostPopularCategory również wykona akcję showCategory. Niniejszym jakakolwiek ingerencja w parametry akcji showNews nie ma sensu, bo tej akcji nie ma w łańcuchu.
Podobnie rzecz się będzie miała z innymi akcjami, a dochodzą jeszcze nieograniczone wręcz możliwości kombinowania układów akcji.

Rodzi się konkretne pytanie - w jaki sposób przekazać w takim układzie parametry żądania? Akcja nie ma pojęcia, w jakim kontekście jest uruchamiana, wiec musi liczyć na to, coś ustawi to za nią, albo sama musi znaleźć te parametry... : \

Jeśli ktoś spotkał się z podobnym problemem, to będę wdzięczny za podzielenie się przemyśleniami oraz posiadanymi linkami do artów itp.

Dzięki wszystkim, którzy w ogóle dobrnęli do końca tego posta

Pozdrawiam.

[Cysiaczek]

Trochę pomyślałem przez noc. Pogadałem z Athlanem na IRC i coś w końcu się urodziło, choć dalej nie jestem zadowolony :/
Skoro akcja nie wie, skąd będą przychodziły do niej dane, to wymaga jedynie mechanizmu ich pozyskania (abstrakcyjnego)
Posłuży temu metoda getParam("paramName"); Pierwotnie dane te miały być pobierane z rejestru żądania, który zawiera różniez inne użyteczne dane.
Źródło danych jak mówi arecki faktyczne najlepiej zdefiniować w pliku XML.

[XML] pobierz, plaintext 
<showCategory params="request:param1=id, param2=page; showNews: param3=jakas_zmienna" />
[XML] pobierz, plaintext 

Nie wnikajcie w nazwy akcji, ani to, co robią, bo to tylko przykład

Pominę szczegóły implementacyjne.
Funkcja... nazwijmy ją paramSourceRetriver() powinna odczytać, że argumenty o nazwach param1 oraz param2 znajdują się w rejestrze żądania, natomiast param3 winna zostać pobrana z danych wyjściowych akcji showNews.
Te dane wyjściowe to cokolwiek, co mamy jako wynik przetwarzania akcji, który może też pobrać np. widok.
Wydaje mi się, że dzięki temu jestem w stanie wytworzyć wiele rożnych kontekstów użycia akcji.

Dalej pozostaje problem przysłowiowej już $id z URL'a, bo trzeba będzie wprowadzić dla tego konkretnego żądania parametry $catId oraz $newsId, choć nie związujemy już akcji z konkretnym łańcuchem polecenia, co jest postępem.

Co o tym myślicie? Może jednak bredzę... : /

Pozdrawiam

[arecki]

Źródło danych jak mówi arecki faktyczne najlepiej zdefiniować w pliku XML.

[XML] pobierz, plaintext 
<showCategory params="request:param1=id, param2=page; showNews: param3=jakas_zmienna" />
[XML] pobierz, plaintext 

Nie wnikajcie w nazwy akcji, ani to, co robią, bo to tylko przykład

Jeżeli już tak to chcesz zrobic to nie lepiej np. tak zdefiniować :

[XML] pobierz, plaintext 
 <showCategory>
    <param name="id" from="URL" method="GET"/>
    <param name="cd" from="XML" method="./\test.xml"/>
 </showCategory>
[XML] pobierz, plaintext 

Generalnie masz większą możliwość manipulacji i sprawdzania skąd i jakie zmienne możesz czerpać. No i
w parze z tym idzie czytelniejszy zapis i łatwiejsze odczytywanie zmiennych. Nie trzeba nic 'explodować' czy ineczej przetwarzać.

Pominę szczegóły implementacyjne.
Funkcja... nazwijmy ją paramSourceRetriver() powinna odczytać, że argumenty o nazwach param1 oraz param2 znajdują się w rejestrze żądania, natomiast param3 winna zostać pobrana z danych wyjściowych akcji showNews.
Te dane wyjściowe to cokolwiek, co mamy jako wynik przetwarzania akcji, który może też pobrać np. widok.
Wydaje mi się, że dzięki temu jestem w stanie wytworzyć wiele rożnych kontekstów użycia akcji.

Dalej pozostaje problem przysłowiowej już $id z URL'a, bo trzeba będzie wprowadzić dla tego konkretnego żądania parametry $catId oraz $newsId, choć nie związujemy już akcji z konkretnym łańcuchem polecenia, co jest postępem.

Początek już masz więc myślę że możesz o zacząć rozwijać. Ja też myślę o dorobienie do własnego FW możliwości generowania klas i metod potrzebnych do aktualizacji danych z bazy na podstawie definiowanego pliku XML więc dyskusja mi się też przyda (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)