Da ist noch etwas.
Wenn man bei HTML::Temlate zu viel param(...) übergab, dann beschwerte sich HTML::Template darüber, weil es nicht wußte, wo es die Parameter hinschieben sollte. Das ist jetzt nicht mehr drin. Eigentlich fehlte mir da schon die andere Richtung, daß zu viel <TMPL_VAR ...> auch nicht angemeckert wurde. Wenn das Template also etwas größer wird, wie halte ich Ordnung?

huch.
das findest du ein feature?
oder verstehe ich dich nicht richtig?

was willst du genau?

Es kann ein Feature sein (wenn man es während der Entwicklung einschalten und im Produktivsystem ausschalten kann).

genau @renee so etwas wie <TMPL= _ ESCAPE=DEBUG> auch

du meinst die_on_bad_params ? oder so
ist nicht drin, wird auch nie drin sein!
siehe dazu die POD

Also wenn es sich nur für Testphasen handelt... könnte ich für H:T
folgendes vorschlagen:



Aber für H:T:C wüßte ich da nichts. Hier geht auch wohl eher um H:T:C
als um H:T.\n\n

<!--EDIT|opi|1167408900-->

[quote=esskar,29.12.2006, 16:53]du meinst die_on_bad_params ? oder so
ist nicht drin, wird auch nie drin sein!
siehe dazu die POD[/quote]
Ich hab's in der POD gerade gelesen.
Schade eigentlich, weil so ein wesentliches Hilfsmittel zur Fehlersuche fehlt, so etwas wie "strict" eben.

ich find die_on_bad_params sinnlos. denn mehr parameter uebergeben
als benutzt werden war fuer mich noch nie eine fehlerquelle.
umgekehrt - also im template auf einen undefinierten (oder nicht-exististierenden)
key zugreifen, koennte ich theoretisch abfangen.
ein einfaches abfragen auf undef koennte ich vielleicht sehr einfach mit
warnings.pm realisieren (z.zt. ist jedes template-kompilat mit
no warnings 'uninitialized' kompiliert). auf exists testen waere etwas
aufwaendiger.

ist auf der TODO-liste.\n\n

<!--EDIT|pq|1167410839-->

Daß ein undef genau so behandelt wird wie q{} ist ok. Das erwartet man im Allgemeinem von einem Template, daß es damit umgehen kann.

Wenn man mit param(...) weniger vorgibt, als man verwendet, dann ist das ein Fehler, der z.B. dann entsteht, wenn man ein Template neu aufsetzt. Anders herum passiert es, wenn man ein vorhandenes Template anpaßt. Das zusätzliche Parametrisieren ist zwar nicht wirklich ein Problem, jedoch leidet die Performance. Beides zusammen entsteht, wenn man sich verschreibt.

Ich weiß zwar nicht, wie Dein Template genau funktoniert. Der Einfachste Fall ist, wenn Parameter in einem Hash gehalten werden, daß man diesem eine Art Tie::StrictHash verpaßt und schon könnte man falsche keys erkennen/registrieren. Das Ein- und Ausschalten (tie oder nicht tie) ist einfach und abgeschaltet ist das Programm so, wie es immer war. Der andere Fall ist das Zählen der Zugriffe am Ende und das Filtern der mit 0 gezählten. Das würde ich auch auch mit in den tie reinpacken.

Um so etwas zu implementieren, würde ich mein Template (wenn ich eins geschrieben hätte) nicht so abwandeln, daß es im nicht-strict Modus Performanceverluste hätte. Denn sonst würde ich (steffenw) am Ende sagen: Das habe ich nicht gewollt.

Das mal so als Gedanken dazu.\n\n

<!--EDIT|steffenw|1167422384-->