[SF][Symfony3] Strategia na tworzenie i zapis miniaturek do zdjęć Opcje

[CodeRider]

Cześć!

Mam encję Article, która ma id, title i image. Tworzę formularz, dodaję walidację i wszystko ok.

Ale co w sytuacji, gdy potrzebuję dodatkowo 3 miniaturki z uploadowanego zdjęcia, które muszę przyciąć, uploadować i zapisać do nich ścieżkę w bazie danych?

Czy wtedy powinienem dopisać nową encję zdjęcia, która będzie miała swoją tabelę w bazie danych, dodatkową klasę do przycinania obrazka i będzie wstrzyknięta do Article (encja zdjęcia oczywiście)?
Czy może jest jakieś proste rozwiązanie, aby wszystko to trzymać w encji Artykułu?

Ten post edytował CodeRider 19.06.2017, 19:11:04

[damianooo]

Nie jestem pewien bo nie robiłem czegoś podobnego wcześniej ale wydaje mi się że skoro o zdjęciu będzie więcej informacji to raczej osobna encja będzie potrzebna ... z czasem na pewno będziesz potrzebował takie pola jak createdAt i updatedAt , więc już się robi tego więcej ... poza tym rozumiem że Artykuł może mieć więcej zdjęć więc chyba logicznym wydaje się zrobienie dodatkowej encji ..
Wolałbym jednak aby wypowiedział się ktoś kto podobne rzeczy robił

[Pilsener]

Podejścia są trzy:
- tylko oryginalny plik jako encja w DB
- jak wyżej, ale do encji dodane dodatkowe informacje
- każdy plik jako encja w DB

Najsensowniej wydaje się 2. Po uploadzie masz standardowe encje file, gdzie dodajesz pola typu pathSmall, pathXSmall etc. Akcję tworzącą miniaturki odpalasz w CRONie, akcja wyszukuje encje bez miniaturek, tworzy je i zapisuje w bazie.

Przykładowa encja file z jednego z projektów symfony:

`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`mime` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`extension` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
`path` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`deleted_at` datetime DEFAULT NULL,

Gdzie path to unikalna, wygenerowana nazwa pliku pod którą jest on zapisywany na dysku. Wystarczy dodać path_small i przed pobraniem miniaturki sprawdzać, czy pole nie jest null (jak jest null można wstawić zaślępkę typu "trwa przetwarzanie zdjęcia" czy coś w tym stylu)

[Pyton_000]

Ja bym zapisywał każdą fotkę (+ te dodatkowe) jako osobna encja powiązana z Articles. Dodatkowo możesz do zdjęć dodaktowych dodać powiązanie z rodzicem w Encji Photo.
Jakby nie patrzeć to zmienione zdjęcia to już są nowe zdjęcia

Oczywiście fotki zapisywane na dysku a nie w BD. To tak ku jasności

Ten post edytował Pyton_000 20.06.2017, 07:48:43

[nospor]

Ja skolei nie kumam, po co w ogole chcecie zapisywac info o miniaturkach w bazie. Masz w bazie glowna fotke i wystarczy. Miniaturki sa po to, by w roznych formatach wyswietlac dana fotke. Na liscie jeden format, w arcie inny, gdzies na stronie glownej jeszcze inny. Po co do tego info w bazie? Do niczego. Miniaturke generujesz w razie potrzeb i w kazdej chwili mozesz sobie dynamicznie zmieniac. A jesli masz naprawde duzy ruch to mozesz generowac od razu dany zestaw miniatur dla danej fotki i juz.

[Puszy]

Z łopatologicznych rozwiązań jest też opcja robienia miniaturek w locie np. przy użyciu Imagine, choć wydajnościowo może się to nie opłacać. Możesz też podczas uploadu tworzyć miniaturki, zapisywać je do folderów "small", "large" etc. Pliki zawsze będą miały tę samą nazwę, więc w encji przechowujesz tylko jedną nazwę a jedynie przy wyświetlaniu korzystasz z niezależnych ścieżek, w przypadku braku zdjęcia (np. dodanie nowego rozmiaru) zawsze możesz użyć HTMLowego atrybutu onerror, sprawdzić czy plik istnieje i wyświetlić inny, lub napisać joba który będzie pobierał z configu wymiary nowego rozmiaru i tworzył nowe miniatury na podstawie oryginalnego pliku, dzięki temu po kilku minutach po dodaniu nowego rozmiaru masz nowe miniaturki.

[CodeRider]

mozesz generowac od razu dany zestaw miniatur dla danej fotki i juz.

No tak, od razu mam dane dla całego zestawu i tworzę miniatury. Ale w zależności od strony, mają one inne nazwy.

Rozumiem, że jeśli nie zapisuję ścieżki do każdej miniaturki to robię to tak, że w klasie encji Image mam np. 4 ścieżki na stałe + 4 metody, które zwracają mi path do image?

Np.

[PHP] pobierz, plaintext 
private $originalPath = __DIR__.'/images';
private $thumbXSmallPath = __DIR__.'/images/XSmall';
 
public function getOriginalImagePath(){
 return $originalPath . $name . $ext;
}
public function getThumbXSmall(){
 return $thumbXSmallPath. $name . $ext;
}
[PHP] pobierz, plaintext 

i posługuję się tylko nazwą i rozszerzeniem zdjęcia? (w bazie danych)

Ten post edytował CodeRider 20.06.2017, 09:49:04

[nospor]

Tak

[Pilsener]

po co w ogole chcecie zapisywac info o miniaturkach w bazie

1. Żeby wiedzieć, czy miniaturki już się wygenerowały (są już dostępne) - zazwyczaj dodaje się wiele zdjęć, nieraz bardzo dużych i ich obróbka "w locie" jest niemożliwa, z kolei przy wyświetlaniu nie trzeba używać "file_exists"
2. Czasami, żeby zapisywać dodatkowe informacje związane z miniaturkami (jeśli są potrzebne, np. znaki wodne, tagi, nagłówki, tekst w "alt", tryb wygenerowania...)
3. Żeby było prościej a co za tym idzie:
- żeby uniezależnić przechowywanie pliku na dysku od jego typu, funkcji, przeznaczenia etc. Preferuję system, w którym plik nazywa się np. 1a2B i jest zawsze w jednym folderze, cała reszta w bazie lub cfg - tak jest prościej
- żeby łatwiej napisać funkcje/routingi pobierające plik, np. file/1a2B zadziała niezależnie od typu pliku a inaczej musimy kombinować file/xsmall/1a2B, file/orygin/1a2B itd.
- dużo łatwiej zmienić coś w bazie/cfg niż majstrować przy folderach czy ścieżkach. Widać to zwłaszcza, gdy trzeba robić migrację jakiś funkcjonalności czy całych systemów.
- żeby łatwiej debugować
- itd.

Taką mam opinię po pracy z wieloma różnymi systemami.

[Pyton_000]

No i dodatkowo mieć informację jaki pliki mamy a nie potem się zastanawiać jakie pliki wywalić jak będzie ich 5000000000000