Widok w MVC, Różne formaty wyjściowe Opcje

[UDAT]

Ostatnio wziąłem się za budowę własnego CMS'a opartego na MVC i sterowanego zdarzeniami.
Jednak o ile Model i Kontroler ( ten drugi w moim rozwiązaniu szczątkowy) nie sprawiły mi kłopotów to rozplanowanie systemu szablonów już tak.

Czy lepiej jest tworzyć ogrmoną ilość szablonów (oddzielnych dla PDF'a, XHTML, XML'a, oDT, TEXT itd.) czy lepiej stworzyć jakiś system, który wprowadzał by dodatkową warstwę, której zadaniem byłoby przechowywanie uporządkowanych danych w czymś a'la XML. Natomiast View miałby za zadanie IMPORT/EXPORT do niej.

Nie chodzi mi o to co będzie szybsze (w sensie czasu działania) tylko łatwiejsze do zrealizowania przez osoby tworzące content dla serwisu, nie znające php. Jednocześnie system ma być łatwy do rozszerzania.

W pierwszym przypdaku ilość szablonów w najgorszym przypadku równa będzie ilość formatół * ilość akcji*ilość skinów.
W drugim szczerze mówiąc nie wiem do końca jak zbudować VIEW.

Czy lepiej może jeszcze inaczej rozwiązać??

[Ociu]

Jak dla mnie model to plik konfiguracyjny danego modułu, który przechowywany jest jako xml/ini/php/db (Jak kto woli).

Ja sam w swoich projektach nie używałem modelu, ponieważ nie był mi potrzebny, ale jeśli będzie potrzebny, to napewno wybiore xml.

A swoją drogą, uruchomienie odpowiedniej akcji wygląda u mnie tak (w skrócie).

Kod

FilterChain->(URLFilter)->(ActionChain)->
HttpRequest->
ExecutionFilter->URLFilter->ActionChain->
PageFilter->Action->OPT.

pozdrawiam

[ActivePlayer]

jak dla mnie widok to 2 czesci.

jedna to dane

[PHP] pobierz, plaintext 
<?php
 
// php4
var $data = array();
 
?>
[PHP] pobierz, plaintext 

druga czesc to funkcja ktora przetwarza $this->data na format jaki ty chcesz.

Wiec na moje oko najlatwiej wykonac to w ten sposob:

[PHP] pobierz, plaintext 
<?php
 
class View{
	var $data;
 
	function parse(){;}
}
 
?>
[PHP] pobierz, plaintext 

a potem

[PHP] pobierz, plaintext 
<?php
 
class HtmlView extends View{
	function parse(){
	   // all fetch'es...
	}
}
 
class PdfView extends View{
	function parse(){
	   // all fetch'es...
	}
}
 
?>
[PHP] pobierz, plaintext 

a uzycie w kodzie:

[PHP] pobierz, plaintext 
<?php
 
function ViewFactory($type){
   switch($type){
   default:
   case 'html':
	   return new HtmlView();
   break;
   case 'xml':
	   return new XmlView();
   break;
   }
}
 
//...
//$typ_widoku ustalasz wg zadania klienta
$oView = ViewFactory($typ_widoku);
// wszystkie assigny itd
$oView->parse();
 
?>
[PHP] pobierz, plaintext 

nie wiem czy do konca temat zrozumialem, ale ja to tak widze.

[bela]

@AP, @Ociu: jakoś nie przekonują mnie wasze rozwiązania ;]

@Ociu, chyba nie rozumiesz co to jest model. Już spieszę z wyjaśnienie. Otóż model to inaczej dane, a ściślej rzecz biorąc to zestaw klas, funkcji do pobierania danych z źródła np. bazy danych bądź plików tekstowych.
A ten schemat też mi się jakoś nie podoba. Czemu jest URLFilter? Przecież URL trzeba sparsować aby dowiedzieć się jakie akcje się pod nim kryją. U mnie to jest pluginem.
Poza tym mam problem z rozszyfrowaniem reszty schematu

@UDAT, z tego wynika że najlepszą metodą będzie dla Ciebie XML i przetwarzanie przez XSLT, bo większość formatów o których wspomniałeś to aplikacje XMLa, a z PDF albo plain textem, możemy poradzić sobie za pomocą XSL-FO. Coś jak Cocoon, albo klon dla php a nazwie Popoon.

A co do ilości szablonów w pierwszej Twojej propozycji to wynosi ona tylko liczba szablonów * liczba formatów. Gdyż skiny można zastąpić poprzez CSS.

[hwao]

@Ociu:
Twoj pomysl moze i dobry, ale imho dlamnie zupelnie mijajacy sie z celem (modul jako "modul" jest, ale opornie sie go wlacza).
@AC:
To poco pokazalest to imho system szablonow a nie View (wiedok) z MVC.

Propozycja Beli wydaje sie najlepsza ale niesie ze soba kolejne nie dogodnosci mianowicnie nie wystarszczy znajomosc html/xml/css zeby to wszytko ladnie zlozyc.

Moja propozycja:
Przeciez calej strony nie bedziesz wyrzucal jako PDF, bo poco?
w PDF'ie mozna wyrzucac dokumentacje/faktury itp... wiec czy nie latwiej jest poprostu dopisac do nich osobny paser?

[Ociu]

@Ociu, chyba nie rozumiesz co to jest model. Już spieszę z wyjaśnienie. Otóż model to inaczej dane, a ściślej rzecz biorąc to zestaw klas, funkcji do pobierania danych z źródła np. bazy danych bądź plików tekstowych.
A ten schemat też mi się jakoś nie podoba. Czemu jest URLFilter? Przecież URL trzeba sparsować aby dowiedzieć się jakie akcje się pod nim kryją. U mnie to jest pluginem.
Poza tym mam problem z rozszyfrowaniem reszty schematu

Troche źle się wyraziłem. Conf + parser. O to mi bardziej chodziło. A co do reszty. Tyle interpretacji ile ludzi, kazdy ma swój punkt widzenia. A co do URL. URLFilter czyli tłumaczenie adresów. Umysliłem sobie, ze dla mnie filtrem będzie wszystko co co jest potrzebne, słada się tylko z jednej funkcji (metody) i jest bardzo potrzebne ( myk jest taki, że musisz sam zrozumieć ). URLFilter spełnia te wymagania. Wszystkie informacje przerzucam do Context'u, ponieważ te dane są mi zawsze potrzebne. Translator wygląda mniej więcej tak:

[PHP] pobierz, plaintext 
<?php
Class URLFilter implements IFiltr {
public function execute(HttpContext $context, FilterChain $chain) {
$url = /* .... */ $_SEVER['PATH_INFO'];
 
$context->vars = explode('/', $url);
$context->module = $context->vars[1];
# ...
$chain->executeNext($context);
}
}
?>
[PHP] pobierz, plaintext 

Edit: ActivePlayer Myśle, że tutaj sposób ukazany w prado będzie ok.

Ten post edytował Ociu 2.01.2006, 16:45:39

[bela]

Wiem o co Ci chodzi. Jednak idea filtra jest inna. Filtr możemy sobie wrzucić, wyrzucić, zmienić, zrobić z nim co chcemy, filtr nie jest elementem od którego zależy cała aplikacja. Takim czymś jest plugin

[Ociu]

Jak kto woli. Mi się tam dobrze pracuje z tym co mam .

PS. Wszsycy mnie tylko krytykują i popychają. "A ja się ogolić nie dam! bo ten zarost nosze od przed wojny"

pozdrawiam

[ebe]

mały OT ale forum bez OTów to jak żołnierz bez karabinu ;P

@Ociu do czego służy Ci HttpContext? Czy za pomocą niego porozumiewają się różne obiekty w Twoim programie, używają do do wymiany informacji?

[NuLL]

@UDAT - naprawde myslisz ze dla kazdej akcji mozna miec output w PDF-ie - wskazana przez Ciebie liczba templatek jest mocno przesadzona. Formularz logowania tez bedzie mozna w PDF ?

[UDAT]

@UDAT - naprawde myslisz ze dla kazdej akcji mozna miec output w PDF-ie - wskazana przez Ciebie liczba templatek jest mocno przesadzona. Formularz logowania tez bedzie mozna w PDF ?

No niby można

[Ociu]

mały OT ale forum bez OTów to jak żołnierz bez karabinu ;P

@Ociu do czego służy Ci HttpContext? Czy za pomocą niego porozumiewają się różne obiekty w Twoim programie, używają do do wymiany informacji?

HttpContext służy mi jako nośnik obiektów Request i Reponse.
Bela: A co do schematu, zacząłem go tłumaczyć, ale musiałem, iść na korki

Kod

FilterChain->(URLFilter)->(ActionChain)->
HttpRequest->
ExecutionFilter->URLFilter->ActionChain->
PageFilter->Action->OPT.

(Swoją drogą, ale go napisałem... tak naprawde nic nie tłumacy co się dzieje ) Uruchamiany jest FilterChain, do którego ładuje URLFilter i ActionChain. Uruchamiam HttpRequest, aby zrobił to co powinien. Potem ExecutionChain, któy uruchamia filtry URLFilter, ActionChain i PageFilter, którego na schemacie zapomniałem załadować, a tak naprawde to on ładuje co ma być wyświetlone - content. ActionChain uruchamia odpowiednią akcję, której wynik pakowany jest do html (opt).

[bela]

@ebe, spójrz tutaj, a jak poszukasz tu to będziesz miał lekturkę na kilka miesięcy

[splatch]

Mankament z XSL FO jest taki, że z tego co mi wiadomo nie ma procesora zdolnego do współpracy z php, który jest go w stanie obsłużyć, chyba że ktoś ma możliwość używania javy z poziomu php i odpowiednio skonfigurowany serwer. Moja propozycja...

[PHP] pobierz, plaintext 
<?php
 
class ViewProcessor {
 
	const PDF = '.fo';
	const XML = '.xml';
	const HTML = '.html';
 
	/**
	 * @param string $default domyślny rodzaj outputu.
	 **/ Zwraca obiekt DOMDocument.
	public function __construct($default = ViewProcessor::HTML) {
		$this->default = $default;
	}
 
	/**
	 * Zwraca obiekt DOMDocument.
	 *
	 * @param string $fileNameWithoutExtension nazwa pliku do
	 * której będzie dodane rozszeżenie. Dla pliku "test" nazwa szablonu
	 * będzie wyglądać: test.fo.xsl test.xml.xsl test.xml.html
	 *
	 **/
	public function getDomObject($fileNameWithoutExtension, $type = null) {
		if(is_null($type)) {
			$type = $this->default;
		}
		if(file_exists($fileNameWithoutExtension . $type .'.xsl')) {
			$d = new DOMDocument;
			// tutaj ustawianie zmiennych etc.
 
			$xsl = new DOMDocument;
			// tutaj ładujemy arkusz XSL
			$xsl->load($fileNameWithoutExtension . $type .'.xsl');
 
			// Tworzenie procesora XSL
			$proc = new XSLTProcessor;
			$proc->importStyleSheet($xsl); // dołączenie arkusza XSL
			$doc = $proc->transformToDoc($d);
 
			return $doc;
		}
		return false;
	}
}
 
?>
[PHP] pobierz, plaintext 

[Ociu]

Myślę, że znowu zaczyna się temat tpl Vs. php. No ale...

IMHO 'view' powinien być jeden. Tyle na ten temat Nie ma się co tworzyć nowych obiektów dla jednego modułu. Dlaczego ? Tworzy się w szablonach barokowy przepych, którego nie powinno być. W prado jest tak, że dla każdego modułu tworzymy nowy plik template, w którym wykonywana jest cała klasa. Rozumiem zrobić sobie tworzenie bloku (parsowanie pliku xml) w tpl, ale uruchamiać obiekt ? Niepotrzebnie. Można zobaczyć:

[XML] pobierz, plaintext 
<div class="author">
      last modified on <%= date('M d, Y h:ia',$this->Parent->Data['wtime']) %>
    by <%= $this->Parent->Data['author'] %>.
      [ <a href="blog.php?page=Blog:EditPage&id=<%= $this->Parent->Data['id'] %>">edit</a> ]
      [ <com:TLinkButton Text="delete" CommandParameter="#$this->Parent->Data['id']" OnCommand="Page.onClickDeleteBtn" onclick="if(!confirm('Are you sure?')) return false;"/> ]
  </div>
[XML] pobierz, plaintext 

I to jes takie nie oddzielanie od siebie warstw tworzącej od wynikowej (Cntroller i View). Po to wymyślowo MVC, aby je od siebie oddzielać.

pozdrawiam

[splatch]

Tutaj wcale nie zaczyna się temat php vs TPL. On tutaj się kończy. Cały proces tworzenia outputu odwala procesor XSL. Nie ma tutaj miejsca na nic innego. W pamięci przechowywany jest obiekt DOMDocument ze zmiennymi (zmienna $d).
Wszystko pozostaje w jednym języku, bez dodatkowych klas (PDFView, SmartyView, PHPView) etc. zmieniają się tylko szablony XSL.

[sf]

Ee, u mnie to jest dosc prosto zrobione. To wywolywania akcja tworzy obiekt response, a nie framework ( czy tam kontrolera, zwal jak zwal), response nie jest czescia frameworka, a czescia wywolanej akcji, dzieki temu to czy to bedzie smarty, xml czy cokolwiek ... moja aplikacja nie ma z tym problemu, trzeba tylko napisac odpowiedni Response i z niego korzystac.

Ten post edytował sf 2.01.2006, 22:10:15

[UDAT]

IMHO 'view' powinien być jeden. Tyle na ten temat Nie ma się co tworzyć nowych obiektów dla jednego modułu.
------------------------------------------------------------
W prado jest tak, że dla każdego modułu tworzymy nowy plik template, w którym wykonywana jest cała klasa.
------------------------------------------------------------
I to jes takie nie oddzielanie od siebie warstw tworzącej od wynikowej (Cntroller i View). Po to wymyślowo MVC, aby je od siebie oddzielać.

Ten środkowy kawałek trochę mi nie pasuję.
Preferowałbym rozwiązanie pozwalające na pełną hermetyzację Widoku (tj. można zmienić Widok, ale także Model czy Moduł bez zmiany reszty)
Jednak nawet transformacja XML:XSLT nie rozwiązuje tego problemu

[Ociu]

Wiesz, każdy robi jak lubi.
Ja wole używac uniwersalnego viewu dla każdego moduły, czy to news, artykuł, post.

pozdrawiam

[UDAT]

Wiesz, każdy robi jak lubi.
Ja wole używac uniwersalnego viewu dla każdego moduły, czy to news, artykuł, post.

pozdrawiam

O to mi chodzi.

Jak takie coś skonstruować