Fallback placeholder für we:img

[blickfang]

Um im Template ein we:ifNotEmpty zu sparen, könnte das we:img tag um ein Attribut "placeholder" erweitert werden. Ist vom Redakteur kein Bild gepflegt, wird das placeholder-Bild ausgegeben.

gleiches sollte dann für we:picture gelten

Code: Alles auswählen

<we:ifNotEditmode>
<we:ifNotEmpty name="meinBild" type="image">
<we:img name="meinBild" />
<we:else />
<we:img name="meinBild" id="1 showimage="true" />
</we:ifNotEmpty>
</we:ifNotEditmode>

abkürzen mit:

Code: Alles auswählen

<we:ifNotEditmode>
<we:img name="meinBild" placeholder="5" />
</we:ifNotEditmode>

https://qa.webedition.org/view.php?id=13815#c53696

[ThomasGoebe]

Statt "placeholder" würde ich dann lieber "default" nehmen.
Aber noch schöner wäre ein

Code: Alles auswählen

<we:img id="5" name="meinBild" />

D.h. es wird solange das Bild mit der ID 5 ausgeliefert, bis ein eigenes eingestellt wurde. Ich meine sogar, dass das Verhalten jetzt schon so ist.

[blickfang]

wenn das das Standardverhalten sein sollte, bei gesetzt id und nicht gewählten Bild durch den Redakteur, dann erübrigt sich der FR. Bzw. dann war das in der Version zu der Zeit als der FR aufkam, nicht das Standardverhalten oder ein Bug

[LOOK//one]

Könnte das einer von Euch mal testen?

[blickfang]

Verhalten in der aktuellen 9er:

Wenn id gesetzt und kein Bild vom Redakteur gewählt wird, dann wird im NotEditmode das Bild mit der id ausgegeben.

Einzig was man hier noch diskutieren könnte, ob man das dann im Editmode auch so haben möchte, dass das Bild mit der id angezeigt wird oder hier lieber ein leeres Feld sehen möchte. Das ginge im aktuellen Verhalten so dann nicht, da auch im Editmode das Bild mit der id angezeigt wird.

[lukasimhof]

Tatsächlich entspricht der Default mittels "id" nicht wirklich dem dynamischen Ersatzwert aus Timos Template-Schnipsel, der immer dann ausgegeben wird, wenn der Redakteur nichts ausgewählt hat... vielmehr funktioniert es analog zu den Feld-Defaults auf Objekten:

Wenn das Dokument im Editmode geöffnet wird und in der DB für das Image noch nichts eingetragen ist (weil neu oder nicht gesetzt), dann wird hier im Editmode das Bild aus "id" vorausgewählt. Nach dem Speichern steht der Wert aus "id" in der DB (tblContent) und das Feld ist folglich nicht mehr leer => ein auf dem Template geänderter Wert für "id" wird nicht mehr beachtet (aber natürlich ein geändertes Bild unter der betreffenden ID). Wenn ich nun den Eintrag für das Image aus tblContent lösche, ist das Bild im Frontend leer und im Editmode erscheint wieder das Bild aus "id"...

Dies ist das übliche Verthalten in WE und wird v.a. im Zusammenhang mit "alt" und "title" immer wieder diskutiert, wo ebenfalls die Werte vom we:img-Tag hart gespeichert werden, auch wenn ich unverändert diejenigen aus dem Image-Dok übernommen habe. Bei diesen Attributen stellt sich jedoch die Frage, ob man volldynamisch nur noch auf die Attribute vom Image-Dok zugreifen und gar nichts mehr auf dem verwendenden Dokument in die DB speichern soll: alte Frage, Einigkeit gab es darüber noch nie...

Das schöne an WE ist ja aber, dass man sich quasi jedes gewünschte Verhalten punktgenau mit den Templates hinbauen kann...
=> denn die Variante aus dem obigen Beispielkode mit ifNotEmpty und einem fest im Template vorgegebenen Ersatzbild liefert z.B. genau die geschilderte volldynamische Lösung: ich weiß von daher nicht, ob ich hier Bedarf für ein neues Attribut sehe.

Wenn es nun quasi mit "id" sowas wie einen statischen Editmode- und mit "default" einen dynamischen Frontend-Default geben sollte, muss das auf jeden Fall jemand sehr sauber dokumentieren, damit der Unterschied überhaupt fassbar wird

[blickfang]

@Lukas: hatte es nur im Editmode getestet, daher das von dir beschriebene Verhalten so gar nicht bemerkt. Ist aber eigentlich dann schon nicht ganz richtig die id zu speichern, wenn der Redakteur nichts angegeben/ausgewählt hat. Eine Anzeige aller Bilder für die noch kein Bild gewählt wurde, wäre somit z.B. auch nicht mehr möglich.

[lukasimhof]

@Timo: dass man das infrage stellen kann, habe ich geschrieben. Aber es ist das normale Verhalten praktisch aller Default-Werte auf Tags und Feldern: diese werden beim Ausspielen in den Editmode bzw. die Bearbeiten-Ansicht der Objekte als Feldwerte gesetzt, wenn nichts aus der DB kommt; beim Speichern kommen sie dann eben als solche in die DB.

Es gab im einzelnen immer wieder die Frage, ob man dieses Verhalten nicht auf den Zustand nach dem ersten Speichern beschränke sollte. Das führt aber bereits beim Reload des Editmode/Objekt-Feldes zu Problemen, wie man auch auf dem we:img sehen kann: das Löschen des voreingstellten Bildes klappt gar nicht, weil es beim anschließenden Reload gleich wieder gesetzt wird.

Man müsste das Thema deshalb weiter fassen und generell überlegen, wie diese Defaults funktionieren sollen:
- so wie bisher
- gesetzt nur vor dem ersten Speichern oder evt. vor dem ersten Reload, danach aber löschbar
- "volldyamisches" Setzen des Defaults, wenn für das Feld nichts in der DB steht (wie könnte es dabei aber löschbar bleiben...?)

Letzteres müsste sicher optional sein und es erfordert auch deutlich mehr Kode im geparsten Template (bzw. in den von den Tags benutzten Funktionen), denn die Information zu solch einem Default sowie die zugrundeliegende Mechanik muss ja beim Ausspielen der Seite vorhaden sein: das kommt mir auf Anhieb zwar unkompliziert vor, da kann ich mich aber auch täuschen, solange ich das nicht konkret im Kode gecheckt habe.

Vielleicht wäre ja tatsächlich eine Kombination des alten "statischen" (evt. aber optimierten) Defaults mit einem neuen "dynamischen" der Königsweg, beide atürlich optional. Für die dynamische Variate sollte dann ein neues, für alle betroffenen Tags/Felder einheitliches Attribut gefunden werden.