Fájl törlés Codeigniter-ben
Üdv emberek!
Most kezdtem ismerkedni a Codeigniterrel és akadt egy kis gondom. Van egy oldalam, ahol e-bookok vannak tárolva és listázva. Akartam írni hozzá egy törlést, hogy ne kelljen egyenként kiszedni adatbázisból ha törölni akarom őket. Na most a db-ből szépen el is tűnnek, de a fájlok a könyvtárban ott maradnak. Két féle fájl van, egy maga az e-book a másik egy kép, ami a borító lenne. A kód:
ebook_model.php:ebooko_controller.php:Hibaüzenetet nem dob ki, az adatbázistörlés(amit most innen kivettem) tökéletesen lefut.
Valaki tudna segíteni?
■ Most kezdtem ismerkedni a Codeigniterrel és akadt egy kis gondom. Van egy oldalam, ahol e-bookok vannak tárolva és listázva. Akartam írni hozzá egy törlést, hogy ne kelljen egyenként kiszedni adatbázisból ha törölni akarom őket. Na most a db-ből szépen el is tűnnek, de a fájlok a könyvtárban ott maradnak. Két féle fájl van, egy maga az e-book a másik egy kép, ami a borító lenne. A kód:
ebook_model.php:
function torles_file($konyv)
{
$this -> db -> select('borito, filename');
$this -> db -> from('ebook');
$this -> db -> where('id',$konyv);
$this -> db -> limit(1);
$query4 = $this -> db -> get();
foreach ($query4->result_array() as $sor):
$file_nev=$sor['filename'];
$borito_nev=$sor['borito'];
delete_files('./boritok/'.$borito_nev);
delete_files('./konyvek/'.$file_nev);
endforeach;
}function konyv_torles()
{
$this->load->helper("file");
$konyv= $this->uri->segment(3, 0);
$this->load->model('ebookkiolvasas');
$this->ebookkiolvasas->torles_file($konyv);
}Valaki tudna segíteni?
Segítség és tippek
delete_files()metódus a paraméterül kapott mappa összes fájlját törli, ha csak egy-egy fájlt szeretnél törölni, akkor a PHP beépítettunlink()függvényével tudod megtenni. Pl.:unlink(realpath(FCPATH . '/boritok/' . $borito_nev))- már ha tényleg ez a fájl elérési útja - az FCPATH az apllication és system mappákkal egy szinten található index.php (a program belépési pontja, ahova minden lekérés befut) elérési útját tartalmazza, tehát ehhez képest adod meg kívánt fájl elérési útját. Arealpath()használatával kapod meg a végleges platform független elérési útját a fájlnak.Néhány javaslat:
Alternatív szintaxis
Ezen a helyen már többször olvastam figyelmeztetést. Kerüljük az alternatívot, illetve az csak bizonyos helyen, mondjuk "view"-ban megengedett. Hiányzik az indoklás. A szokásjog is megfelelő, vagy technikai korlát ha ismersz ilyet.
szerintem az identálás és
ellenben ha keverve van a php más kóddal pl html-lel akkor hasznos, ha beszédes egy blokk lezárása, mert egy <?php } ?> rész kezdetének megtalálása igen fájdalmas lehet, itt a php 'vezérlésen' van a hangsúly, ezért kiemeljük hogy olvashatóbb legyen.
Olvashatóság
Endif, endwhile nálam akkor van ha lelóg a képernyőről a közbezárt kódrész. A blokk végén is látom mi ért véget. Semmi közepén álló zárójel mihez tartozik, hányat kellene látnom ...
A tabulálás működik.
Ilyen esetben inkább
és
Van aki csinálja, én még nem
+1 és pár gondolat
Itt pedig már bejön minden olvashatósággal általában kapcsolatos érv, például hogy a kódot nem csak magának írja az ember, stb. Mondjuk erre a legtöbben magasról tesznek, sajnos.
6: Kód átszervezés
Más kódjában tapasztalhattam hasonló szemléletet. Ami nálam több képernyő az X-nél feldarabolódott egymást hívó függvény láncba. Javasolt módszer, de mégis, érdemes ezért 7-8 szintet létrehozni? (ennyi jött össze)
Kódszervezési ajánlások
Ha komolyabban érdekel a kódszervezés téma, akkor nézz utána a clean code és TDD fogalmaknak. :)
Kérdések
Az ilyen szám szerinti
Logikusan átlátható részfeladatokra bontani a feladatot, az sokkal jobban hangzik. Logikus elnevezésekkel ugrálni se kell folyton a függvények között, ráadásul ugyanazt a részfeladatot mindig elvégeztetheted ugyanazzal a függvénnyel.
Szubjektív
Nálam a 210 soros metódus
Ne viccelj már :) Tényleg 210
- Ránézéssel azonnal átlátod mit csinál a metódus, nem kell végigtekerni egy marhanagy kódot.
- A comment nem él együtt a kóddal, nagy részük előbb-utóbb nem tükrözi a valós működést és csak félrevezeti a később odatévedő fejlesztőt. Tudom, erre mindenki figyel, mégis ez egy létező probléma.
- Nem vezérlési szerkezetek tömkelegét kell felfognod, hanem nagyjából egy mondatszerű hívási láncot.
- A spagettikóddal szemben ez tesztelhető, és karbantartható.
Nem tudom ebben mi a szubjektív. A szokást aláírom, a spagetti kód egy rossz szokás :)Szubjektív
Is is
A számok pedig kinek mennyi (szerintem 10 és 500 közt :)), és ugyanúgy a stack terheltsége is...
Az első és legfontosabb dolog, hogy te később is átlássad a kódod, és rögtön a második, hogy a kollégáid is. Aztán ahány ház, annyi szokás...
Stack vs inlining
Igen, szerintem ilyenkor
Persze mindig vannak kivételek, de ha a kódomban megjelenik egy monolit függvény/metódus, ami ki se fér a képernyőre, akkor azért gyanút fogok, hogy valami itt nem stimmel :).
Olvashatóság
endforeach-et használt, akkor számára a kapcsos zárójelek lesznek furcsák. Tehát ebben a témában mindenki csak a szubjektív véleményét tudja leírni, így ezen vitatkozni sok értelme nincs.Ennél sokkal fontosabb, hogy egy cégen belül mindenki ugyanazokat a konvenciókat alkalmazza, ennek betartatása pedig a cégvezetés dolga, mert a programozók maguktól valószínűleg nem fognak erre figyelni.
Érdemesebb inkább a kapcsos
Szubjektív
Ezzel így természetesen
Én arra válaszoltam, amit írtál (ahhoz, amiről egyébként szó volt):
Orionstar: Kódszervezési ajánlások
Érdekel a kódszervezés meg nem is. A módszertanok zöldmezős fejlesztésre vonatkoznak, általában. Én így értékelem őket, ilyennek látszanak. Ha módosítandó valami, és nálam ez volt a gyakori, akkor ott van az "átalakítás". Ha nem elég akkor még mindig lehet "refaktorálni". Szóval, amit gyakran csináltam arra szűk a módszertani választék.
A módosítás szerintem
Szóval a módszertanok lehet, hogy épp arra vannak kitalálva, amit te csinálsz? :)
Beyond clean codeDo you
Módosítás
Probléma, valahol módosítani kell. Az a rész nincs jelölve. Hogy találom meg? Hol itt a módszertan? TDD?
Eddig lehet, szabálytalanul jártam el. Mivel üzleti alkalmazásról van szó, a keresést a "perzisztencia" felől kezdtem. Az megmutatta mely programrészeket érint a bővítés. A módszertanokban mindig kód és kód és kód játszik. Hogy miért pont azok amelyek, azt adottnak veszik.
Erről van szó
Tipikus eset, amikor bemutatnak egy újabb lehetőséget, leírják, hogy mik az előnyei, és hogy ez nekik mennyit segített a munkában. Ez eddig szép és jó, de a hátrányok bemutatásáról általában el szoktak feledkezni, márpedig az éremnek mindig két oldala van, és általában olyan, amit te is írsz, hogy "derült égből új üzleti igény", ami sehogy sem illik a korábbi működésbe (nekünk pont ma volt ilyen, de aztán a főnököm egyelőre lemondott róla).
Egy nagyon jó példa erre egy általam nemrég talált blogbejegyzés, ami a Scrum metódust mutatja be, aztán a kommentek között valaki leírja, hogy mindaddig működik a dolog, amíg ideálisak a feltételek, azaz van pénz és nem sürget az idő, de ahogy legalább egy nem teljesül, borul a bili (érdemes elolvasni a többi hozzászólást is).
Te miben hiszel?
Persze
$valasz = lekerdezes($sql);2, teljesen válasszuk szét a programlogikát és az adatokat a megjelenítéstől
A többi projektfüggő.
Ennek fényében fura, hogy
Igen, de én ebben az esetben
Igen, de én ebben az esetben
Senki nem azért használ
Ha ez így lenne, akkor nem
Persze, és tollal is lehet
Visszakérdezek: te milyen
Mi scrumot használunk, picit
Ezekkel megnyerjük azt, hogy többnyire igen jól olvasható és karbantartható a kódbázis. Valamint még fejlesztési időben elkapjuk azoknak a hibáknak a jó részét, amit a tesztelés hiánya miatt simán becommitolnánk, és bekerülne a releasebe. Ez sok egyéb szempont mellett azért nagyon fontos, mert így a legolcsóbb a hibák javítása. Ha ezen a fázison túljut egy probléma, akkor a fejlesztő már máson dolgozik, több időbe kerül neki a probléma lokalizálása (context switch), esetleg blokkol vele más fejlesztőket, vagy ami még rosszabb, már ráépítettek a hibás komponensre, ezért a javítás nem lokális, hanem szerteágazó. Ha a manuális tesztelésről pattan vissza a feature, akkor azt újra le kell majd tesztelni, ami sok idő, és az emberi erőforrás a legdrágább. Emellett a manuális tesztelés nem tud teljesen átfogó lenni, így önmagában abban nem bízhatunk meg. Én személy szerint azt gondolom, hogy a minőséget mindezek nélkül nem lehet biztosítani, és az otthoni pet projecteket leszámítva (de néha még ott is) ez egy alapvető elvárás. Amikor fejlesztünk, valakinek a idejével, pénzével "játszunk". Megrendelő, cégvezető, saját... Márpedig ha nincs minőségbiztosítás, igen nehéz kivédeni a szükségtelen kockázatot. Minőséget pedig csak viszonylag merev szabályokkal lehet biztosítani. Amiket néha áthágunk, ha a szükség úgy hozza (és ezt dokumentáljuk), vagy alakítunk rajta, ha nem jól fedi le az igényeket. De a szükségességét szerintem nem lehet elvitatni. Ezt az egész processt pedig a project méretéhez, igényeihez kell igazítani, egy 3 fős kiscég nyilván nem tud fenntartani egy nagy infrastruktúrát, vagy ha úgy tetszik bürokráciát. A pár sorral feljebb írtakat figyelembe véve (más pénzével, idejével játszunk) azzal viszont egyáltalán nem tudok egyetérteni, hogy az automata teszteket érdemes elhagyni, mert "növelik a fejlesztési időt", vagy mert "majd a userek letesztelik", vagy mert "a mi alkalmazásunk nem igényli az automata tesztelést". Mindet nagyon jól meg lehet cáfolni. Egy dologgal értek egyet: a bevezetése költséges, ha nincs(enek) olyan ember(ek) a csapatban, aki(k)nek van jó tapasztalata. De ez gyakorlatilag mindenre igaz, és csak egyszer kell megfizetni.
90%
Úgy tűnik, amikor elvekről beszélsz akkor elsősorban a tesztelést szolgáló módszerekről van szó.
Finomítok az álláspontomon:
Viszont kisebb projekteknél nem feltétlenül éri meg ezeket használni, mert esetleg többe kerül a leves, mint a hús, ráadásul a szivárgó absztrakciók miatt célszerű minél egyszerűbben elkészíteni a szoftvert, hogy minél kevesebb hibalehetőség legyen benne.
Nem is írtam, hogy mindenhol
Szivárgó absztrakciók. Szerintem totálisan félreértelmezed Joel cikkét (gondolom innen fúj a szél). Nem azt írja, hogy ne használj absztrakciót mert az rossz, hanem hogy attól még hogy absztrakciót használsz, ismerd a problémád számára fontos abszrakciók mögötti valós működést. Ez egy nagyon nagy különbség :) Az absztrakciók segítenek egyre hatékonyabb, komplexebb és átláthatóbb programokat írnunk. Ezt ő is kiemelte a cikkében. Egy mezítlábas függvényhívás ugyanolyan absztrakció, mint ami egy design pattern mögött van pl. Mondhatnám, hogy akkor programozz assemblyben, de hát az is egy nagyon durván magas absztrakciós szint a processzor belső működéséhez képest :) Amit ebből le lehet szűrni, hogy gondolkodó ember módjára kell softwaret fejleszteni, és meg kell látni a feladat mögött a lényeget, és hogy ahhoz milyen eszközt kell használni.
Valóban, a tesztek írása X%
- A fejlesztés ideje ez alapján legalább négyszerese annak, ahol nincsenek tesztek
- Az össz programkód négyszerese a szükségesnek, ennyivel több hibázási lehetőséggel
A fejlesztés ideje ez alapján
Megint az az érzésem van, hogy olyan dolgon vitatkozol, amiben nincs értékes project tapasztalatod, és dobálsz be idézeteket, meg kontextusából kiragadott fogalmakat, amik teljesen nem illenek oda, és jellemzően nem állják meg a helyüket.
»A fejlesztés ideje ez
Nem ismétlem magam sokadszor. Röviden: ez nem igaz.
A teszt nem része a programnak.
Ő ezt sem írta. És ez értelmetlen is.
»Mivel minden absztrakció szivárog, minél többet használsz, annál nagyobb az esély, hogy lyukra futsz«
Ez mégis mit jelent? :)
Vegyünk egy aktuális példát: korábban volt egy blogmark, az alapján találtam ezt a linket, ahol leírják, mi a gond mobilokon a böngésző alapú alkalmazásokkal. Nézzük az absztrakciós listát Androidon:
- DOM objektum
- böngésző
- virtuális gép
- operációs rendszer
- hardver
Mindegyik absztrakciós szint egy újabb szivárgást hoz be, például azt, hogy böngészőben nem tudod a memóriát menedzselni, hanem az automatikus (GC), valamint az egyes objektumok jóval több memóriát foglalnak el, mint amennyi kevesebb szint esetén szükséges lenne. Ennek a következménye (többek között), hogy a natív alkalmazások ismét virágkorukat élik, és még úgy is megéri velük foglalkozni, hogy tudjuk, elvileg a közös webes platformon elég lenne egyszer megírni őket.
Amire nem válaszoltam, azon gondolkozom.
Tapasztalataid szerint
Az androidos példádra nem tudok érdemben reagálni, mobil fejlesztéssel eddig még nem foglalkoztam, így nincs releváns tapasztalatom, csak pet project jellegű. De azt azért ne felejtsd el, hogy ez még mindig egy viszonylag új terület, ahol a gyártók még nem, vagy csak a high-end területen találták meg a választ ezekre a problémákra. Az egész iparág célja, hogy általánosságban minél magasabb absztrakciós szinten dolgozzunk, hisz annyival nagyobb értékű funkcionalitást tudunk implementálni egységnyi idő alatt. Ezért ahogy az Intelnek is megjött a válasza pl a polimorfizmusra (unconditional branch prediction), úgy szerintem a mobil iparnak is meg lesz.
Minden módszernek van
Hirtelen az a példa jut eszembe, hogy bár a kalapács remek eszköz szögek beverésére, akik mindig az ujjukra csapnak a szög helyett, többnyire a kalapácsot fogják szidni.
Ehhez jön hozzá, hogy nem létezik Szent Grál, tehát hibát mindenben fogsz találni. Mivel a módszertanok használata igényli, hogy feladd bizonyos szokásaidat, berögzött módszereidet, tehát alkalmazkodóképességet igényel, rendkívül sok programozó kapásból bukja az egészet (mivel hát emberek vagyunk mi is, na). Ekkor persze mivel a hiba biztos nem bennem van, be kell bizonyítani, hogy a módszer fassság és mivel bizonyára vannak hibái, könnyen el is hiteted magaddal (velem legalábbis így volt/van, és ezt a mintát sok helyen vélem felfedezni).
Affelé hajlok, hogy mivel a mi szakmánkban mindennapos dolog a "derült égből üzleti igény", tekintve hogy a döntéshozók többnyire analfabéták, ami még nem lenne baj, de ráadásul kompetensnek hiszik magukat, nekünk olyan módszereket kéne használnunk, hogy erre fel legyünk készülve, nem? Merthogy szakemberek vagyunk. Ha egy módszer 5%-al megnöveli a projektem rugalmasságát, cserébe néhány szokásomat fel kell adnom, akkor szakemberként ez jó üzletnek tűnik, még ha emberként nem is.
Szóval, a te szavaiddal élve, én igen szkeptikus vagyok a módszertanok fikázóival kapcsolatban, és nem véletlenül :).
tekintve hogy a döntéshozók
Hogyan tudsz valamiről jó döntést hozni, ha nem ismersz pro és kontra érveket?
A módszertanok zöldmezős
Talán az életciklus modell
Ezt olvastam: Ha eljutott a dolog a bevezetésig akkor új igény esetén "goto 1". Szerintem akkor már más feltételek között kell fejleszteni. Nincs szükség ágyúra, a meglévő kód kötöttséget jelent. Melyik módszertan számol ezzel, és hogyan?
Az a példa, miszerint létrehozzuk az interfészt üresen, utána majd csak megoldjuk, az tiszta lapon rendben van. Általában ami későbbre halasztja a tényleges munkát az nem látszik megfelelőnek. Vagy én nem tudok velük mit kezdeni.