Jak w temacie, gdzie powinno sie wedlug Was odbywac skalowanie, usuwanie uploadowanie obrazkow. Moj pomysl to - upload w kontrolerze, na podstawie kazdego upnietego pliku tworzony jest obiekt z danymi tego pliku i przekazywany do modelu, ktory skaluje, zapisuje minuatury na dysku i dodaje info do bazy. Troche nie podoba mi sie fakt ze i kontroler i model wie o sciezkach do katalogow z uploadem (oczywiscie sciezki zapisane w Registry/Config) z drugiej strony skalowanie i zapis powinien byc w modelu na wypadek jakbym na przyklad chcial obrazki z bazie zapisywac ( ).
Dodatkowo usuwanie obrazkow - lepiej wywolac jedna metode modelu deleteAll() niz w kazdym kontrolerze powtarzac ten sam kod kasowania.
Nie wiem natomiast czy sam proces uploadowania powinien brac na siebie kontroler czy moze powinien przekazywac dane z formularza do modelu ... ale znowu model nie powinien wiedziec nic a zadnych formularzach, powinien tylko dostawac czyste dane czyli sciezki do plikow ktore ma zeskalowac i zapisac.
Co Wy na to ?

Ja mam osobne narzedzia do uploadu plikow, osobne to modyfikacji obrazkow, osobne to zarzadzania tym na dysku. Jak dla mnie to nie powinno sie to odbywac w kontrolerze. Kontroler w tym wypadku powinien jedynie korzystac z interfejsow jakie daja klasy modelu. No ale jak to niejednokrotnie juz padlo kazdy MVC implementuje/interpretuje po swojemu i uwazam ze nie ma tu jakis scislych regul. Zrob jak uwazasz bedzie dla Ciebie wygodniej i elastyczniej.

Wszystko w modelu. Kontroler powinien przekazać do modelu obiekt pliku (konkretniej - przesłanego), a ten powinien wiedzieć co z nim zrobić. Ważne, żeby nie porozsypywać tego po różnych klasach, bo się zrobi chaos. Możesz uploadowane pliki reprezentować przez klasę implementującą prosty interfejs:

[PHP] pobierz, plaintext 
<?php
interface UploadedFile {
	// Zapisuje plik (czyli po prostu go przenosi...).
	function saveAs($sPath);
}
?>
[PHP] pobierz, plaintext 

który spokojnie możesz wykorzystać w modelu

[PHP] pobierz, plaintext 
<?php
class ImageUploadModel {
	public function saveImage(UploadedFile $img) {
		$img->saveAs(Config::get('image.path'));
		// Generuje miniaturkę i zapisuje ją.
		$this->generateThumbnail($img, Config::get('image.thumbnail_path'));
	}
}
?>
[PHP] pobierz, plaintext 

Dalej możesz dopisywać metody odpowiadające za resztę działań na uploadowanych plikach. Możesz wydzielić tworzenie miniaturek i wykorzystać do tego obiekt Image zwracany przez metodę saveImage(). Tak jak napisał thornag - ilu ludzi, tyle implementacji.

Czyli zbieram pliki w kontrolerze, tworze sobie obiekty UploadedFile i daje je do modelu zanim jeszcze zrobie move_uploaded_file()? W sumie dobry pomysl, bede musial troche przeprojektowac klase do uploadowania i zapisu plikow na serwerze

Tak jest. Tylko wszystkie szczegóły uploadu zamykasz w tej klasie. Poza nią nie ma istnieć żadne odwołanie do move_uploaded_file itp. Interfejs ma ukryć szczegóły implementacji, dzięki czemu będziesz mógł dodawać w ten sam sposób pliki z różnych źródeł - nawet importować z jakiegoś FTP...

U mnie plik jest przekazywany do modelu, ale potem są przekazywane z kontrolera czy ma coś jeszcze robić.
Dlatego może być tylko upload'owany plik, jak i tworzyć 20 miniaturek parametryzowanych z modelu przy dodawaniu "metody do obróbki".
Te "metody do obróbki" wiedzą co robią wiec przy dodawaniu np. tworzą miniatury, a przy kasowaniu je usuwają. Czyli te "metody do obróbki" nie wiedzą skąd jest plik tylko jego ścieżkę i wiedzą tylko o swojej działce. Główna część zajmuje się sprawdzeniem pliku i po udanym upload'dzie uruchamia dodane "metody do obróbki"

Co daje dość rozszerzalną rzecz, łatwo dodać coś nowego bo albo dopisuje się nową "metody do obróbki" lub tylko w kontrolerze dorzuca ją do modelu, że ma być używana. Model wie co ma w niej odpalić przy tworzeniu i przy kasowaniu.

Dość ciężko się pisze i analizuje jak to dokładnie działa, ale potem w użyciu jest banalne.

Czyli samo zajmowanie się plikiem jest po stronie modelu (po części rozproszonego) a kontroler mówi które mają być modele użyte... więc chyba może być

A jak wyswietlic komunikat trwa wysylanie pliku?? a jak sie zakonczy to ze zakonczono:) Lub uzyc jakiegos progress bar??

w Kontrolerze a nie w Modelu.

Model to warstwa posredniczaca miedzy Kontrolerem a Baza Danych.

Wezmy na przyklad takie rozwiazanie :

W zaleznosci od danych przeslanych do Kontrolera z Widoku, uploadujesz plik, dynamicznie wczytujesz odpowiedni Model ( to wlasnie wybor Modelu w tym przypadku zalezy od danych dostarczonych Kontrolerowi )i go uaktualniasz.

Pakujac upload do Modelu musisz zduplikowac metode odpowiedzialna za upload, jezeli bedziesz chail uzyc 20 modeli ta sama metode powielisz 20 razy.

Oczywiscie mozna na stale wrzucic do jednego modelu upload, a reszte tylko wczytywac ... tylko po cholere ladowac nie zawsze potrzebny Model ?

Ludvik - to w zlym tonie pisac na tematy o ktorych sie nie ma pojecia.

Czyli w przypadku, gdy zechcesz trzymać obrazki w bazie danych, to możesz tę warstwę pominąć? Poza tym, zawsze myślałem, że model jest odwzorowaniem danych i funkcjonalności pewnej części systemu. Kontroler może zażądać aktualizacji modelu, a to czy dodajesz newsa, czy obrazek, za bardzo mnie w tym momencie nie interesuje...


Ale po co mi upload obrazków w 20 modelach? Wystarczy mi jeden osobny model, który zajmie się obsługą uploadu i tyle... Nie widzę tu potrzeby powielania żadnego kodu...


Rozumiem, że wyróżniłeś najważniejszą część swojego posta? Osobiste wycieczki - PW, jeżeli jest to dla Ciebie wielkim problemem. Na razie tylko Tobie się to nie podoba, więc to chyba wszyscy, którzy tu pisali (i nie są to anonimowe osoby, które zarejestrowały się tydzień temu na forum) są w błędzie według Ciebie...

smieszny temat, tak jakby istnial tylko model i kontroler

plik ( np obrazek ) nie jest danymi - to sposob przechowywania danych, podarzajac Twoim tropem modele powinny zajac sie obsluga plikow XML, tablic ( to tez sposob na przechowywania danych), sesji ( tak jak poprzednio ) i generalnie wszytskiego , lacznie z manipulacja tablicami, sesjami itp. Sam sobie odpowiedz czy to wlasciwy sposb interpretacji zastosowania Modelu.




Zastanawiam sie teraz po co w wiekszosci frameworkow modele standardowo sa powiazana z tabelami BD ( w niektorych nie sposob stworzyc Model ktroy nie bedzie korzystac z zadnej tabeli ) , i zwykle maja zdefiniowane rozne relacje miedzy soba...



Akurat skopiowalem nicka gdzies z Twojego posta, jako ze byl pogrubiony to i reszta textu zostala pogrubiona, wiec wybacz ale nie bylo to celowe dzialanie.

Idac dalej Twoim tropem , banda dresiarzy bez karkow rozwalajaca czyjs samochod na osiedlu w bialy dzien robi wszytsko jak najlepiej, bo nikt im nie zwroci uwagi ? Troche oderwany od tematu przyklad, ale obrazujacu sensownosc Twoich argumentow.

@kuba77
Model najczęściej korzysta z bazy danych, ze ktoś ogranicza model tylko do bazy danych to już jego problem.
Model wie skąd pobrać dane i zwrócić w unormowanej postaci. Właśnie model ma nas izolować od tego, czy korzystamy z DB czy z XML czy też pobieramy z innej strony.
To co korzysta z modelu nie obchodzi skąd on bierze dane, ale to model powinien wiedzieć skąd pobrać i zapisać dane.

Mam takie cos:

[HTML] pobierz, plaintext 
<input type="submit" name="upload" onclick="sexyBOX('YourURL','300'); return false;" value="Wyslij">
[HTML] pobierz, plaintext 

sexyBOX('YourURL','300') - powoduje ze wyskauje takie graficzne okienko...tam chcialem dac "trwa wysylanie pliku" ... ale wtedy skrypt sie nie odpala do wysylania plikow :/... tzn wogole nic nie leci z formularza ...return false... szczal w leb ;)Mozna zrobic tak ze jak zamkne okno w javie to zeby rpzestal sie odpalac skrypt w php.. np jakie sprzkeirowanie co kolwiek