ich kann HTC in diesem fall nicht so programmieren wie HT, denn ich erlaube
ja auch methodenaufrufe. ich weiss also allein aus dem template nicht, wie
der parameterhash aussehen muss.
umgekehrt geht eine strict-option auch nicht zur compile-zeit, da ich erst
nach dem param()-aufruf weiss, welche parameter übergeben wurden.
das ginge also dann nur zur laufzeit.
ich würde bei der strict-option dann eben zusätzlich auf exists prüfen.
das macht es langsamer, aber wenn es nur in der entwicklungsphase
benutzt wird, macht das ja nichts.
man muss halt immer bedenken, dass es ein ganz anderer ansatz als HT
ist. das template wird einmalig in eine perl-subroutine verwandelt, und
die parameter werden in einem hash abgelegt. die_on_bad_params
ist so nicht nur schwierig zu implementieren, sondern unmöglich. einzig
in HTC::Classic wäre es möglich (weil es keine methoden kann), aber
ich weiss nicht, ob mir dafür der aufwand zu gross ist, wenn ich
selbst immer noch keinen sinn darin sehe.

ich bin dagegen, denn weihnachten ist schon vorbei, und ich glaube, HTC kann immer noch keine Expressions. Ich lass mich jetzt aber auch gerne enthaupten, wenn es es doch schon kann.

:)

ich hab nicht gesagt, welches weihnachten es sein wird =)

So wie ich das sehe, sind Methoden doch auch nur Variablen mit speziellen Eigenschaften, denen dann beim Aufruf die jeweilige Methode (Eigenschaft) angehangen wird. Oder irre ich da? Im POD sehe ich keine Parmeter für die Methoden und auch kein Beispiel in der Art object.foo.bar.baz alias $object->foo()->bar()->baz(). Ist das evtl. nur nicht dokumentiert?

Ach @esskar, Weihnachten oder nicht. Mir ist das eigentlich völlig egal. Die Diskussion hier mit @pq ist doch vom Niveau recht gut. Und wenn sie gedanklich durch das eine oder andere angeregt wird, ist das doch nicht zu kritisieren. Keiner erwartet doch, daß hier sofort etwas implementiert wird. Ich auch nicht. Als Modulautor, und das ist eindeutig @pq, will man doch das Optimum erreichen, wie das auch immer aussieht. Da muß man Prioritäten setzen und dazu gehört auch das eine oder andere nein. Wenn Ruhe eingezogen ist und wieder Zeit ist, kann man Entscheidungen aber auch immer wieder neu überdenken.\n\n

<!--EDIT|steffenw|1167469323-->

achso, ich dachte man könnte hier abstimmen! ;)

Also so etwas wie die_on_bad_params sollte nie ein default-Wert sein. Zum Entwickeln ist es sicherlich häufig recht sinnvoll. Aber ich zum Beispiel baue bei der Webseite für die Perl-Zeitschrift darauf, dass HTC das einfach so schluckt. Da kann man einige Parameter bei TMPL_IFs einfach unterschlagen (wenn es ungesetzt sein soll).

Aber @renee, die parameter übermittelst du schon mit param, nur ist da undef drin, weil sie ggf. nie befüllt worden sind oder?

bad parameters - die definition ist doch in sich schon schwamm oder?\n\n

<!--EDIT|steffenw|1167472455-->

Nee, ich übermittel die *gar nicht*

Ich verwende die meisten Templates für mindestens zwei Fälle.

Beispiel:

Und im Skript dann (mit CGI::Application):

Beide Fälle benutzen zwar das gleiche Template, machen aber so unterschiedliche Sachen, dass ich es nicht in eine Sub zusammenfassen wollte.

So übergebe ich bei der einen Sub keinen Parameter für MESSAGE, weil da _nie_ der Fall eintritt wo ich MESSAGE brauchen würde.

So spare ich mir eine umständliche Sub (durch Aufteilung in zwei!) und ich muss kein zweites Template machen!

Ja stimmt @renee, das Erzwingen von parametern würde das Template einschränken.

[quote=steffenw,30.12.2006, 10:01]So wie ich das sehe, sind Methoden doch auch nur Variablen mit speziellen Eigenschaften, denen dann beim Aufruf die jeweilige Methode (Eigenschaft) angehangen wird. Oder irre ich da? Im POD sehe ich keine Parmeter für die Methoden und auch kein Beispiel in der Art object.foo.bar.baz alias $object->foo()->bar()->baz(). Ist das evtl. nur nicht dokumentiert?[/quote]
hmm?
http://search.cpan.org/~tinita....OBJECTS

entscheidend ist, <tmpl_var foo.bar.baz> kann zu $param->{foo}->bar()->{baz} werden
oder zu $param->foo()->{bar}->baz(), je nachdem, was in den skalaren
drinsteckt, objekte oder hashes.