Erweiterung von L

[Niclas]

In vielen templates taucht Code mit [% IF %]-Abfragen auf, die prüfen, ob ein HTML-Tag als "readonly" angezeigt werden soll oder nicht. Statt diesen ganzen Abfragen könnte man doch besser das Modul SL/Template/L.pm um zwei Funktionen erweitern:

1. readonly: Wenn die Option readonly als true mitgegeben wird, wird der HTML-Code nur als readonly angezeigt. Also als ganz normaler Info-Text, keine select-Tags, keine input-Tags

2. hidden: Genauso, wie bei readonly, nur dass der Variablen-Wert als hidden weitergeliefert wird.

Diese beiden Optionen würden an vielen Stellen den HTML-Code in den templates verkleinern, und somit viel lesbarer gestalten.

Siehe auch Ticket #1836.

Nicht als state in L bitte. Das ist action at a distance und kann einem ganz böse auf die Füße fallen.

Wenn überhaupt dann als lexikalischen Scope für subtemplates, das würde das sauber kapselbar machen.

Das ist nicht ganz trivial:

1. Wenn ein Input-Tag (egal welcher Natur) auf readonly gesetzt wird, so schickt der Browser den Inhalt des Inputs beim POSTen nicht mit. Darauf muss der Controller in dem Moment ausgelegt sein und statt dessen je nach Bedarfsfall den Inhalt des Inputs eben doch noch zusätzlich als hidden mitschleifen. An anderen Stellen reicht es aber vollkommen aus, wenn der Inhalt des Inputs im folgenden Request eben nicht zur Verfügung steht.
2. Oft genug ist die Entscheidung eben nicht, ob nur das Input angezeigt wird oder nicht, sondern auch gleich ob eine ganze Tabellenzelle/-zeile dafür angezeigt werden muss. Hier hilft ein eigenes Attribut dafür nicht.

Weiterhin: aus den möglichen Funktionsparametern im select_tag() den tatsächlich zu benutzenden Wert für den Hidden herauszusuchen, ist alles andere als trivial, weil das default-Attribut eben nicht nur einfache Werte annehmen kann, sondern auch RDBO-Objekte, aus denen ein Attribut als Wert genommen wird. Oder aber bei Multi-Selects: hier kann's eine Array-Ref sein mit den Inhalten davon.

Sprich: der Aufwand, das richtig zu implementieren, ist die Ersparnis im Template nicht wert. Daher bitte nicht machen. Danke.

Ich schließe das Ticket auch wieder.

Hallo,

ich hätte dann mal ein konkretes Beispiel: wenn ich eine alte Dialogbuchung aufmache, d.h. sie ist nicht mehr editierbar, angenommen ich möchte die bebuchten Konten nicht als generelles Dropdown mit ausgewähltem Konto, sondern als Dropdown mit nur diesem einen Eintrag (also nicht mehr änderbar) darstellen. Oder vielleicht einfach nur als Textfeld, wie das Bernd bei den nicht änderbaren Zahlungsaus- und Eingängen bei EK- und VK-Rechnungen gemacht hat, wo aus dem Dropdown mit auswähltem Zahlungskonto ein hidden und Textstring wird, je nach Wert von $changeable:

     [% IF $changeable %]
       <select name="AR_paid_[% i %]">[% $selectAR_paid_ref %]</select>
     [% ELSE %]
       <input type="hidden" name="AR_paid_[% i %]" value="[% $AR_paid %]">[% $AR_paid %]
     [% END %]

Sollte man also lieber immer im Template per if/else abfragen?

Bei dem Beispiel der alten Dialogbuchung bräuchte man glaube ich nicht mal das hidden, drucken kann man nicht, und das Storno wird anhand der Datenbankwerte durchgeführt, nicht anhand der Werte in form.

Das Grundproblem ist ein anderes: show und edit in einer Maske vereinen. Bau eine separate show action, die Sachen nur anzeigt, ohne irgendwelche Inputfelder. Schon ist alles gut.

Aber die show Action gibt es doch eigentlich schon mit [% variable %]. Außerdem bräuchte man ja dann immernoch die IF-ELSE-Abfragen im template.

Die Idee wäre viel mehr gewesen so etwas schreiben zu können:

[% L.select_tag(..., read_only=$changeable) %]

oder

[% L.select_tag(..., hidden=$changeable %] (wenn eine hidden Variable erstellt werden soll).

anstatt den 5 Zeilen Code, die Geoffery gepostet hat. Aber das wurde ja von Moritz abgelehnt...

Ja, es wurde und wird weiterhin von mir abgelehnt, weil der Aufwand, solche Attribute für all unsere möglichen Tag-Funktionen und, vor allem, alle möglichen Eingabemöglichkeiten an die Tag-Funktionen UND dann noch an die möglichen Szenarien, welche Daten Controller mit jedem Request brauchen und welche nicht, schlicht viel zu hoch ist. Es ist unglaublich viel Arbeit, solch ein Attribut richtig funktionierend für alle Szenarien hinzubekommen. Und es nur "einfach so" zu implementieren im Sinne von "gut genug für 90%" verführt dazu, dass man das Feature auch nutzt und sich dann einen Wolf debuggt und riesig viel Zeit zum Fixen investiert, wenn man einen der 10%-Fälle erwischt hat.

Der Aufwand für die Umsetzung und das spätere Fixen ist ungleich, ungleich viel höher, als der Aufwand, den du beim Tippen der Masken einsparen würdest.

Das verhält sich ähnlich wie bei den Umstellungen zu Themen wie Währungen (echte Verknüpfung via foreign keys zu currency anstatt einfach nur den Währungsnamen), oder aber die tax_id-Geschichte. Da haben nicht nur du, sondern auch Sven und ich Stunde um Stunde reinstecken müssen, um sie richtig hinzuziehen. Der große Unterschied ist, dass diese Umstellungen einen deutlich größeren Nutzen nach sich zogen: einfachere Auswertbarkeit der Daten hinterher, Vermeidung von Buchungsfehlern aufgrund Checks direkt in der Datenbank, Datenkonsistenz auch über die Zeit hinweg.

Der Nutzen von einem solchen Attribut ist hingegen minimal.

Daher habe ich das abgelehnt. Bitte nicht umsetzen.