Artikel mit mehreren Bildattributen oder eine eigene Klasse?

Donnerstag, 03. August 2006 09:35:16

Hi Fabian,

> Die Grossansicht, plus 3-4 Kleinansichten.

Ist das alles das gleiche Bild? Die Größe der Bilder ist für eZ publish irrelevant, da das System Bilder auf verschiedene Größen skaliert (einstellbar in der Konfiguration).

> Variante 1
> Pro moegliches Bild in der Klasse Produkt ein Attribut.
> Ist sicher am unflexibelsten, sollte aber doch beim auslesen am schnellsten
> sein, wenn nur 1 Objekt geladen werden muss.

eZ publish speichert Objekte generisch, das heißt es gibt eine Objekt-Tabelle, die Infos zum Objekt allgemein enthält und eine Tabelle für die Attribute. Das heißt, ein Objekt hat für jedes Attribute einen Eintrag in der Attribute-Tabelle. Ich gehe jetzt mal davon aus, dass eZ publish intern zwei Möglichkeiten hat: entweder alle Attribute auf einmal zu laden oder nur die Attribute, die benötigt werden. Somit resultiert ein Content-Objekt mit mehreren Attributen evtl. von sich aus bereits in mehrere zu ladende Attribute-Objekte. Aber wie gesagt, ich weiß nicht, wie der Datenbankzugriff geregelt ist.

> Variante 2
> Produkt Klasse beinhaltet kein Attribut pro Bild, dafuer gibt es eine 2.
> Klasse die Produktbild heisst mit 1 Attribut fuer das Bild.
> Wenn also fuer ein Produkt 4 Bilder vorhanden sind, dann gibt es 4 Objekte
> mit der Klasse Produktbild die dem Objekt Produkt zugewiesen werden.
> Hier muss einfach pro Produktobjekt immer noch x-Objekte geladen werden.

Ich würde vermutlich diese Variante bevorzugen. Die Bilder können dann als Child-Objekte erzeugt werden oder als related objects - je nach eigenen Vorlieben.

Über das Laden würde ich mir grundsätzlich weniger Gedanken machen, da eZ publish die Seite cached und somit dieses Laden nicht so häufig vorkommen sollte. (Du kannst unter Umständen sogar so weit gehen, dass eZ publish alle oder einzelne Seiten statisch erzeugt, die dann der Webserver direkt ausliefert - ohne PHP-Processing ist das unschlagbar schnell.) Außerdem vermute ich, dass im Falle eines Neuladens die Template-Verarbeitung mehr Zeit in Anspruch nimmt als der Datenbankzugriff.

Außerdem: welche Zugriffszahlen erwartest du denn? Wenn du in Bereiche kommst, wo das wirklich relevant wird, dann sollte das Geschäftsmodell vermutlich auch Geld für einen zweiten Webserver und/oder eigenen Datenbankserver abwerfen (Bisher hört sich das ganze jedenfalls nicht nach einer extrem personalisierten Webseite an...)

> Variante 3
> Eine zusaetzliche Produktbild Klasse mit n Attributen fuer Bilder. n ist so
> gross zu waehlen wie maximal Bilder zu erwarten sind.
> Dadurch wird beim anzeigen eines Produktes maximal 2 Objekte geladen.

Hört sich nicht so elegant an.

> Ist das laden von mehreren Objekten in ezPublish so ressourcenfressend oder
> kann man dies vernachlaessigen? Mit "laden" meine ich sie im Browser fuer
> den Endbenutzer darzustellen.

Siehe meinen Kommentar oben. Nun ja, das Darstellen im Browser ist dann wohl eher von der Internet-Anbindung bei dir und beim User abhängig...

Einen schönen Tag

Thomas

Donnerstag, 03. August 2006 19:26:16

> Ich gehe mal davon aus, dass mit dem Related objects das entsprechende Attribute in der Klasse meinst, oder? Dann
> mache ich wohl eine Produkte Klasse die mehrere Objekte von der Klasse Produktebild beinhalten kann.

Nein, ich meinte folgendes: Du kannst im Admin-Interface, wenn du ein Objekt bearbeitest, am Ende der Seite verwandte Objekte hinzufügen. Dies können sowohl bereits existierende Objekte sein als auch neu hochzuladende Bilder. Im Online-Editor werden diese Bilder auch angezeigt, wenn du ein Objekt hinzufügen willst. Intern werden diese Relationen gleich behandelt wie wenn die in einem Attribut definiert werden. Die verwandten Objekte werden im Admin-Interface dann - ähnlich den Child-Objekten - unter dem aktuellen Objekt angezeigt.

Wenn du dir eines der verwandten Objekte ansiehst, dann siehst du auch, zu welchen Objekten es verwandt ist (Stichwort: reverse related).

Viele Grüße

Thomas