Hallo zusammen, ich habe einige Templates angepasst, um abhängig von einem bestimmten Attribut eines Artikels weitere Attribute gezielt anzuzeigen oder zu verbergen, um die unterschiedlichen Eigenschaften strukturiert darzustellen. Nun stehe ich leider vor dem Problem, dass die 20 Attributs-Felder ab Werk nicht ausreichen. Einige Artikel haben ziemlich viele Eigenschaften (so ca. 30-35). Andere Artikel hingegen kämen mit den 20 ab Werk verfügbaren Attributen allemal aus. Auf Basis des Threads Hinzufügen eines 2. Beschreibungstextes für Produkt wollte ich meinen Artikeln ein paar Attribute mehr spendieren. Ich überlege nur gerade, was später mehr Performance bringt: Ich könnte jetzt einfach einen Haufen weiterer Attribute hinzufügen. Dann hätte ich die Daten im Template in {$sArticle.attr21}, {$sArticle.attr22}, etc. Die neuen Spalten in der DB-Tabelle würden dann aber auch bei den Artikeln geladen, die diese Felder gar nicht nutzen, richtig? Performant dürfte dies nicht sein. Eine andere Möglichkeit wäre, ein Feld mit großem Fassungsvermögen anzulegen (z.B. Datentyp “mediumtext”) und darin einen String zu speichern, der zu einem Array umgewandelt wird. Das Erzeugen des Arrays könnte ich von einem Event-Listener-Plugin erledigen lassen (z.B. bei “[color=green]Shopware_Modules_Articles_sGetArticlesByCategory_FilterLoopEnd[/color]” für das Listing). Dann hätte ich die Daten im Template im einfachsten Fall in {$sArticle.attr21.0}, {$sArticle.attr21.1}, etc. Möchte jemand eine Empfehlung abgeben, welches die performanteste Lösung ist? Oder hat jemand einen ganz anderen Ansatz?
Hi, ich würde dir zur Lösung 1 empfehlen. Gründe: - Ob im Frontend jetzt 20 oder 30 Attribute selektiert werden und plain in die View gereicht werden macht keinen großen unterschied. - Das Speichern von mehreren Werten in einem mediumtext, den du dann erst noch beim Speichern und Laden wieder konvertieren musst kostet hingegen schon eher Performance. Bei Artikeln die nur die ersten 20 Attribute verwenden werden natürlich auch die anderen neuen 20 Attribute ausgelesen. Doch das ist natürlich beim Mediumtext dann genauso. Mit freundlichen Grüßen Oliver Denter
Hi, dann werde ich mal den 1. Weg eingehen… Ich hab aber noch ein anderes Problem, nämlich mit dem Import: Ich habe zur Probe über die Install-Methode meines Plugins ein einzelndes Feld über das Model angelegt: $metaDataCache = Shopware()-\>Models()-\>getConfiguration()-\>getMetadataCacheImpl(); $metaDataCache-\>deleteAll(); Shopware()-\>Models()-\>addAttribute( 's\_articles\_attributes', 'my', 'AdditionalAttribute', 'mediumtext', true, null ); $metaDataCache = Shopware()-\>Models()-\>getConfiguration()-\>getMetadataCacheImpl(); $metaDataCache-\>deleteAll(); Shopware()-\>Models()-\>generateAttributeModels( array('s\_articles\_attributes') ); Beim Installieren wird brav ein neues Feld namens ‘my_AdditionalAttribute’ in der Tabelle s_articles_attributes angelegt. Dann hab ich einen Artikel-Export als XML durchgeführt. Ausgegeben wurde dabei ein neues Feld namens ‘myAdditionalattribute’. Beim XML-Import bekomme ich weder aus einem Knoten namens ‘myAdditionalattribute’ noch namens ‘my_AdditionalAttribute’ Daten in das neue DB-Feld. Woran liegt das? EDIT: Hab grad noch einen Fehler gefunden: Wie gesagt, steht im XML ja ‘myAdditionalattribute’, obwohl das erzeugte DB-Feld ‘my_AdditionalAttribute’ heißt. Ich hab gerade einen CSV-Export versucht. Fehlermeldung: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘at.myAdditionalattributes’ in ‘field list’ in Zend/Db/Statement/Pdo.php on line 234 Ist wohl ein Fall für den Bug-Tracker?