2009-05-19T17:08:23 pq

2009-05-19T16:34:21 sid burn

Klar hat es auch noch eine eigene TT angelehnte Syntax. Was ich aber auch nicht gerade positiv finde das es zwei Arten unterstützt.

es unterstützt keine zwei syntaxen, sondern nur zwei stile, also wie die begrenzer der template-anweisungen aussehen. keine ahnung, wie du da zwei syntaxen herausliest...

Und anstatt <TMPL_VAR asd> kann man auch. <%= asd %> etc. nutzen das ist in meinen Augen schon eine andere syntax. Ein HT Nutzer kann mit deinen ganzen speziel Tags erstmal nichts anfangen.

Ansonsten wo ich gerade über deine Doku schaue. War es bei dir nicht auch Möglich das man einfach ein Array übergibt und jeden Wert durchlaufen kann in HTC, ohne das man das Array vorher in AoH umwandeln muss?

Quote

es kann methodenaufrufe, und man kann eigene escaping-plugins schreiben. es gibt sicher situationen, in denen man eine einschränkung hat,

Zu dem Thema haben wir ja den anderen Pfad.

Quote

aber die hat man bei jedem templating mehr oder weniger, dann muss man schon perl selbst benutzen. auch TT kann sicher nicht alles, was perl kann. nur weil HTC eingeschränkter als TT ist, ist es für dich was komplett anderes?

Beides sind Templating System, aber klar sind beide etwas anderes. Wenn es nicht was anderes wäre warum gibt es dann HT, HTC, TT, Petal und noch zig andere Templating Systeme?

Quote

man kann gerne behaupten, HTC sei unnötig, da es ja schon TT gibt. aber nur weil man im template weniger funktionen zur verfügung hat, ist es trotzdem noch ein template-system und damit trennung von html (o.ä.) und logik.

Das es unnötig ist habe ich nicht behauptet. Hat man bereits HT und möchte es erweitern mag es noch ein gutes Drop-In Replacement sein.

Ansonsten ist die Aufgabe eines Templating Systems nicht logik von nicht logik zu Trennen, und auch nicht die Aufgabe von MVC.

Sie sind dafür da unterschiedliche Logiken voneinander zu trennen. Im View kommt die Logik zum Anzeigen, und auch nur dort. Und nicht im Controller oder im Model. Der View könnte genauso Perl sein, wenn man dort eben nur Anzeigelogik verbaut.

Die Trennung ist dafür da das du jedes System für sich anpassen/ändern kannst. Keine Logik hättest du nur ausschließlich dann wenn du eine Statische Seite auslieferst. Sobald du aber schleifen durchlaufen kannst, Werte vergleichen kannst etc. steckt da auch Logik dahinter.

Ein Templating System muss über genug Logik verfügen um Daten aufzubereiten. Wie es sie aufbereitet, ob nun HTML, XML, JSON oder wie es die Daten darstellt ist dann komplett die Logik des Views.

Je nachdem wie stark das Templating System aber eingegrenzt ist, ist man letztendlich dazu gezwungen immer mehr anstatt im View woanders zu machen. Bei HT ist das extrem. Durch die ganzen Idiotischen Datenstrukturen die man im vorfeld aufbauen muss steckt schon ein erheblicher Teil des Aufbaus für den View im Controller/Model wo es nicht hingehört.

Was ist wenn man die Daten ganz anders darstellen möchte, zum Beispiel hat man mehrere Templates zur auswahl? Dann müssen die Datenstrukturen im Code entsprechend darauf angepasst werden.

Der Funktionsumfang eines Templating systems hat also schon damit zu tun wie gut es seine aufgabe erfüllt.

Quote

meiner ansicht nach verleitet HTC weniger dazu, zuviel logik im template unterzubringen.

Wenn du Logik die zum anzeigen benötigst auch im Template nutzt ist das volkommen okay, dafür ist es ja da. Wenn ein Templating System dich aber begrenzt Anzeigelogik woanders einzubauen dann erfüllt es seinen Zweck meiner Ansicht nach nicht.

Ob das mit HTC nun volkommen umgesetzt werden kann weiß ich nicht. Da ich noch davon ausging das dein HTC keine Funktionsparameter kann, wäre das ein Grund gewesen zu sagen das es die aufgabe nicht einwandfrei erfüllt.

Bei HT weiß ich aber das es die Aufgabe so gut wie überhaupt nicht erfüllt. TT erfüllt diese aufgabe ziemlich gut.

Quote

H::T finde ich aber wegen der notwendigen Datenstrukturen nicht gut, man muss sich in der Logik sehr verrenken, um verwertbare Strukturen fürs Template herzustellen, und es fördert global_vars, deshalb denken auch einige, die auf HTC umsteigen, erstmal viel zu kompliziert.

An "global_vars" sehe ich auch nichts schlimmes. Wenn ich in Perl zwei for Schleifen geschachtelt habe, dann ist es nur natürlich das ich in der innersten for schleife auch auf variablen auf den übergeordneten Scope darauf zugreifen kann.

Eigentlich ist "global_vars" auch keine gute bezeichnung für die Funktionalität die man dafür bekommt.

Zu den Datenstrukturen habe ich ja oben etwas geschrieben, ich denke da stimmen wir überein. :)