Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.

2 Stron V  < 1 2  
Reply to this topicStart new topic
> Widok - renderowanie widoku, sposoby implementacji, różnice w istniejacych rozwiązaniach
Sedziwoj
post 16.09.2008, 16:00:08
Post #21





Grupa: Zarejestrowani
Postów: 793
Pomógł: 32
Dołączył: 23.11.2006
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


Od samego typu widoku nie jest zależne która akcja się wykona, więc to nie Router powinien decydować jaki będzie "typ" wynikowy. To już jest poziom kontrolera. Można oczywiście wykorzystać mainControler do tego, ale to jednak w nim powinien być wybierany widok.
Pytanie, jak z szablonami html wiadomo, mają określoną nazwę i lokalizacje i w tan sposób są dobierane, to jak sprawa przy PDF, gdzie musi istnieć klasa która umie wygenerować odpowiednie dane wynikowe? W sumie to sam widok powinien wiedzieć jaka jest domyślna konfiguracja, więc można dla PDF tworzyć unikatowe klasy renrerer'ów, które by potrafiły obsłużyć to co widok dostał.
(chyba muszę sobie przyswoić lepiej słownictwo, bo się nie dogadamy ;] )

A no i to sam widok określa jaki typ jest zwracany, bo on wie kim jest, nie ma żadnego ustawiania.

Ogólnie tym do czego dążę to aby mieć jakieś widoki (Smatry/OPT/XML/PDF/JSON) i do nich odpowiednie "renderer"y dla smarty .tpl, dla PDF odpowiednia klasa itd.
Dzięki temu, jakby ktoś chciał zmienić system szablonów wystarczy zaimplementować odpowiedni interfejs/abstrakcje widoku i dla miejsc wystąpienie potrzebne renderery. W czym renderery nie są jakoś zunifikowane, bo należą tylko do widoku.

EDIT: literówka

Ten post edytował Sedziwoj 16.09.2008, 16:00:35


--------------------
Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami.
Go to the top of the page
+Quote Post
LBO
post 16.09.2008, 20:51:29
Post #22





Grupa: Zarejestrowani
Postów: 1 415
Pomógł: 117
Dołączył: 7.09.2005
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


Cytat(Sedziwoj @ 16.09.2008, 17:00:08 ) *
Od samego typu widoku nie jest zależne która akcja się wykona, więc to nie Router powinien decydować jaki będzie "typ" wynikowy. To już jest poziom kontrolera. Można oczywiście wykorzystać mainControler do tego, ale to jednak w nim powinien być wybierany widok.


Jak nie? Przecież router tłumaczy URLe, parametry z CLI, komendy głosowe (biggrin.gif) jaką akcje ma wykonać? Tym samym wydaje mi się, że od niego zależy jaki format wynikowy ma być. Dla CLI, czy SOAP to będzie jasne, ale dla web requestów już nie (HTML, (AJAX) JSON, (AJAX) XML).
Kontroler/Akcja ma byc niezależna od formatu wynikowego. Dlatego tak potepiam te stosy ifów sprawdzających rodzaj żądania i generujacych odpowiedni output w wewnątrz akcji.

[edit]Hmmm, tak myślę, że może nie tyle Router, co warstwa requestu.[/edit]

Zauważyłem właśnie, że strasznie dużo ludzi utożsamia widok z renderem.

  1. <?php
  2. // pseudo costam kontroler
  3. function executeListingAction($request_parameters) {
  4.    $model = new SomeListingModel();
  5.    $listing = $model->getAllByPage($request_parameters['page']);
  6.  
  7.    // i tutaj pies pogrzebany, bo patrząc na większość frameworków
  8.    // $this->view jest instancją jakiejś nakładki np MyFrameworkSmartyView,
  9.   // MyFrameworkOptView, albo MyPDFView, czyli w istocie renderera.
  10.    $this->view->set('listing', $listing);
  11.  
  12.   // i co potem?
  13.   if($this->request_type == 'pdf') {
  14.      $this->resonse->setContentType('application/pdf');
  15.      $this->view->setPDFTemplate('templates/listing.pdf'); // bo tutaj renderer obsluguje PDF, nie ma tego w podstawowym interfejsie klasy widoku. bleh!
  16.   } else if($this->request_type == 'ajax') {
  17.      $this->resonse->setContentType('application/json');
  18.   }
  19.   // gdzie tu jakikolwiek podzial kontrolera/akcji od widoku?
  20. }
  21. ?>


Cytat(Sedziwoj @ 16.09.2008, 17:00:08 ) *
Pytanie, jak z szablonami html wiadomo, mają określoną nazwę i lokalizacje i w tan sposób są dobierane, to jak sprawa przy PDF, gdzie musi istnieć klasa która umie wygenerować odpowiednie dane wynikowe? W sumie to sam widok powinien wiedzieć jaka jest domyślna konfiguracja, więc można dla PDF tworzyć unikatowe klasy renrerer'ów, które by potrafiły obsłużyć to co widok dostał.
(chyba muszę sobie przyswoić lepiej słownictwo, bo się nie dogadamy ;] )


Lepiej stworzyć widok(i) akcji, który bedzie potrafil obsluzyć kilka rodzajów formatów wyjściowych w tym np. modyfikować dane z kontrolera i dopiero je przekazywać do renderera. O tyle wygodniej, że nie trzeba robić renderera JSON, bo wystarczą fukcje natywne.

Cytat(Sedziwoj @ 16.09.2008, 17:00:08 ) *
A no i to sam widok określa jaki typ jest zwracany, bo on wie kim jest, nie ma żadnego ustawiania.

Ogólnie tym do czego dążę to aby mieć jakieś widoki (Smatry/OPT/XML/PDF/JSON) i do nich odpowiednie "renderer"y dla smarty .tpl, dla PDF odpowiednia klasa itd.
Dzięki temu, jakby ktoś chciał zmienić system szablonów wystarczy zaimplementować odpowiedni interfejs/abstrakcje widoku i dla miejsc wystąpienie potrzebne renderery. W czym renderery nie są jakoś zunifikowane, bo należą tylko do widoku.

EDIT: literówka


O i doszedłem do Tego, przeczytałem i też mi się podoba. Chociaż trochę sie skrzywiłem, na to, że dla każdego rendera na twardo będzie trzeba obsługę formatu wpisać (czyli ten skrypt PHP dla PDF i tpl dla Smartów). Nic nie przebije samego PHP gdzieś pomiędzy jeszcze - chociażby mozliwości jego użycia.

Ten post edytował LBO 16.09.2008, 21:36:45
Go to the top of the page
+Quote Post
starach
post 17.09.2008, 08:57:51
Post #23





Grupa: Zarejestrowani
Postów: 999
Pomógł: 30
Dołączył: 14.01.2007
Skąd: wiesz ?

Ostrzeżenie: (0%)
-----


Cytat(LBO @ 16.09.2008, 21:51:29 ) *
Jak nie? Przecież router tłumaczy URLe, parametry z CLI, komendy głosowe (biggrin.gif) jaką akcje ma wykonać? Tym samym wydaje mi się, że od niego zależy jaki format wynikowy ma być. Dla CLI, czy SOAP to będzie jasne, ale dla web requestów już nie (HTML, (AJAX) JSON, (AJAX) XML).
Kontroler/Akcja ma byc niezależna od formatu wynikowego. Dlatego tak potepiam te stosy ifów sprawdzających rodzaj żądania i generujacych odpowiedni output w wewnątrz akcji.
No dobra, ale co z sytuacją kiedy moduł reaguje inaczej na element który wymusza w routerze zmianę typu wynikowego. Owszem sytuacja niszowa i wątpię czy kiedykolwiek się z nią spotkam, ale wtedy istnieje konieczność zmiany generowania typu odpowiedzi w module. ( swoją drogą pomysł z rozpoznawaniem przez rozszerzenie jest bardzo fajny )
-- Dobra sam już sobie odpowiedziałem na mój bezsensowny zarzut do tej metody. Też jestem za tym żeby router ustawiał typ odpowiedzi.
Mam tylko jeszcze zastrzeżenie co do wykrywania typu odpowiedzi. Ile jest typów dokumentów ? Chyba tego nie wie najstarszy programista.
Co w związku z tym ? Ano tylko że obsłużyć kilka standardowych a resztę olać ustawiając domyślny ?

Teraz pytanie o wyniki widoku.
Klasa V powinna sama pakować dane do obiektu który ma je wyświetlać czy zwracać wynik do kontrolera akcji który się tym zajmie ?

CLI - Command Line Interface ? eee ?
Go to the top of the page
+Quote Post
LBO
post 17.09.2008, 10:01:52
Post #24





Grupa: Zarejestrowani
Postów: 1 415
Pomógł: 117
Dołączył: 7.09.2005
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


Cytat(orglee @ 17.09.2008, 09:57:51 ) *
Mam tylko jeszcze zastrzeżenie co do wykrywania typu odpowiedzi. Ile jest typów dokumentów ? Chyba tego nie wie najstarszy programista.

Co w związku z tym ? Ano tylko że obsłużyć kilka standardowych a resztę olać ustawiając domyślny ?


Jeżeli masz dobry router, elastyczny i genialny, nie musi to być po rozszerzeniu. Możesz ustawić, że /blog/post/read/my-title ustawiają format wynikowy na domyslny, /blog/post/read/my-title.html ustawiają format wynikowy na HTML, /blog/post/read/my-title.pdf na PDF, a na przykład /ajax/blog/post/read/my-title wymuszają JSON - ja tak robię smile.gif

Cytat(orglee @ 17.09.2008, 09:57:51 ) *
Teraz pytanie o wyniki widoku.
Klasa V powinna sama pakować dane do obiektu który ma je wyświetlać czy zwracać wynik do kontrolera akcji który się tym zajmie ?

CLI - Command Line Interface ? eee ?


Nie rozumiem. Mógłbyś wyjaśnić?

Pozdrawiam, Alan
Go to the top of the page
+Quote Post
dr_bonzo
post 17.09.2008, 11:02:01
Post #25





Grupa: Przyjaciele php.pl
Postów: 5 724
Pomógł: 259
Dołączył: 13.04.2004
Skąd: N/A

Ostrzeżenie: (0%)
-----


[ot] CLI = Command Line Interface


--------------------
Nie lubię jednorożców.
Go to the top of the page
+Quote Post
starach
post 17.09.2008, 13:46:35
Post #26





Grupa: Zarejestrowani
Postów: 999
Pomógł: 30
Dołączył: 14.01.2007
Skąd: wiesz ?

Ostrzeżenie: (0%)
-----


Zależnie od architektury frameworka wynik produkowany przez moduł jest wysyłany bezpośrednio do przeglądarki, pakowany do obiektu wyświetlającego który wykonuje dodatkowe zadania ( np. pakuje gzip'em ) lub zwracany do klasy kontrolującej ładowanie modułu.

W moim FW wynik jest pakowany do klasy wyświetlającej 'Output'.
Stąd moje pytanie. W którym miejscu wynik wygenerowany przez moduł powinien być przekazywana do klasy Output w celu dalszej obróbki?


  1. <?php
  2. if(CLI == 'Command Line Interface') {
  3. echo 'W takim razie nie rozumiem do czego LBO odniosłeś CLI w swoim poście';
  4. }?>
Go to the top of the page
+Quote Post
LBO
post 17.09.2008, 14:17:38
Post #27





Grupa: Zarejestrowani
Postów: 1 415
Pomógł: 117
Dołączył: 7.09.2005
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


@orglee PHP też mozna użyć do konsolowych aplikacji, odczytywanie argumentów mimo mimo, że natywnie proste, nie jest elastyczne.


Kod
php /usr/some_project/console.php post read 1 # kieruje na kontroler post, akcje read, id = 1

php /usr/some_project/console.php delete 100 comment  #kieruje na kontroler comment, akcje remove, id = 100

php /usr/some_project/console.php cleanup_session # kontroler default akcja cleanSession



To są ekstramalne przypadki, ale pokazują, że router się przydaje i tutaj.

Cytat(orglee @ 17.09.2008, 14:46:35 ) *
W moim FW wynik jest pakowany do klasy wyświetlającej 'Output'.
Stąd moje pytanie. W którym miejscu wynik wygenerowany przez moduł powinien być przekazywana do klasy Output w celu dalszej obróbki?


Ale co generuje moduł? Tylko zmienne? Czy już HTML/PDF?

Ten post edytował LBO 17.09.2008, 14:20:29
Go to the top of the page
+Quote Post
quality
post 2.03.2011, 08:47:36
Post #28





Grupa: Zarejestrowani
Postów: 172
Pomógł: 9
Dołączył: 13.02.2006
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


Witam.
A czy ktos uzywal kiedys XSLT do renderowania widoku ? smile.gif
Znajomy ostatnio mi pokazal jak fajnie mozna tego uzyc. Generujemy plik XML z wszystkimi danymi, a nastepnie szablon w XSLT, ustawiamy naglowki na HTML i mamy pieknie wyrenderowana strone przez przegladarke, badz parser smile.gif


--------------------
Go to the top of the page
+Quote Post
Speedy
post 9.04.2011, 15:53:42
Post #29





Grupa: Zarejestrowani
Postów: 651
Pomógł: 28
Dołączył: 4.12.2004

Ostrzeżenie: (0%)
-----


Cytat(quality @ 2.03.2011, 09:47:36 ) *
Witam.
A czy ktos uzywal kiedys XSLT do renderowania widoku ? smile.gif
Znajomy ostatnio mi pokazal jak fajnie mozna tego uzyc. Generujemy plik XML z wszystkimi danymi, a nastepnie szablon w XSLT, ustawiamy naglowki na HTML i mamy pieknie wyrenderowana strone przez przegladarke, badz parser smile.gif


Kiedyś się tym bawiłem w ramach eksperymentów, ale było to dawno temu. Nie wiem, czy ta technologia się zmieniła od tamtego czasu, bo do niczego konkretnego jej nie używałem.
Jedyne, co pamiętam, to fakt, że arkusze XSLT są przetwarzane po stronie klienta i jest za to odpowiedzialna przeglądarka. W związku z tym, w jednej przeglądarce wszystko wyświetlało się, jak należy, a w innej już nie. Moim zdaniem, używanie tego na co dzień może być dość ryzykowne, ponieważ nie masz pewności, czy wszystko zostanie przetworzone i wyświetlone, jak należy. Musiałbyś wcześniej porobić jakieś testy. Poza tym, jest to trochę inne zagadnienie, niż klasyczne renderowanie widoku, gdyż PHP robi wszystko po stronie serwera, natomiast tutaj cała akcja dzieje się po stornie klienta.


--------------------
Sygnatura niezgodna z regulaminem.
Go to the top of the page
+Quote Post
everth
post 9.04.2011, 16:04:29
Post #30





Grupa: Zarejestrowani
Postów: 782
Pomógł: 153
Dołączył: 21.07.2010

Ostrzeżenie: (0%)
-----


XSLT też może być przetwarzane po stronie serwera i wydaje mi się to nawet bardziej rozpowszechnione niż sposób o którym mówisz. Mniej problematyczny, robiłem tak przez pewien czas, jednak formuła Widok -> XML -> XSLT -> HTML jest jednak trochę przekombinowana jak dla mnie.


--------------------
Już mi się ani wiedzieć, ani tym bardziej myśleć nie chce.
[Think different]!
Go to the top of the page
+Quote Post

2 Stron V  < 1 2
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 19.03.2024 - 09:45