[addon multiplefileupload] MultipleFileUpload – form control

pri vytvarani komponenty vies nastavit max. pocet suborov, kt. mfu spracuje, ale mal by si rovnako obmedzit ich pocet aj v JS, inak to bude velke WTF :-)

<?php
$form->addMultipleFileUpload('file_upload', 'Testík', 1); // 1 subor
?>

Caute, viete mi poradit aky mozem mat problem ked mi vracia komponenta:

Call to undefined method Nette\Application\UI\Form::addMultipleFileUpload().

proste mi ju nezaregistruje, uz fakt neviem preco, pritom mam v bootstrap:

MultipleFileUpload::register();

verzia addonu: Verze z 27. 8 2011 od Kashpi pro Nette 2.x pro PHP 5.3
nette: 2.1-dev

Editoval duskohu (18. 12. 2012 16:44)

Tak som skusil tu upravenu verziu: https://github.com/Ciki/MFU ale stale nic, proste v bootstrap ked zaregistrujem pomocou:

MultipleFileUpload::register();

tak to urobi, lebo nevrati ziadnu chybu, ale ked to pouzijem uz na:

$form = new Form;
$form->addMultipleFileUpload("upload","Balíček souborů");

tak mi da:

Call to undefined method Nette\Application\UI\Form::addMultipleFileUpload()

proste sa to nezaregistruje. Nakopiroval som:

1. z WWW_DIR/modules/multipleFileUpload >> do mojho WWW_DIR a dalsie potrebne js, css
2. app/components/MultipleFileUpload >> do mojho components
3. do head som dal : {!=MultipleFileUpload::getHead()}
4. do bootstrap >> MultipleFileUpload::register();

Urobil som nieco zle?

MultipleFileUpload::getUIRegistrator();
Mam hned za $container->addService('router', $router);

ked som ho dal pred tak mi vratilo:
Service 'router' has already been registered.

nalinkovane subory mam tiez, aj keby nie tak je to jedno na tych teraz nezalezi, kedze mi vracia ze nevie najst metodu v Form, takze ju ani nezaregistruje, co je divne ze pri registracii mi neda ani error, takze ako by ju zaregistrovalo, ale nieje tam.

Call to undefined method Nette\Application\UI\Form::addMultipleFileUpload().

a ide ti to aj na nette nette: 2.1-dev?, pouzivam nove tovarnicky cez create a inject, a stable 2.0 to nepodporuje.

Tak som ti to rozbehal aj na 2.1dev .. staci tato mala uprava https://github.com/…d9e44be3964a

caute viete mi poradit, ako nastavim validaciu na prvok? Lebo nastavenie mime type mi nefunguje.

$form->addMultipleFileUpload("upload2", "Druhý balíček souborů")
        ->addRule(MultipleFileUpload::validateMimeType, 'Povolene je len zip', '
            application/x-zip,
            application/zip,
            application/x-zip-compressed,
            application/octet-stream');

vrati mi to:

Undefined class constant 'validateMimeType'

Preco by to nefungovalo? Tak ako validovat tuto komponentu?

Editoval duskohu (29. 12. 2012 12:09)

Vsimol som si ze ked chcem uploadnut zip subor tak mi vypise alert Invalid file type. a v html kode mam: accept=„image/jpeg,image/gif,image/png“, ako viem toto zmenit? lebo som hladal a nic som nenasiel, ziadnu konfiguraciu. Popripade aj velkost max file size pre 1 subor? Vie mi niekto poradit? pls.

<input
id="p17fu3q4vk1u05vi21jr1s478s30_html5"
style="font-size: 999px; position: absolute; width: 100%; height: 100%;"
type="file"
accept="image/jpeg,image/gif,image/png"
multiple="multiple">

Editoval duskohu (2. 1. 2013 18:49)

Pouzivate niekto https://componette.org/search/?… miesto netteForms.js?

Strávil jsem pár dní s vrtáním se v MFU, konkrétně jeho verzí pro nette 2.0.x z GITu. Narazil jsem na pár bugů:

1. SQLite3 není u mě funkční (PHP 5.3.21), při ukládání se Sqlite3::escapeString(serialize($file)) spolehlivě ořízne na znaku \x00, řešení je stejné jako u tohoto problému .
2. Co mi dalo zabrat byl problém nefunkčnosti v Google Chrome (verze 24.0.1312.57). V podstatě nefunguje vše, co používá flash, já se snažil rozběhnout uploadify. FF bězí, Opera běží. Problém byl zde:

<?php
class MFUUIUploadify extends MFUUIBase {
	public function isThisYourUpload() {
		return (
			\Nette\Environment::getHttpRequest()->getHeader('user-agent') === 'Shockwave Flash'
			AND isSet($_POST["sender"])
			AND $_POST["sender"] == "MFU-Uploadify"
		);
	}
...
}
?>

Chrome neposílá user-agent ‚Shockwave Flash‘, ale klasický (Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17), protože má flash integrovaný přímo.

Jinak moc děkuju všem co jsem na tomto pluginu podíleli, usnadní to ostatním spoustu práce.

Editoval dada-amater (1. 3. 2013 14:26)

Oznamuji, že doplněk je nově dostupný na githubu. SVN repozitář je zatím pořád funkční, vyvíjet se však bude v GITu.

Těším se na pull requesty, forky a všechny další vymoženosti, které GIT přináší.

Používáte-li svn:externals, tento článek je určený pro vás.

(V případě, že bych dělal něco proti GIT-best-practices, prosím upozorněte mě na to, jsem GIT-zelenáč)

Ahoj, pozri na https://github.com/…FU/downloads, je tam starsi .zip len potrebnych suborov pre MFU.. podla nich vies, kt. subory su ozaj nevyhnutne pre MFU a mozes ich z toho balastu naokolo vytiahnut a zacat sa hrat :-) V podstate je ale vsetko potrebne v README.
S NDB nerobim, takze v tomto smere nepomozem.
Keby som mal niekedy cas, tak skusim ten balast z toho repa odstranit ;-)

Muzu poprosit o podporu pro Composer? Snazim se ho pouzit pro muj projekt a tohle by bodlo. Je to paradni vec. Je to hotovy za par minutek.

• lepší organizace souborů ve složce www
• opravdu mít MFU ve složce components v appDir?

Ahoj, já bych nejraději organizaci souborů viděl takto:

• app/components/MultipleFileUpload bych přesunul do složky src (a nejlépe podle PSR0)
• pokud jsou ve www pouze externí závislosti, tak odstranit
• složky app, libs, log,… odstranit

Navrhuji jen to, aby v repositáři byly soubory, které patří k MFU.

To repo slouží zároveň jako příklad – to už teď není v módě?

To doufám nebylo nikdy v módě. Důvody proč to tam podle mne nepatří:

1. Velikost. Teď má naklonovaný repositář přes 5MB, pokud budu ve svém projektu používat 10 doplňků a s každým se mi bude stahovat Nette, dibi, adminer, …, tak z toho nebudu nadšen.
2. Log. Pokud se podívám např. na commit 79c5ba, tak z logu vůbec nepoznám co měnilo. Jestli to je jen nakopírovaná knihovna, nebo jestli tam byly i nějaké úpravy kvůli kompatibilitě, …

Pokud chceš poskytovat i funkční demo, tak bych pro něj udělal vlastní repo, podobně jako má Nette sandbox.

Jako clovek, ktery tento doplnek nepouziva a ani moc neplanuju, zkusim napsat muj nazor k architekture.

Zkracene: Architektura je uplne spatne. :D

Dlouze: Doplnek pro upload by vubec nemel resit databazovou vrstvu. Tecka. Cele bych to vyhazel. Jestli to dobre chapu, je to jen backend pro samotnou komponentu. Urcite to nejde udelat bez toho? Ja plupload takto uspesne provozuju bez problemu (vcetne chunkovani), jako standardni form prvek. Tim se ti dost snizi pocet nutnych repozitaru, cela komponenta se krasne procisti a hlavne, bude delat to, co se po ni zada (chcu upload, proc bych kvuli tomu mel mit db?). Dale bych zalozil organizaci. Jednotlive interface jsou jednotliva repa. Dale take repo demo (tzn. oddelit). A hlavne, interface pro html4 bych dal nativne do zakladniho balicku + dulezite info, nikde jsem nenasel, pridal bych do nativniho balicku interface pro html5. Toz se ti repa docela zjednodussi:

• mfu/mfu
• mfu/plupload
• mfu/uploadify
• mfu/swfupload
• mfu/demo

Hrachu, není to pravda, každá architektura má nějaký důvod a určitě není správně ji shazovat, jen proto, že ten důvod neznáš. Myslíš, že jsem se tak rozepisoval jen tak z plezíru?

MFU řeší problém, když potřebuješ odesílat data například v administraci. Jsi-li autentizován máš svoji session. Problém je v tom, že upload neprovádí vždy prohlížeč, ale například flash. Ten si posílá cookies jaké chce a nedá se na to spolehnout. MFU tedy musí chytat data ještě před startem session, jinak by jsi byl odhlášen. A k tomu potřebuje nějak uložit identifikační tokeny a k nim přiřazené soubory.

Úplně původně MFU využívalo cache Nette. Problém je v tom, že toto použití je chybné. Do cache smíš ukládat jen to, co jsi schopen kdykoli znovu vypočítat. Což tu neplatí.

Potom využívalo přímý přístup do adresáře cache, kde si dělalo vlastní soubory, což bylo úplně zcestné. A navíc tu byl problém s atomicitou při vícevláknovém odesílání. Občas se něco ztratilo. (což se s cache dělo taky)

Potom vznikla myšlenka driverů, že si bude moci každý uložit tyto metadata kam chce. A to je důvod.

Chtělo by to nějak zpřehlednit API, aby si to byl každý schopen jednoduše přepsat pro svoje modely. Však je tam ten striktní požadavek na atomicitu a to se ukázalo jako největší překážka.

Najednou to nesmysl není. Drivery jsou opodstatněné.

@voda:

• Verze knihoven. Chtěl jsem, aby to fungovalo prostě po stažení repozitáře.
• Zatím bych to rozdělil na dva. Example a MFU. Nad těmi dalšími ještě popřemýšlím.

že má něco nějaký důvod ještě neznamá, že je to správně

Pořád lepší řešení nevidím…

Myslíš, že jsem se tak rozepisoval jen tak z plezíru?

To stejné platí o mém postu ;)

Dobrý smeč! :-)

Je jedno. Jde prostě o to, že máš session. Tu můžeš mít a ani nebudeš přihlášen.

Právě. Tu session to poruší, proto je třeba předávat vlastní token a session simulovat pomocí něj ještě před tím, než se session zavede a potom skončit.

Jasný, ale to vůbec nesouvisí s tím, že to ukládáš do db.

Výchozí je SQLite, je v tom problém? Cache v nette taky užívá sqlite jako svůj index. Výhoda je, že je to rychlé a jednoduché na implementaci…

Do adresáře cache je to zcestné, patří to do adresáře temp.

S adresářem cache jsem se spletl. Myslel jsem temp.

Ohledne vicevlaknoveho odesilani – nenasel jsem zadnou zminku o tom, ze by nejaky interface umel odesilat vice chunku zaraz. Pokud je to mysleno ve smyslu, ze mam vice komponent na strance, nevidim v tom problem. Z meho pohledu je disk stejne bezpecne uloziste jako db (ktera je konec koncu taky na disku).

Nene, více chunků ne, ale umí posílat více souborů zároveň.

Navic, ohanis se atomicitou a pritom kdyz se podivam na dibi driver vubec nechapu tuto cast kodu:

…

Fakt netusim, jestli mi neco unika, nebo te tu budu skolit z pouzivani dibi.

Díky za upozornění. Chce to refactoring. Driver jsem nepsal já a byl psán analogicky v sqlite driveru… Tedy nevyužívá všech pěkných vlastností dibi. Než vyjde oficiální verze pro Nette 2.0, projdu to.

Čtu si to po několikáté a pořád vůbec nechápu, co vlastně chceš. Vím jen, že si myslíš, že je něco špatně, ale pořád nerozumím tomu co vlastně a hlavně proč. Zkus to prosím popsat nějak srozumitelněji. Proč si myslíš, že je špatně, že si komponenta chce uložit někam informace, které potom nemusí složitě dolovat? Proč si je nemůže uložit třeba do sqlite? Proč nemůže dát volnost programátorovi v podobě driverů?

session a soubory

Soubory se ukládají přímo na disk, jen meta-informace (tj. do které fronty patří a kolik ho zatím dorazilo) se ukládají přes driver. Vůbec netuším, jaký vidíš rozdíl v tom, jestli si komponenta vytvoří několik složek a do nich soubory s metadaty a k tomu uploadované soubory. Nebo jestli si všechny informace uloží do jednohou souboru (sqlite) a potom už se stará jen o uploadované soubory. Nehledě na to, že použiji-li již něco co je odladěné (sqlite), nemusím ladit něco opět od píky.

dibi driver a drivery vůbec

Ano jde to napsat jednodušeji, ale výsledek je ekvivalentní.

nastavení pluploadu

MFU používá normálně názvy souborů s tím, že na disk ukládá sha1($token . $chunks . $fileNameOriginal), aby se vyhnulo speciálním znakům. MFU by také mohlo všechno ukládat do jednoho adresáře, stačilo by, aby název souboru prefixoval název fronty.

Problém s flashem a cookies:

http://forums.asp.net/…57515.aspx/1
V zásadě jde o to, že všechny prohlížeče posílají pro požadavky z flashe cookie Internet Exploreru.

Pustil jsem se do oddělení příkladu a komponenty samotné…

Narazil jsem však na problémy s GITem i Composerem, se kterými si zatím nevím rady. Pokud někdo tušíte, jak by se toto dalo vyřešit, prosím poraďte!

Problém s GITem. Po rozdělení nejsem schopen připojit do repa příkladu jen část repa komponenty – tedy není možné vytvořit odkaz na adresář. To mi působí značné problémy, protože nejsem schopen do www/MFU připojit složku s js, css, … a do libs/MFU samotné zdrojáky MFU, ale pouze celé repo. Tedy otázka je – je možné to udělat jinak, než založit dvě repa?!

//EDIT: Není toto řešení problému s GITem?

To samé s Composerem. Zdrojáky mají přijít do libs/MFU – v tom není problém. Ale co se složkou, která má přijít do složky www? Nepodařilo se mi nic najít ani na stránkách Composeru.

Při rozdělování jsem předělal adresářovou strukturu, doufám, že k lepšímu… Prosím o komentáře.

(a nyní přemýšlím, jak to celé ztotožnit s myšlenkou DI)

Skvělý, díky za úpravy, brzy vyzkouším.

Jak to myslíš? ;-)

Je to tak, že v současné chvíli existuje vývojová verze pro Nette 2.0. (je to vlastně jen upravená původní verze + clenup) Najdeš ji na Githubu zde: https://github.com/…leFileUpload

Chceš-li si to rozjet i s příkladem, použij composer: https://forum.nette.org/…form-control?p=8 a nebo si jej stáhni z https://github.com/…oad-example/

Už je to jasné? :-)

Každopádně větev pro Nette 0.9 bylo odsunuta na postranní větev.

koren měl asi na mysli NetteDatabase, která je součástí Nette2 a nikoliv dibi. Samozřejmě, nejlepší by bylo pracovat prostě s cache a nevymýšlet kolo.

Jinak upozorňuji, že objekt SQLiteDatabase už v současné verzi PHP nelze získat, takže implicitní metoda nefunguje a měla by být když ne odebrána, tak změněna na alternativní nebo upgradována (ciki to tuším u sebe má).