[Basti]

Hi.

Ich häng hier an einem Entwurfs-Problem und probier das mal zu schildern:

Es geht um das einbetten von Bildern in einem Content-Management-System. Um Bilder in einer Komponente einzubetten, wird das Bild-Objekt unter der Angabe einer Bild-Klasse an ein Widget (Image oder Thumbnail) übergeben. Eine Bild-Klasse ist dabei keine PHP-Klasse, sondern im Wesentlichen einfach eine Definition, wie hoch und wie breit das Bild maximal sein darf.

Um das Bild dann anzusprechen, wird ein Request mit der Angabe der Klasse an den Server geschickt. Dieser gibt das Bild entweder direkt aus (falls es im öffentlich zugänglichen Cache liegt) oder skaliert das Bild entsprechend runter und gibt es dann aus (und speichert es ggf. in den Cache).

Mein Problem ist nun, dass ich gewährleisten möchte, dass Bilder nur in den Klassen gecached bzw. angezeigt werden, in denen sie im Template angewiesen werden.

Konkret:
Ich hab ein öffentlich lesbares Bild "xzy.jpg", dass in einem Template als Bild der Klasse "header_image" ausgespuckt wird. Jetzt gibt es aber noch weitere Bild-Klassen, wie fullsize, news_thumb. Zusätzlich gibt es die Option, ein Bild mit der direkten Angabe der Maximal-Maße, also ohne Klasse auszuspucken.

Der Aufruf erfolgt dann über

example.com/image.display/header_image/xyz.jpg


Nun will ich verhindern, dass bei einem der folgenden Aufrufe das Bild entsprechend runterskaliert und angezeigt wird:

example.com/image.display/news_thumb/xyz.jpg
example.com/image.display/700x400/xyz.jpg
etc.

Das Problem ist, dass in den Views, genauer die Templates enschieden wird, in welche Klasser bzw. mit welchen Maximal-Maßen ein Bild ausgegeben werden soll, ich aber eigentlich nicht z.B. aus dem Widget heraus in die Datenbank schreiben möchte: Bild xyz.jpg wurde in der und der Klasse oder mit den und den Maximal-Maßen in der und der Komponente eingebunden.

Könnt ihr was damit anfangen, habt ihr schonmal ein ähnliches Problem gehabt und wie habt ihr es gelöst?

Widgets sollten nicht auf die Datenbank zugreifen, Views höchstens read-only, aber nur die Views/Widgets wissen, wie ein Bild dargestellt werden soll und muss diese Information eigentlich an das System/die Datenbank weitergeben.

Session (z.B. Challenge-IDs) ist kein Weg, da die Bilder fixe URIs brauchen, um extern verlinkt werden zu können.

Würdet ihr den Widget DB-Access geben oder vielleicht Observer einklinken?

Hoffe, dass sich da jemand eindenken kann und seine Anregungen oder Erfahrungen mit mir teilt.

Einen sonnigen Tag wünscht der
Basti

[Basti]

Ich sehe hier gerade keinen "bearbeiten"-Button, von daher noch ein klener Nachtrag:

Der Sinn und Zweck, diese Requests zu verhindern liegt natürlich darin, mir nicht die Platte zuzuballern:

PHP-Code:

<?php
for ($w = 1; $w<1000; $w++) {
    for ($h = 1; $w<1000; $h++) {
        fopen('http://example.com/image.display/' . $w . 'x' . $h . '/xyz.jpg');
    }
}

...würde mir das Bild 1.000.000 mal in verschiedenen Größen auf die Platte kopieren.

Basti

[Jann Hendrik]

Zitat von Basti

...würde mir das Bild 1.000.000 mal in verschiedenen Größen auf die Platte kopieren.

ich kann dir auf deine eigentliche Frage zwar nicht antworten, aber der Nachteil wenn der Browser das runterskalieren muss ist der, das man das den Grafiken oftmals ansieht!

Das ist jedenfalls mein Eindruck, darum würde ich dann eher dazu tendieren die Bilder mehrfach als echten thumb auf die Platte zu packen, was im übrigen auch den traffic veringert.

[Basti]

Das mach ich ja auch so. Eben darum gehts ja auch, sonst würde ich das Bild immer in Originalgröße ausspucken und es wäre kein Problem, dass die Templates hier entscheiden, wie groß das eingebunden wird. Aber klar, der Ansatz ist Käse und den kann (und will) ich nicht verkaufen.

Ich werde das jetzt irgendwie mit Observern lösen, die die Widgets beobachten und sich vielleicht bei der Widget-Factory anmelden. Ich denke, das wird sich auch gut machen, um Links zu beobachten und ggf. auch später ein differenzierendes Cacheing einzubauen.

Wie genau, weiß ich allerdings noch nicht - werds erstmal irgendwie zusammenschustern und dann sehen, wohin es sich entwickeln will.

Basti