ugrás a tartalomhoz

Template

dorten · 2012. Ápr. 2. (H), 02.46
Sziasztok!

Egy egyszerű template kezelőt készítek, és elakadtam benne. Adott egy html fájl, amely valamilyen kódot tartalmaz, most például legyen hozzászólásokhoz tartozó html.
Régebben az xTemplate-ben láttam olyat, hogy a blokkok egymásba voltak ágyazva:

<!-- BEGIN: hozzaszolasok -->
     <h1>Eddigi hozzaszolasok</h1>

     <!-- BEGIN: nev -->
          <h2>{NEV}</h2>
     <!-- END: nev -->

     <!-- BEGIN: szoveg -->
          <div>{HOZZASZOLAS}</div>
     <!-- END: szoveg -->

<!-- END: hozzaszolasok -->
Odáig rendben vagyok, hogy kiszedem a <!-- --> tagek közti tartalmat, ha nincs egybeágyazás. Viszont ha egybe van ágyazva, mint a példában, akkor visszakapom az aktuális tag tartalmát plussz az az előtt lévő tartalmat is. Egész pontosan így szeretném a tartalmakat megkapni (mindig csak az aktuális részre vonatkozót):

$blokkok = array(
    'html_fajl_neve' => array(
        'hozzaszolasok' =>  '<h1>...</h1>',
        'nev'           =>  '<h2>...</h2>',
        'szoveg'        =>  '<div>...</div>'
));
Egybeágyazás nélkül preg_replace_callback segítségével el tudom tárolni a blokkok nevét és hozzájuk a tartalmat.

A segítséget köszönöm!
‹ Asszociatív tömb rendezése minta alapján hozzáférés korzlátozás ›
 ■
1

XSLT

Hidvégi Gábor · 2012. Ápr. 2. (H), 08.46
Sok munkát spórolhatsz meg magadnak, ha már kész sablonozórendszert használsz, például az XSLT-t. Több előnnyel jár, például kliens- és szerveroldalon is natívan kezelik a böngészők és az operációs rendszerek, az adatokat különválaszthatod a megjelenésüktől.
2

Miért?

Poetro · 2012. Ápr. 2. (H), 09.50
Egyáltalán miért van szükség sablonozó rendszerre, mikor a PHP maga is képes mindenre. Sőt, 5.4 óta a short open tag is alapértelmezett, azaz lehet simán használni a <?= $valtozo ?> formát. Egy template fájl renderelése pedig ekkor leredukálódna a következőkre:
function render_template($template_file, $variables) {
  extract($variables, EXTR_SKIP); // Extract the variables to a local namespace
  ob_start(); // Start output buffering
  include APP_ROOT . '/' . $template_file; // Include the template file
  return ob_get_clean(); // End buffering and return its contents
}
Forrás: theme_render_template
3

Mert külön akarják választani a megjelenítést.

pp · 2012. Ápr. 2. (H), 11.02
Csak éppen azt hiszik, erre megoldás a sablon, holott az eszköz (sablon) nem fogja számára biztosítani a szétválasztást. :)

pp
4

HTML template helyett

Vilmos · 2013. Okt. 21. (H), 11.26
Nagy kérdés, miért lett a lefordítandó "template" ennyire elterjedt. A tiszta PHP sablon jobbnak látszik, az minden körülmények között működik, de szerintem egyik sem az igazi. Egyszerűen nem váltják be az ígéretet, a kód és a html szétválasztását. Pedig, eddig minden ténykedés sikeres volt ami a html szövegből kipakolt dolgokat. Lásd: CSS, külön fájlban, JS külön fájlban. Maradhat egyben is, de jobb így.
A szerver oldalon tartja magát a vegyítés. Tudom, az MVC elmélet kifejti, mire jó a szétválasztás, és miért mégsem, de aki először hallja a varázslatos mondatot, az szó szerint veszi. A valóság hervasztó. Hozzá sem kezd a szétválasztáshoz aki sablonnal dolgozik.

Abban az időben, amikor a hozzászólás készült, éppen tanuló fázisban voltam. Form-mal és a html-css párossal kapcsolatban voltak hiányosságaim.(A PHP részt hamarabb ismertem.) Egyszerű, készítesz egy működő oldalt, a szerver oldalt szintén megírod, és közben tanulsz is. Ha kész, akkor kap az oldal segítséget a dizájn miatt. A demó változat fapados grafikus szemmel.

Itt azért van egy kis gond. Oldal tervezés ok, csakhogy élesben feltöltendő adatbázisból egy része. Megoldások: (kihagytam valamit?)

1 - Vegyített kód PHP nyelven,
2 - Vegyített kód sablon nyelven,
3 - Oldal előállítása PHP echo utasításokkal(tartalom generálás helper modulokkal, azt hiszem így hívják)
4 - Oldal felépítése böngésző oldalon, ezt most hagyjuk,
5 - Eredeti html szöveg kiegészítése.

Az utolsó az ami praktikusnak látszott. Ha egyszerre kell html-t és php-t programozni, hol ezt, hol azt, akkor jobb ha nem olvasztom be szerver kódba az oldal szövegét. Ráadásul kétirányú kapcsolatban maradhatok a dizájnerrel.

A legtöbb sablon motor az 1. és a 2. pontot valósítja meg. Az 5. pont szerint a bevezetőben említett "xTemplate" dolgozik. Felszerszámozod az oldalt blokk jelölésekkel, és csere változókkal. Megjeleníthető a tartalom simán böngészővel, méghozzá jól, és feldolgozható szerver oldalon is. Király. (A sablont- *.xtpl - át kell nevezni html-re akkor megy a böngészős nézegetés, a kiterjesztés a feldolgozó objektumot nem érdekli.)


Kérdésem:

- Kinek praktikus egy ilyen "xTemplate" sablonozó, és kinek nem?
( Rosszul teszem ha rá szavazok ?)

- Kezdésnek praktikusnak látszik, sokkal inkább mint a nagyágyúk. A klasszikus vegyítésről nem is beszélve. Mégis, találkozni csak véletlen lehet vele. Valahol kevés lesz az a szemlélet amit képvisel ?


Köszönöm a válaszokat előre is.
5

Ha egyedül dolgozol, akkor

Hidvégi Gábor · 2013. Okt. 21. (H), 12.02
Ha egyedül dolgozol, akkor nem érdemes sablonrendszerekkel lassítani a futást, ezeknek akkor van igazán értelme, ha többen vagytok. A lefordított sablonok még akkor is jók, ha a kliensnek szánt html kódot szeretnéd egyszerű eszközökkel előállítani.
6

Kisebb projekteknél szoktam

bamegakapa · 2013. Okt. 21. (H), 12.41
Kisebb projekteknél szoktam volt a PHP sablonozó lehetőségeit használni (alternatív szintaxis a vezérlőszerkezetekhez, meg persze <?=$x?>). Ahogy Gábor is írja, ez egyemberes, tényleg apró projektekhez pont elég is.

Smarty-t és társait soha nem értettem, minek, többet árt, mint használ. Tapasztalatom ezekről mondjuk nincs számottevő.

Az utóbbi időben a Mustache nevű templating megoldással dolgoztam, szerintem kiváló, ahogy állítja magáról, "logicless" és számtalan nyelvre van már hozzá bejáratott implementáció. Nagy könnyebség, hogy ugyanaz a template kliens- és szerveroldalon egyaránt használható, barátibb megvalósítani a fallbacket, ha a kliensen nincs Javascript, illetve a mozgástered is nagyobb. Úgy látom az xTemplate is hasonló logikát követ, javíts ki, ha tévedek, nem néztem nagyon utána. Próbáltam már kisebb projekteknél is a Mustache-t, szerintem oda is kiváló megoldás, átláthatóbb és rugalmasabb lesz minden. Az elején bele kell szokni, hogy nem irkálhatsz PHP-t a template-be (lustaság+megszokás+sietség eredménye, hogy kisebb projekteknél az ember néha azt mondja, na jó, gyorsan lekérem itt a template-be az adatbázisból ezt az egy dolgot vagy összeadom ezt a két értéket, nem lesz baj). Futottam vele akadályokba, az tény, de az többnyire az én rossz szemléletem miatt volt, nem a Mustache miatt.
7

A smarty és társai arra jók,

Hidvégi Gábor · 2013. Okt. 21. (H), 12.56
A smarty és társai arra jók, hogy a programkódot különválassza a megjelenítéstől. Sitebuilderként elég egy egyszerű szintaxist megtanulnom, nem kell ismernem a php-ét, nem kell ismernem a fájlstruktúrát, külön fájlba dolgozhatok, ami a saját könyvtárban lehet saját írási jogosultságokkal, és, ha le van tiltva a php kódrészlet beszúrásának lehetősége, akkor még nagy disznóságot sem csinálhatok.
9

Mindamellett, hogy értem és

Joó Ádám · 2013. Okt. 21. (H), 13.10
Mindamellett, hogy értem és megértem az ilyen jellegű törekvést, de néha úgy érzem, mintha a legtöbb helyen semmilyen formában sem volna a különböző csapattagok által írt kód ellenőrzése és integrálása feladata valakinek. Ezt elég nagy bajnak tartom.
11

Nem igazán értem, amit írsz,

Hidvégi Gábor · 2013. Okt. 21. (H), 13.48
Nem igazán értem, amit írsz, kifejthetnéd bővebben, hogy miben látod a problémát, és hogy ez mit eredményez.
Mindenki a maga kódját ellenőrzi, de mit szeretnél integrálni?
12

Code review

Poetro · 2013. Okt. 21. (H), 13.55
Minden esetben egy kollegának kellene ellenőríznie a kódot, mert több szem többet lát. És amikor kész van egy új szolgáltatás, akkor azt bele kell integrálni az alkalmazásba, amit legjobb, ha egy harmadik személy tesz meg, neki lehetőleg ez legyen az egyik fő feladata.
13

Ez oké, de mi köze ennek a

Hidvégi Gábor · 2013. Okt. 21. (H), 13.59
Ez oké, de mi köze ennek a sablonozáshoz?
14

ha le van tiltva a php

Joó Ádám · 2013. Okt. 21. (H), 14.05
ha le van tiltva a php kódrészlet beszúrásának lehetősége, akkor még nagy disznóságot sem csinálhatok


A sablonrendszerek használata melletti, nagyon elterjedt érvként ez az, ami arra enged következtetni, hogy hiányzik a code review. Ha lenne, aki átnézi a kódot, akkor ő kiszúrná, ha emailt küldesz sablonból.
17

Biztos nincs rá keret.

Hidvégi Gábor · 2013. Okt. 21. (H), 14.27
Biztos nincs rá keret.
16

Azt én értem, de mégis kötve

bamegakapa · 2013. Okt. 21. (H), 14.11
Azt én értem, de mégis kötve maradsz a PHP-hoz. Akkora hasznát sose láttam a sima PHP-s template-ezéshez képest, hiszen ha csak template-et csinálsz PHP-vel, kb. 5-6 dolgot kell megtanulnod, a nyelvet nem kell ismerni. Így viszont meg kell tanulnod egy másik szintaxist :).
28

Mustache? http://weblabor.hu

deejayy · 2013. Okt. 21. (H), 19.53
Mustache?

http://weblabor.hu/blog/20100814/php-alapu-sablonmegoldas#comment-70235
29

Nem rossz, de a Mustache

bamegakapa · 2013. Okt. 22. (K), 00.22
Nem rossz, de a Mustache azért táposabb ;).
8

Nagyon régen én is emellett

Joó Ádám · 2013. Okt. 21. (H), 13.03
Nagyon régen én is emellett tettem le végül a voksom. Aztán rájöttem, hogy felesleges erőforráspazarlás, és utána maradtam a PHP kódnál, mint sablonyelvnél, elvégre erre találták ki.
10

A PHP sablonnyelvnek egyrészt

tgr · 2013. Okt. 21. (H), 13.45
A PHP sablonnyelvnek egyrészt ronda, másrészt nem biztonságos. Alapértelmezett escape-elés nélkül nem mernék nekivágni egy komolyabb projektnek.

És hát ha erre találták ki, akkor nem végeztek túl jó munkát. Melyik az olvashatóbb:

<?php if !empty($users): ?>
    <?php foreach ($users as $user): ?>
        <div><?php echo htmlspecialchars($user->name) ?></div>
    <?php endforeach ?>
<?php else: ?>
    <p><?php echo htmlspecialchars(t('Nincs találat!')) ?></p>
<?php endif ?>
vagy

{% for user in users %}
    <div>{{ user.name }}</div>
{% else %}
    <p>{% trans %}Nincs találat!{% endtrans %}</p>
{% endfor %}
15

Ebben teljesen egyetértek

Joó Ádám · 2013. Okt. 21. (H), 14.07
Ebben teljesen egyetértek veled. A escape-elés és a jól formázott kód igénye miatt tértem én is át a hagyományos sablonozásról egy ideje a programozott XML generálásra.
18

Szerintem mindkettő ronda, én

inf · 2013. Okt. 21. (H), 15.55
Szerintem mindkettő ronda, én inkább megírom DOM fa építéssel az egészet, az újrahasznosítható részét a kódnak meg kiszervezem külön osztályokba.

if (!isset($users))
	return html\p(trans('Nincs találat!'))
foreach ($users as $user)
	html\div($user->name);
19

Aztán amikor jön a

tgr · 2013. Okt. 21. (H), 16.00
Aztán amikor jön a frontendes, hogy átírná a HTML részt az új design szerint, akkor elküldöd, hogy tanulja meg a PHP OOP programozást?

Másrészt a sablonok lassúak, éles környezetben le szeretné fordítani őket az ember nyers php sablonokra; egy fákat manipuláló kóddal némileg nehezebb ezt megtenni, mint egy sablon-alapúval.
20

Ez igaz. :-)

inf · 2013. Okt. 21. (H), 16.01
Ez igaz. :-) Fát sosem fogsz lefordítani php sablonra. Túl bonyolult feladat... Hmm mondjuk most, hogy már vannak closure-ok, talán egyszerűbb...

Eddig mondjuk nem nagyon láttam hátrányát ennek a megközelítésnek, de nem is csináltam nagy terhelésű rendszereket eddig... Nem tudom, hogy sebesség különbségben mennyit számít mindez egy jól cachelt kódnál. Gyanítom nem sokat...
21

xTemplate

Vilmos · 2013. Okt. 21. (H), 16.03
A PHP semmilyen be és kimeneten nem biztonságos alapból, ebben egyetértünk. A kimeneten az escape-lés azért két esélyes, alapból legyen, de sokszor kell generált kódot beilleszteni, ott viszont kerülendő.

Szerintem az "xTemplate" használatával (is) szép kódot kapunk. Tetszik, jobban mint más megoldások.

A kacsacsőr-kérdőjel kombó váltogatás html-tag sorozattal, na az az ami kiveri nálam a biztosítékot, projekt mérettől függetlenül. Különösen soron belül halmozva csodaszép. Hol van itt bármi külön választva? Nem tudom mi a helyes kifejezés erre az ősrégi dologra, talán a "webassembly" kifejezi a lényeget.

Az sem lehet véletlen, hogy többségünk menekül ettől, ki merre lát alapon. Egyéni preferenciák abban nyilvánulnak meg, hogy kinek a generált kód, kinek egy elegáns sablon nyelv a megfelelőbb. És meg is van az eredménye. Bármi hatékonyabb mint az alapból biztosított, tanított (sajnos), kevert kód. Az külön baj, hogy a sokunk által igényelt fejlettebb, de egyszerű lib-ek vagy nem működnek, vagy biztonsági hiányokkal küzdenek.

Szerintem a "Mustache" nem hasonlít, egy kód generátor van mögötte. Az "xTemplate" állítólag a drupal alap sablon nyelve, remélhetőleg nem tévedésből. Pont az benne az érdekes, hogy a sitebuilder kódját közvetlenül fel lehet használni. Minimális teendő van vele. Ha a web lap modelljének tekintjük, akkor a szerver oldali adatok helyét csak jelölni kell, és kész. A modell feltöltését már külön PHP program végezheti. Egyszerűbb esetekre alkalmazható, PHP nyelven működik, és nincs AJAX támogatás sem. Mondjuk egy webáruházhoz több mint elegendő. (kipróbáltuk)

A DOM fa építése érdekes kérdés. Ha a böngésző oldalon rakod össze az oldalt, akkor gondolom hasznos (nem próbáltam). Azonban, érdemes megfigyelni, hogy a sablonozó rendszerek, bár tiszteletben tartják a html struktúrát, nem foglalkoznak a DOM-mal. Nem is kell tudniuk mit jelent, elvannak nélküle.


xTemplate: A sablon html forrása

<body>
   <!-- BEGIN: table -->
      <table>
         <tr> <th>id</th> <th>name</th> <th>age</th> </tr>

         <!-- BEGIN: row -->
         <tr>
            <td> {DATA.ID} </td>
            <td> {DATA.NAME} </td>
            <td> {DATA.AGE} </td>
         </tr>
         <!-- END: row -->

      </table>
   <!-- END: table -->
</body>
xTemplate: Feltöltő PHP modul

   include_once('./xtemplate.class.php');

   $xtpl = new XTemplate('ex1.html');

   // add some data
   $rows[]=array('ID'=>'38', 'NAME'=>'cocomp', 'AGE'=>'33');
   $rows[]=array('ID'=>'27', 'NAME'=>'linkhogthrob', 'AGE'=>'34');
   $rows[]=array('ID'=>'56', 'NAME'=>'pingu', 'AGE'=>'23');

   for ($i = 0; $i <= count($rows)-1; $i++ ) {
      // assign array data, parse a row
      $xtpl->assign('DATA', $rows[$i]);
      $xtpl->parse('main.table.row');
   }

   // parse the table
   $xtpl->parse('main.table');
24

A Drupal alap sablonnyelve a

tgr · 2013. Okt. 21. (H), 16.21
A Drupal alap sablonnyelve a PHP (illetve Drupal 8-tól már azt hiszem a Twig).
27

Aham. Gyökeresen nem más,

bamegakapa · 2013. Okt. 21. (H), 17.20
Aham. Gyökeresen nem más, mint a Mustache, de a template-ből a HTML kimenet generálása macerásabbnak tűnik. Kódot kell írni hozzá (for ciklus jelen esetben), ezért a logikát duplikálni kell, ha kliens oldalon is használni akarod a template-t.

De amúgy használhatónak tűnik, ha nincs ilyen igényed.
31

Hogyan terjed a fals info

pp · 2013. Okt. 22. (K), 07.37
"Az "xTemplate" állítólag a drupal alap sablon nyelve, remélhetőleg nem tévedésből."

Lassan 10 éve nem az.

Kellett hozzá nem is 1 perc google:
http://drupal.hu/hirek/20050505/phptemplate
22

PHP vs HTML

mz82 · 2013. Okt. 21. (H), 16.09
Mindig meglepődök az ilyen sablon/nem sablon vitákon. El sem tudnám képzelni sablonhasználat nélkül a fejlesztést. Eleinte saját template kezelőt használtam, mostanában tértem át Smarty-ra.
A <?php ?> folyamatos használatától nekem égnek áll a hajam! Mindig olyan érzésem van tőle, mintha "csuklana" a kódfeldolgozó. Mintha nem tudnánk eldönteni milyen programnyelven is szeretnénk kódolni!
23

Nekem a sablonnyelvektől van

inf · 2013. Okt. 21. (H), 16.16
Nekem a sablonnyelvektől van ilyen érzésem, nem értem minek újra és újra feltalálni a kereket... Maga a sablonozás kis méretben jó dolog, de ahogy bonyolódik a megjelenítés módja, úgy egyre hátrányosabb lesz. Gyakorlatilag egy új nyelvet kell kitalálnod nulláról, aztán azt átfordítani php-ra. Nagy méretekben semmi értelme szerintem. Kis méretben, pl sql template, route template elég jól használható megoldás.

Tesztelni fogom a simpleXML-t, kíváncsi vagyok, hogy alkalmas e HTML építésére, és hogy egy sablonhoz képest mennyivel lassabb...
25

Nem kötelező a sablonnyelv

mz82 · 2013. Okt. 21. (H), 16.22
Sablonhasználat még nem jelenti kötelezően sablonnyelv használatot. Csak akkor a vezérlési szerkezetek nem könnyítik a munkát.
26

sablonnyelv nélkül

mz82 · 2013. Okt. 21. (H), 16.34
Sablonnyelv nélküli én régebben ilyet használtam:

class html_blokk{
	public $html_code;
	
	function load_template_file($fajlnev,$tomb) {
 
		if(file_exists($fajlnev)) {
			$temp = fopen($fajlnev,"r");
			$tartalom = fread($temp, filesize($fajlnev));
			fclose($temp);
			$tartalom = preg_replace("/{(.*?)}/si","{\$tomb[\\1]}",$tartalom);
			eval("\$tartalom = \"" . addslashes($tartalom) . "\";");
			$tartalom = str_replace("\'", "'", $tartalom);
			$this->html_code = $tartalom . "\n";
		}
 
	}
}


$content = 'Tartalom';

$title = 'Cím';


$array = array('content' => $content,
               'title' => $title);


$index_html = new html_blokk;
echo $index_html->load_template_file("template/index.html",$array);
Az index.html meg pl így néz ki:

<html>
<head>
	{head}
</head>
<body>	
	<h1>{title}</h1>
	<div>{content}</div>
</body>
</html>
Sablonnyelv nélkül pedig a ciklikusan megjelenő elemeket sajnos még php-val kell elkészíteni. Egy összetett oldalt pedig több sablonból raktam össze.
30

Miért éri ez meg neked? Nem

inf · 2013. Okt. 22. (K), 02.03
Miért éri ez meg neked?

Nem lenne egyszerűbb simpleXML-el, vagy csak simán szöveg összefűzéssel megcsinálni? Akkor nem kellene html tagek között bűvészkedni különböző sablon kódokkal...
32

Megéri?

mz82 · 2013. Okt. 22. (K), 08.10
Nem éreztem bonyolultnak a használatát. És szerintem meg is éri. Például mert a html állomány önállóan is megállja a helyét. Mert olyan is képes szerkeszteni a sablont aki csak statikus html kódot ért meg. Szerintem sok ilyen grafikus van. Extrém esetben akár wysiwyg szerkesztőben is megnyithatók a sablonok.
Olyankor is jól jött mikor 3-5 oldalas statikus oldalt kellett dinamikussá alakítani. Csak {} jelek közé tettem a dinamikus szakaszokat és készen is voltam.
Tudom, hogy ezeket <?php tag-ekkel oldják meg sokan, de én meg attól készülök ki! :-)
Én azt szeretem, ha a kész html kimenet az index.php utolsó sorában egy echo-val van egyben kitolva.
33

Tudom, hogy ezeket <?php

inf · 2013. Okt. 22. (K), 09.09
Tudom, hogy ezeket <?php tag-ekkel oldják meg sokan, de én meg attól készülök ki! :-)
Én azt szeretem, ha a kész html kimenet az index.php utolsó sorában egy echo-val van egyben kitolva.


A sablonnyelvek mind php sablonra fordulnak le, ezt lementik, és a tényleges feldolgozásnál ez fut le (különben baromi lassú lenne), szóval nem értem az összefüggést, hogy miért ne lehetne kézzel írt php sablont használni...
34

Természetesen igazad van!

mz82 · 2013. Okt. 22. (K), 09.21
Természetesen igazad van! Viszont a lefordított sablont nem nagyon szoktam nézegetni. :-)
Itt most csak arról beszélünk, hogy fejlesztés alatt kinek mi az átláthatóbb módszer. Én jelenleg a Smarty-val teljesen meg vagyok elégedve. Részemről átláthatóbb és gyorsabb így a munka.
35

Részemről átláthatóbb és

Hidvégi Gábor · 2013. Okt. 22. (K), 09.24
Részemről átláthatóbb és gyorsabb így a munka.
inf3rno: ezért írtam a másik témában, hogy strukturálás és a karbantarthatóság szubjektív valami.
37

kifejtenéd?

inf · 2013. Okt. 22. (K), 09.45
kifejtenéd?
38

Itt most csak arról

Hidvégi Gábor · 2013. Okt. 22. (K), 10.13
Itt most csak arról beszélünk, hogy fejlesztés alatt kinek mi az átláthatóbb módszer. Én jelenleg a Smarty-val teljesen meg vagyok elégedve. Részemről átláthatóbb és gyorsabb így a munka.
39

Az egyik programozási nyelven

inf · 2013. Okt. 22. (K), 10.33
Az egyik programozási nyelven írt kód lehet átláthatóbb, mint egy másik programozási nyelven írt kód. Nem hiszem, hogy szubjektív. Elhiszem, hogy egy smarty sablon átláthatóbb, mint egy php sablon, mert olyanok a jelölői, meg úgy színezi az IDE. Vannak szubjektív elemei a dolognak, ezt sosem vitattam, de ha a nagy átlagokat nézzük, akkor ezek kioltják egymást, és csak az objektív része marad a dolognak, nevezetesen, hogy olvashatóbb e az adott megoldás, vagy sem.

Amit te képtelen vagy megérteni, hogy a kódot nem magunknak írjuk, hanem az x évvel utánunk hozzányúló programozónak. Még az is lehet, hogy ez is te leszel, de már máshogy nézed a dolgokat, és szubjektíven más megoldás lesz átláthatóbb neked. Így az, hogy nekünk jelenleg szubjektíven átláthatóbb egy
x?0:y?1:2
mint egy
x?0:(y?1:2)
vagy egy

if (x)
    a = 0;
else if (y)
    a = 1;
else
    a =2;
semmit nem jelent. Az objektív részére kell koncentrálni, szóval arra, hogy az átlag programozónak mi az átláthatóbb, és az jelen esetben nem a short syntax-os megoldás lesz...

Ha egy kódról nem tudom első ránézésre megmondani, hogy mit csinál, akkor annak a kódnak rossz az olvashatósága. Azért kell széttördelni a kódot, hogy a függvény- vagy osztály nevekkel egy magasabb absztrakciós szinten 10 sorban le tudjuk írni, hogy mit csinál egy 1000 soros kód. Ha arra vagyunk kíváncsiak, hogy hogyan csinálja, akkor lemegyünk egy alacsonyabb absztrakciós szintre, és megnézzük az ottani kódot. Ha ömlesztve megadod az 1000 sor kódot, az csak annyit mond ránézésre, hogy hogyan csinálja, de azt nem, hogy mit csinál. Ahhoz át kell nézni és meg kell érteni az egészet. Ez egy csomó plusz idő és munka, amit senki nem fizet meg...
36

mindenkinek igaza van/senkinek sincs igaza

retnek · 2013. Okt. 22. (K), 09.37
Úgy gondolom, hogy bizonyos helyzetben kiváló választás a smarty (pl ha fejlesztés szempontjából a projektben külön van választva a front/back end vagy van több smarty-t alaposan ismerő fejlesztő a csapatban) és vannak olyan projektek, ahol jobb választásnak tűnik a PHP mint sablonnyelv használata (pl ha a projektben CakePHP-t használnak) stb.

Semelyik sem jobb és semelyik sem rosszabb általánosságban. Azt sem lehet eldönteni hogy melyik a legjobb autó és azt sem hogy ki a legszebb a világon :)