Jump to content
php.lv forumi

Smarty


Mr.Key

Recommended Posts

Nezinu īsti, vai Smarty pieder pie freimworkiem un CMSiem.. protams, ka nepieder, jo tā ir veidņu dzinēja bibliotēka.

 

Kādu laiku nebiju sekojis līdzi, tagad skatos, ka nu jau rit darbs pie 3 versijas, kuru, domājams, tad arī lietošu. Līdzīgi kā Zend Framework, tā darbojas tikai ar PHP5 versiju, ir jaunumi sintakses ziņā, kas ir daudz .. atceroties to, kā 2. versijā nācās atstrādāt elementāras lietas. Man liekas diezgan iespaidīgi: http://smarty-php.googlecode.com/svn/branches/Smarty3Dev/distribution/README

 

Vai kādam jau ir pieredze, darbinot 3. versiju? Bugi, ātrdarbība, savietojamība, jaunās superduperfīčas un tā?

 

p.s. Lai nesāktos fleims par to, kāpēc jāizmanto Smarty, izmantošu tāpēc, ka templeiti glabāsies CMSā un tos rediģēs dizaineri/Hā-Tē-eM-eL-isti. Ir daudz vienkāršāk dizainerim iedot smarty manual, nekā mācīt php..

Edited by Mr.Key
Link to comment
Share on other sites

Nepadalīšos gan ar pieredzi, bet pasūdzēšos sakot, ka neredzu jēgu tādai templeitu valodai :) Manuprāt, ir vienlīdz ekvivalenti lietot šādu lietu (šis ir improvizēts piemērs, jo es nezinu Smarty sintaksi - kā piemēru ņēmu Liquid (viena no Rails templeišu valodām) sintaksi)

 

{% for category in categories %}
 Kategorija: {{ category->name }}<br />
{% endfor %}

 

un šādu

 

<?php foreach($categories as $category) { ?>
 Kategorija: <?php echo $category->name ?><br />
<?php } ?>

 

Ir vienlīdz viegli apgūt kā vienu - tā otru (ja skatās no dizaineru viedokļa).

 

Ja Smarty piedāvā arī ko tādu, ko parasti piedāvā vienkārši Framework'i, tad vēl ir OK, bet ja nē, tad nu paldies, bet neredzu tam vispār nekādu jēgu. + ja mainās sintakse pa versijām, tad vispār trakums...

 

Vienīgā templeišu valodas izmantošana, kuru redzu, ir, lai veidotu kaut kādas semi-static lapas ar nelielu dinamisku saturu un lai parasts lietotājs varētu pamainīt šīs lapas uzvedību nedaudz. Ar šo var nedaudz samazināt kaut kādus drošības coķus...

Edited by rATRIJS
Link to comment
Share on other sites

Ir backwards compatibility ar v2.

 

Kā es skatos uz Smarty:

* Sintakse, kuru var izmantot HTML redaktorā, saprotama plašākai publikai, dokumentēta speciāli templeitu kontekstā. Piemēram, to var iedot klientam, kurš pēc iepazīšanās ar to var pats veikt vienkāršas izmaiņas lapā.

* Nodalīts templeita "scope", t.i., darbības apgabals. Darbs ar templeitiem var tikt veikts atsevišķi, no darba organizācijas viedokļa. No tehniskā viedokļa, iespēje kontrolēt, ko var un ko nevar darīt templeitos. Ne vienmēr var uzticēties tam, kurš strādās ar templeitiem, piemēram, ja templeitus maina lietotājs caur CMS sadaļu, nedrīkst atļaut tīšas vai netīšas kļūdas. Varbūt viss, ko projektā var atļaut, ir daži sintakses elementi. PHP gadījumā kā nokontrolēsi, vai templeiti saveidoti pareizi - pārbaudīsi katru? Un ja tā ir sistēma ar 1000 lietājiem?

* Plugini ļauj papildināt bāzes funkcionalitāti ar sistēmai vai CMSam specifiskām iespējām. Piemēram, CMSā var veidot rakstu ar HTML redaktoru, un raksta vidū ielikt {gallery name='lielie_nemieri_saeima'}, kas automātiski iemetīs tajā vietā dajebkādu projektam atbilstošu galerijas kodu. Un HTML editoru var papildināt ar pluginu, kas atpazīst šādu tagu un piedāvā to pievienot/rediģēt. Protams, var jau arī taisīt <?php echo $this->gallery(' ... ?>, bet nu... tas nav tīri..

* utt.

 

Tas vairāk ir jautājums par koda struktūru, kārtību. Un arī jautājums par darba organizāciju. Tas var nebūt būtiski, raugoties no 1 personas skatu punkta un/vai nelieliem projektiem. Taču, veidojot produktu vai palielāku sistēmu, tādi jautājumi jau kļūst būtiski, un parasti risinājums ir templeiti ar savu sintaksi.

 

Tāds mans praktiskais skaidrojums, droši ka ir teorija, kurā viss skaidri un gaiši pamatots.

Edited by Mr.Key
Link to comment
Share on other sites

Atveram http://www.smartyjobs.net/ - vesels 1 darbs "Smarty programmētājam"! Apsveicu!

Skatoties pārējos saitus, kurus pirmajā lapā izmeta Google, ir skaidrs, ka tos Smarty pārsvarā pieprasa (ja vispār kāds pieprasa) tikai kā papildus zināšanas paralēli php, mysql, css, xhtml un tādā garā...

 

Kā es skatos uz Smarty:

* Sintakse, kuru var izmantot HTML redaktorā, saprotama plašākai publikai, dokumentēta speciāli templeitu kontekstā. Piemēram, to var iedot klientam, kurš pēc iepazīšanās ar to var pats veikt vienkāršas izmaiņas lapā.

Un kāda atšķirība vai iedosi klientam glītus "views", kur ir strikti ievēroti MVC principi ar php kodu iekšā, vai arī "Smarty templeitu"?

 

* Nodalīts templeita "scope", t.i., darbības apgabals. Darbs ar templeitiem var tikt veikts atsevišķi, no darba organizācijas viedokļa. No tehniskā viedokļa, iespēje kontrolēt, ko var un ko nevar darīt templeitos. Ne vienmēr var uzticēties tam, kurš strādās ar templeitiem, piemēram, ja templeitus maina lietotājs caur CMS sadaļu, nedrīkst atļaut tīšas vai netīšas kļūdas. Varbūt viss, ko projektā var atļaut, ir daži sintakses elementi. PHP gadījumā kā nokontrolēsi, vai templeiti saveidoti pareizi - pārbaudīsi katru? Un ja tā ir sistēma ar 1000 lietājiem?

Ar to smarty viņš arī var sataisīt "muļķības" tāpat kā ar php, bet ja viņš ir tāds, kas taisīs "injekcijas" aplikācijai iekš "views", tad viņš ir kaitnieks vai nejēga un ir jāpārskata sadarbība ar viņu.

 

* Plugini ļauj papildināt bāzes funkcionalitāti ar sistēmai vai CMSam specifiskām iespējām. Piemēram, CMSā var veidot rakstu ar HTML redaktoru, un raksta vidū ielikt {gallery name='lielie_nemieri_saeima'}, kas automātiski iemetīs tajā vietā dajebkādu projektam atbilstošu galerijas kodu. Un HTML editoru var papildināt ar pluginu, kas atpazīst šādu tagu un piedāvā to pievienot/rediģēt. Protams, var jau arī taisīt <?php echo $this->gallery(' ... ?>, bet nu... tas nav tīri..

Nav skaidrs, kāpēc CMSa admin pusē būtu jāliek kaut kādas "Smarty" vai "views" labošanas lietas? Pat ja to vajag, tur vienmēr būs ierobežotas iespējas un noteikumi, ko tur darīt (vismaz tā vajadzētu būt) un tāpat nāksies taisīt specifisku "parseri" šādām iespējām. Administrācijas puse jeb "back-end" pats par sevi ir ar ierobežotām iespējām, lai nesačakarētu aplikāciju un pēc tam programmētājiem nāktos labot klienta kļūdas uz klienta vai pašu programmētāju rēķina - nevienam tas nav īsti ērti veiksmīgai sadarbībai, tāpēc, vislabāk piedāvā klientam veikt izmaiņas ar ierobežotām iespējām, lai samazinātu kļūdu varbūtību.

 

Tāds mans praktiskais skaidrojums, droši ka ir teorija, kurā viss skaidri un gaiši pamatots.

Par to sistēmu - tas ir pats par sevi, ka lietotāja interfeisa daļai vajadzētu būt atdalītai no loģikas, tā ir arī MVC būtība. Par teoriju - nebūšu es gluži LU pasniedzējs, gan jau kāds aktīvs briļļainis paskaidros teoriju labāk! ;)

Link to comment
Share on other sites

  • 3 months later...

Arguments "klients pats var pielabot templeitus" nekad nav izturējis kritiku. Klienti, kas ir spējīgi pielabot templeitus ir 0.001% no visiem un tāpēc izdomāt maģiskas templeitu valodas, manuprāt, ir mēreni pastulbi.

 

Vienīgais saprātīgais arguments par labu šīm templeitu valodām ir tas, ka nelietojot PHP tagus templeitus var labot WYSIWYG editoros, taču nezinu cik daudz vispār ir tādu gadījumu, kad kāds to darītu.

Link to comment
Share on other sites

Arguments "klients pats var pielabot templeitus" nekad nav izturējis kritiku.

gadījumā tai filozofijai arguments nebija "lai dizaineri paši varētu pielabot templeitus"?

bet nu tas, imho, arī īpaši neiztur kritiku, jo tik kruts dizaineris, kas var pielabot templeitu ar kkādu templeitu valodu, varēs pielabot arī templeitu ar php

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...