"Sauber" via Smarty an Attribut-Felder kommen (z.B. s_filter_options_attributes)

Shopware 5 Allgemein
1

Hallo Liebe Community,

ich hätte mal eine Art “Best-Practice-Frage” an euch.
Es geht um das Abrufen von Attributfeldern (in meinem Fall s_filter_options_attributes), das m.E. bisher noch keinem wirklichen Standard folgt.

Ich rufe aktuell das Feld wie folgt in der /frontend/detail/tabs/description.tpl ab:

{foreach $sArticle.sProperties as $sProperty}

  {assign var="section" value={$sProperty.attributes.core->get('section')} }
  {if $section == 'FOO'}
    MACH WAS
  {/if}

{/foreach}

Jetzt zum eigentlichen Problem:
Es gibt ja durchaus nicht wenig Fälle, wo dieses Feld gar nicht gesetzt ist. In diesem Fall rennt der Getter in einen üblen Fehler, der auch das weitere Rendering unterbricht.
Entsprechend kann ich dieses Feld auch nicht auf “empty”/“isset”/“is_null” prüfen, da der pure Getter-Aufruf ja schon einen Fehler auslöst. Von Try/Catch-Strukturen in Smarty wüsste ich jetzt auch nichts, aber unabhängig davon:
Es muss doch einen sauberen Weg geben hier an die Attributfelder ranzukommen, ohne 100 Zeilen Exception-Handling!?

Für Vorschläge wäre ich sehr dankbar :slight_smile:

Liebe Grüße
B. Quarta

2

Der Fehler wird dann eher geworfen, weil du ->get auf einen null-Pointer aufrufst. Daher musst du prüfen, ob .core überhaupt existiert:

{if $sProperty.attributes.core}
  {assign var="section" value={$sProperty.attributes.core->get('section')}}
{else}
  {assign var="section" value=""}
{/if}

Noch schöner wäre es natürlich, wenn du das bereits im PHP-Code machst. Zum Beispiel im LegacyStructConverter. Da gibt es entsprechende Events.

Viele Grüße

3

Hi simkli,

ja, du hast recht. Der Fehler kommt durch einen call auf einen Null-Pointer und deine Lösung würde auch zunächst so funktionieren.
Danke erst mal für die rasche Antwort :slight_smile:

Und ja, im PHP-Code vorher die Daten abzurufen wäre in der Tat sauberer. In dem speziellen Fall ging es lediglich darum diverse Eigenschaften gruppieren zu können und ich habe nach einer “schlanken” Lösung gesucht, ohne hier im Template extra einen Event abzugreifen etc etc.
Ich stimme dir aber zu, dass generell programmatische Angelegenheiten im Template-Engine-Bereich nichts verloren haben.

Ich persönlich fände es konsequenter, wenn Shopware überall da, wo es auch Attribut-Tabellen gibt (wie bei sArticle z.B.) auch die Attribute (selbst wenn es keine gibt) gleich mitgeliefert würden, sodass man im Template einfach via $sProperty.attributes.attributeXY etwas abrufen könnte (und ggf. “NULL” zurückbekommt).
Begründung: Angenommen man benötigt sehr viele verschiedene Attributfelder in verschiedenen Tabellen, müsste man eine Theme.php entweder unnötig aufblähen, weil man für alles Events subscriben muss (das kann ja nach wie vor “möglich” sein, aber es sollte eine Art default-verhalten geben), oder man braucht für solche Dinge ständig Plugins (dann brauche ich aber auch keine standardmäßig leeren Attribut-Tabellen, sondern kann sie ja auch selbst erstellen… von mir aus auch mit Naming-Conventions für Kompatibilitätsfragen).

Das Konzept an sich find ich gut, aber es ist imho einfach etwas inkohärent ^^

Danke jedenfalls für den Denk-Anstoß. Hat mir geholfen :slight_smile:

Liebe Grüße