Kāpēc izmantot template engines?

daGrevis · July 20, 2011

Tas gan. LOL.

Rincewind · July 21, 2011

PHP way:

<p class="pagination">

   <?php if ($first_page !== FALSE): ?>
       <a href="<?php echo $page->url($first_page) ?>" rel="first"><?php echo __('First') ?></a>
   <?php else: ?>
       <?php echo __('First') ?>
   <?php endif ?>

   <?php if ($previous_page !== FALSE): ?>
       <a href="<?php echo $page->url($previous_page) ?>" rel="prev"><?php echo __('Previous') ?></a>
   <?php else: ?>
       <?php echo __('Previous') ?>
   <?php endif ?>

   <?php for ($i = 1; $i <= $total_pages; $i++): ?>

       <?php if ($i == $current_page): ?>
           <strong><?php echo $i ?></strong>
       <?php else: ?>
           <a href="<?php echo $page->url($i) ?>"><?php echo $i ?></a>
       <?php endif ?>

   <?php endfor ?>

   <?php if ($next_page !== FALSE): ?>
       <a href="<?php echo $page->url($next_page) ?>" rel="next"><?php echo __('Next') ?></a>
   <?php else: ?>
       <?php echo __('Next') ?>
   <?php endif ?>

   <?php if ($last_page !== FALSE): ?>
       <a href="<?php echo $page->url($last_page) ?>" rel="last"><?php echo __('Last') ?></a>
   <?php else: ?>
       <?php echo __('Last') ?>
   <?php endif ?>

</p><!-- .pagination -->

Mustache way:

<p class="pagination">
{{#items}}
{{#url}}<a href="{{url}}" {{#title}}rel="{{rel}}"{{/title}}>{{/url}}{{#num}}<strong>{{/num}}{{name}}{{#num}}</strong>{{/num}}{{#url}}</a>{{/url}}
{{/items}}
</p>

Kaut vai koda garums, ko redz dizaineris. Vienkārši, vieglāk pēc tam visu būs uzturēt!

Kas tad tas? Ja PHP iedod to pašu masīvu kuru dod tam Mustache tad tak sanāks šitā:

<?php foreach($items as $i):?>
   <a href="<?php echo $i['href']?>"...</a>
<?php endforeach;?>

nemec · September 5, 2011

Iedvesmojoties no jūsu sarunas, esmu nolēmis nopublicēt šādu tēmu http://teit.lv/progr...lonu-dzini.html

Ja kāds vēlas diskutēt vai nopublicēt pretējo tēmu (Kāpēc neizmantot šablonu dzini iekš PHP, vai tamlīdzīgi), varu padalīties ar uzaicinājumu ([email protected]).

daGrevis · September 5, 2011

Vot, vot. Tieši tā... :) Es tikai nemācēju tik sakarīgi izteikties! :D

codez · September 5, 2011

Sākšu ar to, kā es izmantoju templeitus. Tātad man katram kontrolerim ir automātiski piesaistīts noteikts templeits.

//base.ctrl
class Controller_Base extends Controller{
 function index(){
$this['title']='default title';
$this['user']=User::getByID(Auth::id()); //iegūstam ielogotā lietotāja datus
 }
}

//base.tpl
<html>
<head>
 <title><?=$title?></title>
</head>
<body>
 <div id="header">
Hi, <?=$user['name']?>
 </div>
 <div id="content">
<?=$child_content?>
 </div>
</body> 
</html>

//Index.ctrl
class Controller_Index extends Controller{
 public $parent='Base';
 function index(){
$this->parent()->title='Hi, I changed title';
$this['articles']=DB::query('SELECT * FROM articles WHERE uid=%s',Auth::id()); //iegūstam ielogotā lietotāja rakstus
 }
}

//Index.tpl
<?php foreach($articles as $article) { ?>
<div class="article">
 <?=$article['title']?><br />
 <?=$article['text']?>
</div>
<?php } ?>

Tātad, kontroleris ar $parent propertiju var norādīt savu parent kontroleri, kurš automātiski tiks izsaukts un iekļaus savā templeitā $child_content vietā saturu, kuru uzģenerēs child kontroleris.

Atbildēšu uz vienu citātu:

"Vēsturiski jā, bet mūsdienās nodemonstrējiet man, kā jūs veiksiet mantošanu vai visu mainīgo eskeipošana."

Tātad mantošanu veic norādot parent kontroleri.

Savukārt mainīgie tiek nodoti pašai controller klasei, kura ir realizēta kā ArrayAccess un principā ir masīvs. Tā kā templeits tiek ielādēts ar ob_ funkcijām, kur pirms tam tiek tiek extractoti visi masīva mainīgie, tad to eskeipošana ir viens cikls šājā templeita klases funkcijā.

Taču nodemonstrētais piemērs ar twig gan satur būtiskus trūkumus. Teiksim, base templeitā ir headeris, kurš vienmēr izvada kaut kādu informāciju par ielogoto lietotāju. Jautājums - kur šī informācija tiks iegūta? Katrā child.php failā tiks lādēta no jauna? Tādā gadījuma tiek strikti pārkāpts DRY princips. Lādēta base templeitā? Vēl sliktāk, jo netiek atdalīta biznesa loģika no templeita.

Šādi un citādi meklējot labāko ceļu, agri vai vēlu būs jānonāk pie HMVC paterna, pie tam tādā formā, kur katrs kontroleris ir sasaistīts ar templeitu vai vairākiem un tātas lietas kā extendošana notiks kontrolera slānī, nevis templeita slānī.

Tāpat rakstā tiek visu laiku atspēkoti tie plusi, kas ir PHP izmantošanai templeitā, bet netiek norādīts neviens mīnus.

Lieta tāda, ka PHP izmantošanai templeitu valodas vietā ir tikai plusi.

Tad jautājums, kāpēc izmantot to, kas ir sliktāks?

rATRIJS · September 5, 2011

^ what he said

nemec · September 5, 2011

Manā aprakstītā variantā es varu lasīt kopā savus šablonus neatkarīgi no controller`a. Tā pati mantošana, es to varu veikt krustam šķērsam kaut vai 10 līmeņos, paplašinot vairākus block`us, tādā veidā iegūstot sev nepieciešamo šablonu.

base.html

<html>
<body>
<div id="content">
   	{% block content %}{% endblock %}
</div>
</body>
</html>

two-columns.html

{% extends "base.html" %}
{% block content %}
   <div id="menu">
{% block menu %}
   	navigācija
{% endblock %}
   </div>
   <div id="column">
{% block column %}
   	saturs?
{% endblock %}
   </div>
{% endblock %}

banana.html

{% extends "two-columns.html" %}
{% block column %}
banānu saturs
{% endblock %}

<html>
<body>
   <div id="content">
   	<div id="menu">
   	navigācija
</div>
<div id="column">
   	banānu satus
</div>
   </div>
</body>
</html>

Vēlāk varēšu ieviest three-columns.html un tālāk extend`ot kādu jaunu šablonu, nezaudējot saikni ar base.html.

Tavā piedāvā variantā šablons ir atkarīgs no controller`a.

Ja runājam par controller`iem, tad pašam controller`am vajadzētu savstarpēji mantoties un iegūt galu galā nepieciešamos mainīgos, ko var izvadīt beigu šablonā.

Kas notiek ja ir vairāki šabloni, vai piemēram vēl kādi citi formāti (xml, json utt)?

Galvenie trūkumi PHP engine`am:

1) nav dokumentācijas - viss php.net neder

2) ilga jauna speciālista iesaistīšana, tas izriet no pirmā punkta

3) pārāk liela programmētāju patvaļa šablonos

4) escape`ošana un mantošana, šo var risināt protams, bet atkal katrs to risina pa savam un tas nav labi.

Vēlētos apskatīties kā pārēji veido savus šablonus, varētu kādus piemērus samest.

v3rb0 · September 5, 2011

3. un 4. punkts ir sociāla problēma.

Sociālas problēmas nevar atrisināt ar tehniskiem līdzekļiem (frāze no code.google.com izstrādātāju prezentācijas). Ja dikti sāpēs, atradīs arī veidu kā apiet templeitu engine - kaut vai echo un die() kaut kur actiona sākumā.

Edited September 5, 2011 by v3rb0

codez · September 5, 2011

Manā aprakstītā variantā es varu lasīt kopā savus šablonus neatkarīgi no controller`a. Tā pati mantošana, es to varu veikt krustam šķērsam kaut vai 10 līmeņos, paplašinot vairākus block`us, tādā veidā iegūstot sev nepieciešamo šablonu.

Man jebkuram kontrolerim var būt parent kontroleris, līdz ar to arī var veidoties struktūra 10 līmeņos un dažādās kombinācijās.

Tavā piedāvā variantā šablons ir atkarīgs no controller`a.

Jā, bet tas ir pluss,

1)jau tāpēc, ka mantošanās raksturo jau aplikācijas struktūru un nekādi nav šablonam piederoša loģika. Tai jābūt ir kotrnolerī.

2)Tu nenodemostrēji, kā tu ar plikiem šabloniem izveidosi to, lai katra parent šablona dinamiskā informācija vienmēr tiktu ielādēta un nebūtu jālādē vietā, kur tiek izsaukts child šablons. Respektīvi, ja parent šablonā ir dinamiska informācija no db, tad manā gadījumā parent šablona kontrolieris nodrošinās tās ielādi un man nebūs viņa jālādē child kontrolierī, jo pietiks tikai norādīt kurš ir parent kontrolieris un viņš automātiski tiks izpildīts. Bet kā tas notiks, ja sasaiste uz parent šablonu ir pa tiešo šablonā un child kontrolieris nezin, kurš ir parent kontrolieris un tātad lādē pats? Bet kā tad ar to, ka vienu parent šablonu manto 10 citi neatkarīgi šabloni - vai visu child šablonu kontrolieros būs jālādē parent šablona dinamiskā informācija?

Ja runājam par controller`iem, tad pašam controller`am vajadzētu savstarpēji mantoties un iegūt galu galā nepieciešamos mainīgos, ko var izvadīt beigu šablonā.

Nē, jo tad pazūt loose coupling princips. Manā uztverē katrs kontrolieris ir pilnīgi neatkarīgs un var tikt izpildīts neatkarīgi. Bez tam, var būt, ka parent kontrolerī ar $title tiek apzīmērs <title> saturs, kamēr child kontrolerī tas apzīmē raksta virsrakstu.

Kas notiek ja ir vairāki šabloni, vai piemēram vēl kādi citi formāti (xml, json utt)?

Vairāki šabloni bez problēmām ir iespējami un kontrolera loģika manā variantā var izmainīt defaulto šablona failu uz citu.

Kas attiecas uz vairāku formātu paralēlu atbalstu, tad manā variantā tas nozīmētu, ka jāekstento Controller klase, teiksim uz MultiFormatController un jāpieliek viens papildus parametrs, kurš nosaka, kurš būs defaultais templeita fails. Pārējais viss tapatās.

Galvenie trūkumi PHP engine`am:

1) nav dokumentācijas - viss php.net neder

Tur jau tā lieta, ka dokumentāciju arī nevajag, jo mēs jau zinām PHP.

2) ilga jauna speciālista iesaistīšana, tas izriet no pirmā punkta

Pieredze rāda, ka kontrolierus un tiem atbilstošos šablonus daudz efektīvāk rada viens un tas pats cilvēks, nevis kontroleri vien PHP guru, bet templeitu kaut kāds, kurš stundu lasījis templeitu dzinēja dokumentāciju. Bez tam tāpat ir jābūt HTML, CSS, JS zināšanām. Līdz ar to šādam speciālistam tā vai tā PHP ir jāzin, līdz ar to iesaistīšanas laik ir 0.

3) pārāk liela programmētāju patvaļa šablonos

Tas pats - realitātē šablonus raksta tas pats, kurš raksta kontrolerus, tāpēc tas nav arguments, jo šādā gadījumā viņam kontrolerī ir pārāk liela patvaļa. Šis vairāk ir veselā saprāta un uzņēmuma iekšējās darba organizācijas un standartu jautājums, kur jautājums par patvaļu šablonos ir sniegpārsliņa uz aizberga.

4) escape`ošana un mantošana, šo var risināt protams, bet atkal katrs to risina pa savam un tas nav labi.

Nu bet šablonu dzinējos eskeipošanu un mantošanu katrā dzinējā katrs arī risina par savam, citos vispār pat nav.

Tiešā tāpat PHP viena FW ietvaros, šis risinājums paliek nemainīgs.

nemec · September 5, 2011

2)Tu nenodemostrēji, kā tu ar plikiem šabloniem izveidosi to, lai katra parent šablona dinamiskā informācija vienmēr tiktu ielādēta un nebūtu jālādē vietā, kur tiek izsaukts child šablons. Respektīvi, ja parent šablonā ir dinamiska informācija no db, tad manā gadījumā parent šablona kontrolieris nodrošinās tās ielādi un man nebūs viņa jālādē child kontrolierī, jo pietiks tikai norādīt kurš ir parent kontrolieris un viņš automātiski tiks izpildīts. Bet kā tas notiks, ja sasaiste uz parent šablonu ir pa tiešo šablonā un child kontrolieris nezin, kurš ir parent kontrolieris un tātad lādē pats? Bet kā tad ar to, ka vienu parent šablonu manto 10 citi neatkarīgi šabloni - vai visu child šablonu kontrolieros būs jālādē parent šablona dinamiskā informācija?

Tātad ir šabloni un ir contoller`is - divas atšķirīgas lietas.

Mazliet pielabosim šablonu two-columns.html

{% extends "base.html" %}
{% block content %}
   <div id="menu">
{% block menu %}
   	    hello {{ username }}
{% endblock %}
   </div>
   <div id="column">
{% block column %}
   	saturs?
{% endblock %}
   </div>
{% endblock %}

Atstājam to pašu banana.html bez izmaiņām. Tātad pirms šis šablons tiks apstrādāts, tas izskatīsies šādi:

<html>
<body>
   <div id="content">
   	<div id="menu">
   	    hello {{ username }}
</div>
<div id="column">
   	banānu satus
</div>
   </div>
</body>
</html>

Un tieši tādā izskatā tiks padots controller`im.

Šim šablonam mainīgos pados tieši tāds pats controller`ies, kādu biji aprakstījis savā piemēra.

Nevajadzēja piesaukt controller`i, tikai vēl sarežģījām situāciju.

Tas pats - realitātē šablonus raksta tas pats, kurš raksta kontrolerus, tāpēc tas nav arguments, jo šādā gadījumā viņam kontrolerī ir pārāk liela patvaļa. Šis vairāk ir veselā saprāta un uzņēmuma iekšējās darba organizācijas un standartu jautājums, kur jautājums par patvaļu šablonos ir sniegpārsliņa uz aizberga.

Šodien raksta viens, citu dienu otrs.

Ja ir tik liela uzticība, tad var atļaut rakstīt PHP, bet tas tomēr atstās tādu nedrošības sajūtu.

Jebkurā gadījumā, ja lietot variantu ar PHP, tad ir jāreglamentē - ko tajos šablonos drīkst un ko nē, lai nenonākt spageti kodā.

codez · September 6, 2011

Un tieši tādā izskatā tiks padots controller`im.

Šim šablonam mainīgos pados tieši tāds pats controller`ies, kādu biji aprakstījis savā piemēra.

Nevajadzēja piesaukt controller`i, tikai vēl sarežģījām situāciju.

Nu ok, tik daudz es saprotu, bet vai tu saproti, ko es cenšos pateikt - teiksim tev two-columns.html šablonā ir dati {{username}}, tagad tev ir šis banana.html, kurš extendo. Bet reālā variantā būs vēl apple.html, pear.html, orange.html, pinacle.html, utt., kur visi extendos two-columns.html. Tagad teiksim ir kontroleri banana.php, apple.php, utt., katrs sagatavo datus priekš šablona un izsauc šablona renderēšanu. Tavā variantā katrā no kontroleriem ir jāsagatavo {{username}} mainīgais, kaut gan tas attiecas konkrēti uz two-columns.html šablonu. Šādā veidā tu N kontrolieros darīsi vienu un to pašu, kamēr manā variantā parent šabloniem katram ir savs kontrolieris, kurš sagatavo datus šablonam.

Un kontrolieri vajadzēja piesaukt, jo tas tieši parādīja to, ka parentu piesaiste ir jātaisa kontroleru slānī, nevis šablonu slānī, lai varētu pilnībā ievērot DRY principu un loose coupling principu.

Piemēram, ja man ir kontroleris child.ctrl un parent1.ctrl un parent2.ctrl un katram no tiem ir savs šablons ar dinamiskiem datiem. Ja man sākumā ir child.ctrl ar parentu parent1.ctrl, tad, ja es gribu nomainīt parentu un parent2.ctrl, es to arī daru un man nav nekas jāmaina datu apstrādē nevienā no kontroleriem, jo katrs no kotroleriem atbild par sava šablona datiem un child.ctrl neinteresē kādi ir konkrētā parent kontrolera dinamiskie dati, jo tos sagatavos attiecīgais parent kontroleris. Tiek skaisti ievērots loose coupling princips. Kamēr extendojot šablonu līmenī, child šablonu izsaucošajam kontrolerim jāsagatavo informācija arī priekš ekstendotā parent šablona.

Šodien raksta viens, citu dienu otrs.

Ja ir tik liela uzticība, tad var atļaut rakstīt PHP, bet tas tomēr atstās tādu nedrošības sajūtu.

Jebkurā gadījumā, ja lietot variantu ar PHP, tad ir jāreglamentē - ko tajos šablonos drīkst un ko nē, lai nenonākt spageti kodā.

Bet, ja kāds cits reaģēs kodu, tad reāli viņš būs ar PHP zināšanām, jo šabloni ir pietiekami cieši saistīti ar kontroleriem, lai kāds cits, neizprotot ko un kā izpilda šablonu, varētu to neatkarīgi no kontroliera rediģēt.

Kas attiecas uz nedrošības sajūtum, tad tā tiek atstāta arī kontrolieru rakstītājiem, modeļu rakstītajiem, cores rakstītājiem, serveru administrātoriem, db administrātoriem un tā kā šablonus parasti raksta tie paši, kuri kontrolerus, tad drošības sajūta ne palielinājās, ne samazinājās no tā, jo tikpat labi nav zināms kā viņš rakstīs kontroleri. Tieši tāpēc tas ir uzņēmuma iekšējās organizācijas un standartu jautājums, nevis tehnisko rīgu jautājums.

Jebkurā gadījumā, ja lietot variantu ar PHP, tad ir jāreglamentē - ko tajos šablonos drīkst un ko nē, lai nenonākt spageti kodā.

Iedod man jebkuru šablonu dzinēju un es uzrakstīšu skaistu špageti kodu. Šis atkal ir citas tēmas jautājums - vairāk veselā saprāta.

nemec · September 6, 2011

Nu ok, tik daudz es saprotu, bet vai tu saproti, ko es cenšos pateikt - teiksim tev two-columns.html šablonā ir dati {{username}}, tagad tev ir šis banana.html, kurš extendo. Bet reālā variantā būs vēl apple.html, pear.html, orange.html, pinacle.html, utt., kur visi extendos two-columns.html. Tagad teiksim ir kontroleri banana.php, apple.php, utt., katrs sagatavo datus priekš šablona un izsauc šablona renderēšanu. Tavā variantā katrā no kontroleriem ir jāsagatavo {{username}} mainīgais, kaut gan tas attiecas konkrēti uz two-columns.html šablonu. Šādā veidā tu N kontrolieros darīsi vienu un to pašu, kamēr manā variantā parent šabloniem katram ir savs kontrolieris, kurš sagatavo datus šablonam.

Un kontrolieri vajadzēja piesaukt, jo tas tieši parādīja to, ka parentu piesaiste ir jātaisa kontroleru slānī, nevis šablonu slānī, lai varētu pilnībā ievērot DRY principu un loose coupling principu.

Piemēram, ja man ir kontroleris child.ctrl un parent1.ctrl un parent2.ctrl un katram no tiem ir savs šablons ar dinamiskiem datiem. Ja man sākumā ir child.ctrl ar parentu parent1.ctrl, tad, ja es gribu nomainīt parentu un parent2.ctrl, es to arī daru un man nav nekas jāmaina datu apstrādē nevienā no kontroleriem, jo katrs no kotroleriem atbild par sava šablona datiem un child.ctrl neinteresē kādi ir konkrētā parent kontrolera dinamiskie dati, jo tos sagatavos attiecīgais parent kontroleris. Tiek skaisti ievērots loose coupling princips. Kamēr extendojot šablonu līmenī, child šablonu izsaucošajam kontrolerim jāsagatavo informācija arī priekš ekstendotā parent šablona.

Te jau drīzāk ir runa par to, kā organizēt kodu - šablonu un cotroller`i. Es redzu stipru akarību tavā piemērā.

Es daru tā, ka ir visādas neatkarīgas klases User, Gallery utt.

Savukārt Controller`is norāda, kādi dati ir nepieciešami un kādus datus vajag salasīt - User, Gallery utt.

Tad es varu norādīt base.html, ja ir nodefinēts {{ username }}, tad to izvadam (vai izvadam kaut kādu block`u), ja nē, tad neko nerādam.

Kā to realizēt ar tavu piemēru? Ja es nevelos attēlot User datus, tad $this->parent()->user = false?

codez · September 6, 2011

Te jau drīzāk ir runa par to, kā organizēt kodu - šablonu un cotroller`i. Es redzu stipru akarību tavā piemērā.

Jā ir stipra atkarība starp kontroleri un tā šablonu, tāpēc, ka pēc būtības tie ir stipri atkarīgi, bet nav nekādas atkarības starp svešiem kontrolierim un svešiem šabloniem, kamēr tavā piemērā child kontrolierim ir jāpiegādā dati arī parent šablonam.

Es daru tā, ka ir visādas neatkarīgas klases User, Gallery utt.

Savukārt Controller`is norāda, kādi dati ir nepieciešami un kādus datus vajag salasīt - User, Gallery utt.

Nu jā tā ir, bet labāk, ja datu salasīšana atkārtojas (parent šablonā, neatkarīgi no child šablona, vienmēr būs kaut kādi savi dati, kururs atlasa pēc noteikta veida,piemēram, headerī tas būs ielogotā lietotāja username), tad labāk to darīt vienreiz - tādā veidā parādās absolūta nepieciešamība pēc parent kontroliera.

Savukārt, tavs variants, ka ekstendošana notiek šablonu līmenī, neļauj izveidot atsevišķu datu atlasi priekš parent šablona, tādā veidā kontrolerī, kurā tu izsauc child šablonu, tev vienmēr būs jāatlasa dati priekš parent kontroliera, pat, ja tu tos ieliec citā klasē, tev tik un tā būs vien rindiņa, kura šos datus atlasīs (izjauks loose coupling principu) un šī viena rindiņa atkārtosies visos child kontroleros (izjauks DRY principu). Respektīvi, ja tu gribēsi tagad 10 child kontroleriem nomainīt parent šablonu, tev 10 šablonos nāksies mainīt extendoto šablonu (kas ir tas, ko tu vēlies panākt), bet desmit kontroleru kodos nāksies mainīt datu atlases mehānismu priekš parent šablona (kas jau ir liekais darbs).

Tad es varu norādīt base.html, ja ir nodefinēts {{ username }}, tad to izvadam (vai izvadam kaut kādu block`u), ja nē, tad neko nerādam.

Nav jau runa tikai par to kā šablons reaģēs uz to username, bet gan par to, kā un kurā vietā šis username tik iegūts.

Kā to realizēt ar tavu piemēru? Ja es nevelos attēlot User datus, tad $this->parent()->user = false?

Manā variantā, ja nevēlas attēlot datus, vai kaut kā citādi iedarboties un parent kontrolieri, tad, jā, to dara caur $this->parent(), papildus man vēl ir $this->top(), kas ir pats pēdējais parents. Reāli praksē uz parent kontrolieri man vajag iedarboties tikai retos gadījumos un tie ir, pievienot specifisku JS, CSS failus un nomainīt title. Tad es to daru.

$this->top()->addJS('/js/some.js');

$this->top()->setTitle('New title');

Bet, ja gadījumā man vajadzētu, lai child kontrolieris ietkemē kaut ko parent šablonā, tad es varu izmainīt parent kontroliera patotos datus šablonam uz to iedarbojoties caur $this->parent().

Taču es nespēju iztēloties praksē šādu situāciju. Reāli, ja būtu sadaļas, kurām atšķirās parent kontrolieri, tad es arī taisītu divus atšķirīgus parent kontrolierus (kuri savukārt ekstendo kopīgo) un attiecīgi vajadzīgo ekstendotu, nevis taisītu vienu, kuram nodot parametru kā viņam uzvesties, atkarībā no child kontroliera.

nemec · September 6, 2011

Tad ar tādu public $parent='Base'; arī tiek pārkāpts DRY princips?

Es sarakstu visādas klases, kā jau minēju - User, Gallery utt (tieši šajās klasēs varu sakešot datus). Tad varu uzrakstīt ParentController, kurš piemēram šīs klase manto (dati tiek sagatavoti iepriekšminētās klasēs). Tad varu vēl kādu Controller`i uzrakstīt, tādā veidā salasot tikai man vajadzīgos datus. Un beigu beigās pieslēdzu šablonu.

Varētu to darīt tā UserGalleryController: public $parent = 'User, Gallery'.

Scenārijs ir tāds, ir this.context UserGalleryController`am, un šis context tiek papildināts atkarībā no pieslēgtām klasēm (User, Gallery), sabāžot mainīgajā savus datus.

Ja salasīšana atkārtojas, tad var norādīt BaseController`i, kas jau salasa kaut kādus datus (extend`o User piemēram) un tālāk extend`oties no tā.

Sign In

Kāpēc izmantot template engines?

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation