PHP MVC - skatu (view) ģenerēšana

[ArnisR]

Sveiki!

 

Pēdējā laikā cenšos pareizi izprast MVC būtību un šoreiz nepieciešama jūsu palīdzība!

Kā vislabāk/pareizāk ir ģenerēt skatus MVC framework'ā?

 

Pieņemsim ir WEB aplikācija, kurā ir daudz funkcionalitātes ziņā atšķirīgu lapu, piemēram, reģistrācija, kontaktforma, rakstu izvade, viesu grāmata utt., taču visām šīm lapām saglabājas nemainīgs header, sidebar un footer - mainās vienīgi content bloks.

 

Tā, piemēram, kāda kontroliera metode register ģenerē reģistrācijas lapu. Tad kā būtu jaiekļauj skati šajā lapā? Vai iekļaut pa vienam, piemēram:

 

function register()
{
	// metodes kods...
	
	$this->view('header');
	$this->view('register_form');
	$this->view('sidebar');
	$this->view('footer');
}

 

 

Vai arī izveidot atsevišķu reģistrācijas lapas skatu, kurš savukārt pats sevī iekļauj tos statiskos skatus? Vai skatu iekļaušana citos skatos vispār skaitās good practice?

 

Un kā būt ar datu padošanu skatiem? Piemēram, sidebar skats attēlo pēdējos rakstus, komentārus u. tml., tad sanāk, ka šo datu atlase jāveic katra kontroliera metodē, kura iekļauj šo skatu? Vai var kā citādi?

 

Un vēl - ir dzirdēts, ka skati nedrīskt saturēt if/else, for, while konstrukcijas. Tā ir?

 

Varbūt nedaudz padumji jautājumi, bet tik un tā ceru uz atsaucību.

Paldies!

[Mr.Key]

Skati drīkst saturēt if/else. Es gan nodalu to tā, ka skatos izmantoju konstrukciju if (): endif;, kas vienmēr ļauj saprast, ka tas ir skats, nevis php kods. Cits jautājums ir par veidņu dzini - katram savi nosacījumi. Smarty, piemēram, ir savas izteiksmes, bet "mustache" logic-less veidnes nesatur konstrukcijas, jo veidņu attēlošanu veic kods, kurš gan satur konstrukcijas, utt.

Par pārējo - parasti konkrētās lapas kods izveido lapas HTML, kurš vēlāk tiek ietverts layoutā. Tas var notikt kaut vai tā, ka ar output buffering uzkrāj HTMLu, kuru rada konkrētās lapas kods, iemet to mainīgajā $content un tad ietver layout skriptu, kur "echo $content". Datu padošana skatam - atkarīgs no tā, kā tiek realizēts tavs MVC, taču vispārīgi - kontrollera kods sagatavo datus un padod skata objektam. Papēti Zend, Symphony u.c. ietvaru izmantotos principus.

[Kavacky]

Es gan nodalu to tā, ka skatos izmantoju konstrukciju if (): endif;, kas vienmēr ļauj saprast, ka tas ir skats, nevis php kods.

Njā, tie HTML tagi pa gongu nesit.

[daGrevis]

Abstrakti:

 

Ir rūteris, kas no URL ko pieprasa lietotājs izsauc kontroleri.

 

Kontroleris, ar templeitiem, dabū outputu un atgriež atbildi.

 

Kontroleris var padot datus templeitam.

 

Templeiti atbild par visu HTML utml.. Templeits ielādē visus sidebars, headerus/footerus utml., ne kontroleris.

 

Kontroleris, pa lielam, tikai izsauc. Ja ir nepieciešami dati no ārējā resursa (kā datubāzē), tas izsauc modeli.

 

Ir gadījumi, kad kontroleris izsauc ārejo klasi — kura nav modelis.

 

Kontroleri kontrolē. Modeļi atbild par datiem un CRUD. Templeiti ir viss HTML. Var būt klases, kas nav ne kontroleri, ne modeļi.

[Kavacky]

Vai skatu iekļaušana citos skatos vispār skaitās good practice?

Interesanti gan, kā "code reuse" varētu būt bad practice?

[Mr.Key]

Njā, tie HTML tagi pa gongu nesit.

Piemēram, rakstot view helperi, ir gan HTML tagi, gan PHP kods. Lai nu kā, tādu praksi esmu manījis daudzos projektos, pret kuriem izjūtu respektu.

[daGrevis]

View helperi, kuri satur HTML, Django saukti par templeit-tagiem, ir ok!

[101111]

Daudzi templeitu dzinēji praktizē šablonu mantošanas principu, lai rejūzotu kopīgos blokus starp templeitiem. Manuprāt ļoti jauks piegājiens.

Piemērs: http://twig.sensiolabs.org/doc/templates.html#template-inheritance

 

Ja blokiem nepieciešami dati, tad labāk tos padot nevis caur kontrolieri vai globālajiem mainīgajiem, bet gan izmantojot helperus/extensionus/templeit-tagus (kā nu kurš templeitu dzinējs tos sauc).

Edited April 10, 2013 by 101111

[capsx]

Interesanti gan, kā "code reuse" varētu būt bad practice?

 

super atbilde - #linux.lv stilā ...