Sprachvariablen in smarty

03/16/2013 13:46 Phillor#1
Hallo Leute!

Ich bin nun seit einigen Wochen an einem Projekt dran, das ich mit smarty aufgebaut habe.
Nun würde ich gerne Sprachvariablen verwenden, da ich die Seite später evtl. mehrsprachig machen möchte.
Ich habe also mithilfe von google gesucht und bin auf folgende smarty Klasse gestoßen:
[Only registered and activated users can see links. Click Here To Register...]

Ich habe also eine PHP Datei erstellt, die Klasse dort reingepackt, die smarty klasse eingebunden und diese MultiLingual Klasse in meine index.php eingebunden.

allerdings erscheint nun folgender Fehler:

Ich habe es nun 2 mal versucht, doch es scheint nicht zu funktionieren.
Ich verwende smarty 3.1.12. Ich hoffe mir kann da jemand weiterhelfen :O

Gruß,
Phillor
03/16/2013 17:01 Hiris#2
Würde dir stark von Smarty abraten, ist überfüllter scheis, google einfach mal nach smarty pro/contra dann sollte dir das schnell auffallen^^
03/16/2013 17:58 Phillor#3
komisch, mir wurde von vielen smarty empfohlen...
03/16/2013 18:08 Mikesch01#4
Wie sieht denn dein Code in der Datei aus, wo du das alles verwendest?
03/16/2013 18:17 Phillor#5
wie meinstn du das? Ich habe einfach den Code von der oben verlinkten Seite genommen, die Klasse in der index.php aufgerufen und der Fehler, den ich oben angegeben habe erscheint!
03/16/2013 18:32 Hiris#6
[Only registered and activated users can see links. Click Here To Register...]
03/16/2013 19:39 Phillor#7
Vielen Dank für den Hinweis :D
03/16/2013 20:16 Hiris#8
np^^
03/16/2013 20:30 Synatex#9
Quote:
komisch, mir wurde von vielen smarty empfohlen...
Kommt wahrscheinlich daher das es sich durchaus für größere Projekte früher gelohnt hat und einige noch dran anhalten. Diese setzen heute jedoch auf MVC in Verbindung mit OOP. Für kleinere Projekte kann man auch getrost ohne TPL-Engine arbeiten, da es sich meist einfach nicht lohnt ;)

Siehe beispielsweise Wordpress. Ist eigentlich mit die bekannteste Software im Web und die setzt auf keine.
03/16/2013 20:39 Hiris#10
Quote:
Originally Posted by Synatex View Post
Kommt wahrscheinlich daher das es sich durchaus für größere Projekte früher gelohnt hat und einige noch dran anhalten. Diese setzen heute jedoch auf MVC in Verbindung mit OOP. Für kleinere Projekte kann man auch getrost ohne TPL-Engine arbeiten, da es sich meist einfach nicht lohnt ;)

Siehe beispielsweise Wordpress. Ist eigentlich mit die bekannteste Software im Web und die setzt auf keine.
Manche vertreten auch die Meinung das Tpl-Engine´s generell absoluter Bullshit sind weil PhP selber ein Template System ist aber das ist geschmackssache^^
03/16/2013 21:26 dowhile#11
Quote:
Originally Posted by Hiris View Post
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...] (Artikel PRO Template-Engines)


Quote:
Originally Posted by Synatex View Post
Kommt wahrscheinlich daher das es sich durchaus für größere Projekte früher gelohnt hat und einige noch dran anhalten. Diese setzen heute jedoch auf MVC in Verbindung mit OOP. Für kleinere Projekte kann man auch getrost ohne TPL-Engine arbeiten, da es sich meist einfach nicht lohnt ;)
Wieso soll das MVC Pattern den Einsatz einer Template-Engine ausschließen? oO
03/16/2013 23:19 Synatex#12
Weil man im MVC so oder so im View nur seinen Output hat. Dazu ne TPL Engine nutzen wäre doch recht Sinnfrei wenn man seinen Code schon soweit trennt, dass man die Logik schon ausgelagert hab. Ob man dann <?=$var;?> oder {$var} schreibt macht dann ja auch keinen unterschied mehr.
03/16/2013 23:43 dowhile#13
Quote:
Originally Posted by Synatex View Post
Weil man im MVC so oder so im View nur seinen Output hat. Dazu ne TPL Engine nutzen wäre doch recht Sinnfrei wenn man seinen Code schon soweit trennt, dass man die Logik schon ausgelagert hab. Ob man dann <?=$var;?> oder {$var} schreibt macht dann ja auch keinen unterschied mehr.
Eine Template-Engine kümmert sich nur um die Darstellung ... Ist das nicht die Aufgabe der Präsentationsschicht?

Ich weiß nicht, wie genau Smarty funktioniert, aber bei Twig macht das IMHO schon einen Unterschied.

Quote:
<?=htmlentities($var);?> gegen {{ var }}
Quote:
<?=if(count($entries) > 0):?>
<?=foreach($entries as $entry):?>
<?=htmlentities($entry);?>
<?=endforeach;?> (gibt es das? :D)
<?=else:?>
Keine Einträge.
<?=endif;?>

gegen

{% for entry in entries %}
{{ entry }}
{% else %}
Keine Einträge.
{% endfor %}
Quote:
<?=($answer) ? print('yes') : print('no');?> gegen {{ answer ? 'yes' : 'no' }}
(Ich habe keine Ahnung von den alternativen Schreibweisen von PHP)

Ich finde die Syntax von Twig definitiv schöner und einfacher. Zudem gibt es noch Funktionen wie das Inkludieren anderer Templates, Wiederverwendung (mit Überschreibung) von Blöcken in einem Template, ...
Mit dem MVC Pattern ist das alles, denke ich, trotzdem noch gut vereinbar. Das sind schließlich alles Funktionen, die nur die Darstellung der Daten steuern.
03/16/2013 23:52 Mikesch01#14
Da ist ja reines PHP schöner als Twig! :D

Den Quelltext würde ich nicht lesen wollen. Smarty hat aber dennoch wegen der Flexibilität einen Vorteil. Ich habs auch verwendet und finde es sehr angenehm.
03/16/2013 23:56 Synatex#15
Die ganzen IF-Bedingungen und die Escape-Funktionen gehören nicht in nen View ;) Die werden im Controller vollzogen und dementsprechend zurückgegeben. Wenn du das von oben in PHP machen willst, dann kann man das doch ohne Probleme in normalen PHP schreiben, wofür unnötige Engines die einem noch einmal eine neue Syntax andrehen wollen?

PHP Code:
foreach($entries as $entry) {
  echo 
$entry;
} else {
 echo 
'Keine einträge';

Dieses Beispiel kann keine TPL Engine der Welt schlagen ;) (ja ich habs so nachgebaut wie es oben steht, ich weiß nicht wo seine IF-Abfrage geblieben ist!)

Wenn schon die Logik darein verlagert wird - die im Grunde gar nichts darin zutun hat - dann wäre es doch schlau sich wenigstens an eine Art Standard zu halten damit auch externe, weitere Programmierer das verstehen.

Aber ich verstehe den Sinn noch immer nicht. Der nutzen in den Template Enginen liegt doch darin, Logik und Ausgabe zu trennen und trotzdem nutzen es genau alle zu dem Zweck.. S: