Új hozzászólás Aktív témák
-
cucka
addikt
válasz riska1982 #10100 üzenetére
Nincs ilyen függvény. Vagy megoldod statisztikai alapon, vagy használhatod az adatbázis fulltext search funkcióit (keresés szövegtávolság alapján, a megfelelő távolságfüggvénnyel), esetleg beizzíthatsz egy saját indexelőszervert (pl. Apache Solr). Arra készülj fel, hogy a megfelelő eredmény elérése nem lesz egyszerű menet. A tippem, hogy a képernyőmentésed a B betűs nagy magyar torrentszájtról van, na például ott is szarul van megoldva ez a funkció.
(#10102) PazsitZ
A soundex távolságfüggvény a szavak angol kiejtése alapján számol, tehát nem angol nyelvű adatoknál kérdéses, hogy jó-e egyáltalán.(#10104) modder
Az ilyen, statisztikai alapú algoritmusoknál a legnagyobb probléma, hogy honnan veszel több tízmilliós mintát, ami alapján elkezdhetsz számolni. A google-nek nyilván ez adott, a PH fórumon tanácsot kérő embernél meg valószínűleg nem. -
cucka
addikt
Úgy szokták megoldani, hogy maga a szerkesztő felület egy iframe. Az iframe-ben a DOM-ot korlátlanul módosíthatod, pl. beszúrhatod a betűt, amit megnyomott a júzer, meg tudod kérdezni, hogy a szöveg mely része van kijelölve, stb.
Az ördög természetesen a részletekben rejlik, egy normális minőségű editorban szerintem simán benne van legalább 1 évnyi embermunka, és a végén lényegében ott fogsz tartani, mint ha az elején hagytad volna az egészet a fenébe és letöltötted volna a ckeditort.(Semmiképp sem akarom elvenni a kedved, de nehezen tudnék ennél unalmasabb, haszontalanabb és buktatókkal telibb projektet mondani, szóval ha csak hobbiból csinálod, akkor nem igazán javaslom)
-
cucka
addikt
válasz riska1982 #10109 üzenetére
Ez esetben az adatbázis által biztosított fulltext search szolgáltatás megfelelő lesz. Ezt szinte mindegyik adatbázis tudja.
(#10110) Soak
Szerintem semmi extra nincs benne, némi javascript/jQuery tudással könnyen implementálható. Kell valami timer, ami minden lépésben arrébb rakja a pöttyöt, meg le kell kezelni azt az esetet, ha a pötty az elején van, a végén van vagy olyan helyen van, ahol oldalt kell váltani. Kb. ennyi az egész. -
cucka
addikt
válasz RootRulez #10118 üzenetére
Én inkább így csinálnám:
function isUrl($val){ return $val != ''; }
$linkek=array_filter(file("linkek.txt"), 'isUrl');
$link=$linkek[mt_rand(0, count($linkek)-1)];
header('Location: '.$link);Próbáld megérteni, mit csinál. Amire figyelni kell:
- Ha beolvastad a file sorait egy tömbbe, akkor tudod a sorok számát, semmi szükség beégetni azt a 10-es konstans értéket. Az én verziómban a random a meglévő sorok közül fog választani egyet. Ehhez figyelni kell arra, hogy az mt_rand hogyan viselkedik a szélsőértékeknél (ezért a -1 a sorok számánál).
- A fileban lehetnek üres sorok, például az utolsó sor utáni sorvége egy ilyet fog eredményezni. Ezért hívom meg a array_filter függvényt. Az isUrl eldönti, hogy a sor az egy helyes url-e (tehát alapesetben nem-e üres), az array_filter-el pedig lényegében kiszűröm a tömbből a helytelen elemeket.
- As isUrl függvényt kiválthatod anonim függvénnyel (php 5.3-tól) vagy használhatod a create_function() függvényt is a célra.
- Valami hibakezelést jó lenne belerakni, legalább arra, hogy mi történik, ha valamiért nem tudja megnyitni a file-t.[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #10121 üzenetére
Ezzel két baj van: nem megy nemzetközi domain nevekre és relatív url-ekre, de egyébként tetszik, ügyes megoldás.
több, mint 1 éve nem fejlesztek php-ban, az ilyen alternatív megoldások már nem ugranak be egyből -
cucka
addikt
válasz Sk8erPeter #10124 üzenetére
De a nemzetközi domainekre miért ne menne? Konkrétan mikre gondolsz?
Rosszul fogalmaztam, az ékezetes domain nevekre gondoltam, azokat nem fogja validálni.Azóta milyen nyelven fejlesztgetsz?
Python-ban egy Pylons nevű MVC framework-el. Teljesen véletlenül alakult így, php fejlesztőnek vettek fel, első héten derült ki, hogy a szoftver, amin dolgozni kell, az bizony python-ban van írva, nem php-ban.(#10123) RootRulez
de akkor ez nem visz át minden oldalra?
Rossz a kérdés. Ennek a program(részletnek) a lényege, hogy egy file soraiból véletlenszerűen kiválaszt egyet, ami megfelel egy bizonyos feltételnek. Tehát ha helyes adatokat adsz meg a file-ba (olyan url-eket, ahova át lehet iránytani a böngészőt) és a feltétel függvényed is jól működik (jelen esetben az, amelyik ellenőrzi, hogy üres-e a string), akkor az átirányítás is jól fog működni.(#10129) Soak
Fejlesztés során rengeteg potenciális hibát lehet kiszűrni, ha teljesen be van kapcsolva a hibák kijelzése - érdemes a szkript elején E_ALL-ra állítani. -
cucka
addikt
válasz Sk8erPeter #10136 üzenetére
Érdekes kis tévedés a munkáltató részéről.
Az ügyfél részéről történt tévedés, de amúgy nem bánom, sőt.milyennek találod így 1 év távlatából a PHP-val összehasonlítva (már ha van értelme ilyen jellegű összehasonlítást végezni)?
Maga a nyelv csodálatosan szép, élmény vele dolgozni, a problémás részek általában a 3rd party csomagok illetve ezek dokumentációs hiányosságai. (A php-val szemben a Python egy általános célra tervezett nyelv, így a webes dolgokhoz szükséges funkciókat leginkább 3rd party csomagokból lehet elérni) -
cucka
addikt
válasz fordfairlane #10187 üzenetére
A singleton elsősorban olyan szoftvereknél használatos minta, amelyek sokáig futnak és van egy olyan komponensük, amely valamilyen külső erőforrást használ.
PHP-nál a szkripted minden egyes oldalletöltődésnél lefut, az objektum élettartama nagyon rövid, ráadásul az adatbázis objektumot jellemzően a keretrendszer hozza létre, egy példányban. Egyszerűen nincs előny abból, ha a singleton mintát használod.(#10204) Soak
Ez tetszett -
cucka
addikt
válasz fordfairlane #10212 üzenetére
Az, amit írsz a singleton-ról, az alapvetően jó, viszont pusztán elméleti. Igen, elméletileg a singleton valóban egy hasznos pattern. A php fejlesztés rögvalóságában viszont:
- Tudod mi van, ha két adatbázis kapcsolat objektumot hozol létre? Semmi sincs. Egy élő rendszeren rengeteg adatbázis kapcsolat létezik egy időben. Tehát itt egy olyan veszélytől (több példány létrehozása) véd meg a singleton minta alkalmazása, amely veszély nem is létezik.
- Egy tipikus php alkalmazásban a keretrendszer hozza létre az adatbázis objektumot, nem maga az alkalmazás. Nem áll fenn a veszély, hogy az alkalmazás véletlenül több példányt hoz létre belőle, mert egy példányt sem fog létrehozni.
- Az adatbázis wrapper osztályt tipikusan valamilyen globális változón keresztül éred el. A többszörös példányosítás itt is értelmét veszti.Egy cseppet sem akarok a design pattern-ek ellen beszélni, de szerintem egy tipikus php-s környezetben a singleton elméleti előnyei elméletiek maradnak. 5 évig voltam php fejlesztő, egyetlen egy alkalomra sem emlékszem, amikor olyan problémába ütköztem volna, amit a singleton pattern megold.
(#10235) RootRulez
Hol akadtál el?[ Szerkesztve ]
-
cucka
addikt
válasz fordfairlane #10237 üzenetére
Szerintem nem anti-pattern, pusztán csak nagyon kevés olyan helyzet van, amikor valóban szükség van rá. Ehhez képest az összes design pattern-ekkel foglalkozó írás az első helyen említi, ezt a legkönnyebb megérteni, plusz ugye az elméleti előnyei elsőre nagyon meggyőzőek. (Csak mint sok esetben, ezek az előnyök a gyakorlatban nem észrevehetők)
-
cucka
addikt
válasz RootRulez #10239 üzenetére
Ez a kód lényegében totál hülyeség, mint ha olyan ember írta volna, aki most tanulta pascal-ban a filekezelést. Érdemes lenne megértened, hogy mit csinál a kód, mert abból nem fog semmi jól kisülni, ha kriptikus kódsorokat másolgatsz abban a reményben, hogy hátha működni fog.
A kérdésedre a válasz a korábbi kódot felhasználva:
function isUrl($val){ return $val != ''; }
//a file sorait beolvasom a $linkek tömbbe
$linkek = array_filter(file("linkek.txt"), 'isUrl');
//véletlenszerű kulcs kiválasztása a linkek tömbből
$tkey = mt_rand(0, count($linkek)-1);
//kiválasztok 1 elemet a tömbből a $link változóba
$link = $linkek[$tkey];
//törlöm a tömbből a kiválasztott elemet
unset($linkek, $tkey);
//ha elfogytak a file sorai, akkor felviszem az új elemet a $linkek tömbbe
if (count($linkek)==0){
$linkek[0] = 'előre megadott szöveg';
}
//a $linkek tömb tartalmát kiírom a fileba
file_put_contents("linkek.txt", implode("\n", $linkek);Ahogy látod, a kód elején beolvasom a file tartalmát a végén meg kiírom, az összes művelet a $linkek tömbben történik. A kód nem kezeli le azt az esetet, ha az elején üres a file, továbbá egy idő után, ha elfogynak a linkek, mindig ugyanazt a szöveget fogja beírni a fileba majd kiolvasni, szóval gondold át, hogy tényleg ezt akarod-e? A kód futása után a $link változóban éred el a kiválasztott sor tartalmát, pl. beleírhatod egy html <a> tag-be.
(#10240) PazsitZ
Az alap problémában nem szerializált formában van a fileban az adat, továbbá kérdéses, hogy mennyire segíti a megoldás megértését a kódod nagy részét kitevő zaj (kiírások, $_GET feldolgozás, stb)[ Szerkesztve ]
-
cucka
addikt
válasz PazsitZ #10242 üzenetére
Egy ötlet volt, hogy most GET-ből van a jóistentől jön a link szabadon eldönthető.
Pont ezért jegyeztem meg halkan, hogy semmi szükség rá egy példakódbanAzt feltételezem írni a másik esetben is kell, önmagától ritkán mászik be és ki az adat a fájlból.
Úgy értem, az eredeti problémafelvetésben ott volt, hogy soronként 1 link van a file-ban, lásd #10115(#10243) RootRulez
A sor végén elfelejtettem lezárni az egyik zárójelet, az a baj. (Fejből írtam a kódot, bocsánat)[ Szerkesztve ]
-
cucka
addikt
válasz RootRulez #10245 üzenetére
Lefuttattam és rájöttem, hogy elcsesztem a kódot két helyen: a file beolvasásnál a sorok tartalmába beolvasom az újsor karaktereket is, illetve az unset-et rosszul hívom. Javítva:
function isUrl($val){ return $val != ''; }
$linkek = array_filter(file("d:\linkek.txt", FILE_IGNORE_NEW_LINES), 'isUrl');
$tkey = mt_rand(0, count($linkek)-1);
$link = $linkek[$tkey];
unset($linkek[$tkey]);
if (count($linkek)==0){
$linkek[0] = 'előre megadott szöveg';
}
file_put_contents("linkek.txt", implode("\n", $linkek)); -
cucka
addikt
válasz RootRulez #10247 üzenetére
notepaddal nincsenek új sorban (minden link egy sorban van). Notepad++-al viszont sorok vannak
Az utolsó sorban az implode-nál a "\n" okozza a furcsaságot. A unix-szerű rendszereken ezzel a speciális karakterrel jelölik a sor végét, windows-on viszont "\r\n"-el (mac-en pedig "\r"-el). A problémád tehát lényegében annyit jelent, hogy a windows notepad-ja nem elég intelligens ahhoz, hogy észrevegye, a file-od unix-féle sorvégeket használ. A php és a notepad++ gond nélkül kezeli mindkét sorvége jelet.mod: a "\n" és a "\r\n" helyett érdemesebb a php beépített PHP_EOL konstansát használni, ez a php-t futtató rendszernek megfelelő sorvége jelet tartalmazza.
[ Szerkesztve ]
-
cucka
addikt
válasz WolfLenny #10295 üzenetére
Elvileg úgy lehet megcsinálni, hogy a webodalad ajax-al adott időközönként megkérdezi a szervert, hogy hol tart az adatfeldolgozással, majd a kapott eredményt kiírja (egy progressbar formájában).
Ezzel (meg az ötleteddel) két baj van:
- komoly terhelést rak a szerverre
- a szerveroldalon belül mi alapján fogod eldönteni az egyik thread-ből, hogy a másik thread hol tart a munkával? Még egy thread-en belül sem egyértelmű kérdés ez.Nem véletlen, hogy ilyen progressbar megoldást nem fogsz találni sehol sem a weben - jól nem nagyon tudod megcsinálni, de egy rossz megoldás is bonyolult és hatalmas az overhead-je.
Esetleg java applet-el vagy valamilyen flash objektummal is kivitelezhető lenne, ott legalább megoldható, hogy a szerver szóljon a kliensnek, ha változott valami, ezzel megspórolhatod az ajax hívások overhead-jét, de a fő probléma továbbra is adott.
[ Szerkesztve ]
-
cucka
addikt
válasz papa019 #10297 üzenetére
Lehet, sőt, általában ilyen megoldást szoktak használni a korábbi hozzászólásomban leírt problémák miatt. Csak ugye egy ilyen .gif funkcionálisan ekvivalens azzal, ha kiírta volna, hogy "kérjük várjon", az eredeti kérdésben meg valamiféle valós adatokból dolgozó progress bar szerepelt.
(#10299) Athlon64+
Ez jó találat, viszont kizárólag file feltöltésre működik.[ Szerkesztve ]
-
cucka
addikt
Már írták a tárolt eljárást, de szerintem a függvényed által szállított végeredményt egy normálisan összerakott sql lekérdezés is vissza tudná adni. Egy join (főleg, ha még index is van hozzá) összehasonlíthatatlanul gyorsabb és jobb megoldás, mint ha ugyanezt php-ban bohóckodod össze.
-
cucka
addikt
Egy ilyen sql-el érdemes elindulni:
select events.* from events where users_id in (select friend_id from relations where users_id={$user_id}) order by dateofcreation ascAz in()-ben található lekérdezés kiszedi a $user_id-hez tartozó barátok azonosítóját (ide php-ban be kell helyettesíteni a $user_id változót. A külső lekérdezés meg egyszerűen listázza az events táblát, leszűrve a megfelelő felhasználói azonosítók szerint. Ha a barát adataira is szükség van, akkor bejoin-olod a users táblát is és kész.
A te php-s megoldásod annyi soron megy végig, amennyi a userek és a relációk számának szorzata, tehát az algoritmusod négyzetes.
Ebben az sql-es megoldásban a belső lekérdezés csak egyszer fut le és az index miatt logn időben végez, a külső lekérdezés pedig végigfut az összes soron, de egy index létrehozásával ezt szintén meg tudja oldani logn időben.
Gondolatkísérlet: tegyük fel, hogy nő az oldalad látogatottsága. Tegyük fel, hogy az eredetihez képest tízszer annyi felhasználó van, ami mondjuk húszszor annyi relációt jelent. Ez esetben:
- az én lekérdezésem nagyjából ugyanannyi idő alatt végez a kereséssel, mint előtte
- a te php-s megoldásod 200-szor ( ) annyi műveletet fog végezni, mint előtte[ Szerkesztve ]
-
cucka
addikt
Kimaradt: amikor hasonló helyzeteket kell megoldani, érdemes arra gondolni, hogy az adatbázis-műveleteknél a legköltségesebb művelet az, amikor az adatok átkerülnek az adatbázis-szerverről a php-be. Ezért minden esetben arra kell törekedni, hogy csak azokat a sorokat/oszlopokat kérjük le az adatbázistól, amelyekre valóban szükségünk van. Nagyságrendekkel gyorsabb, ha az eredmények listáját leszűri az adatbázis szerver, mint ha elkérnénk tőle az összes sort és php-val szűrnénk ki a fölöslegeseket.
-
cucka
addikt
Félreértettél, nem azért írtam ilyen sokat, hogy leszóljalak, hanem hogy meg is magyarázzam, hogy az általam írt megoldás miért jobb, mit a tied.
Általában akkor szoktam ide írni, amikor úgy érzem, a válaszomból a másik fél tanulhat is valamit. Ha csak simán meg kell oldani/le kell kódolni egy feladatot, azt úgy hívom, hogy munkahely. -
cucka
addikt
válasz Sk8erPeter #10362 üzenetére
A "Flat" tárolás az azt jelenti, hogy az adatstruktúra egy vektor - köznapi nevén egy 1 dimenziós tömb. Lehet bármilyen bonyolult adatstruktúrád, ha elég mélyre ásol, akkor előbb-utóbb megtalálod azt a pontot, ahol 1 dimenziós adattárolási struktúra lesz belőle, mivel a számítógép memóriája és a diszk is ilyen "flat" adatstruktúra. A legegyszerűbb példa a láncolt lista (egy nem feltétlenül vektor adatsturkúra), amit programozás órán implementáltatok úgy, hogy az adatok a memóriában vannak (ami ugye egy vektor)
Egymásba ágyazott listákkal kétféleképpen lehet bánni:
- amikor pontosan ismered az adatstruktúrát és az egymásba ágyazás szintjét. Ilyenkor érdemes dupla (tripla) ciklussal bejárni az egészet a view részben. Például ki szeretnéd írni az összes júzer nevét és alá az összes hozzászólásukat - ez egy 2 szintes adatstruktúra, dupla for ciklus.
- tetszőleges mélységű a struktúra: ilyenkor érdemes úgy megírni a bejáró eljárásodat, hogy az meg tudjon hívni egy függvényt minden egyes elemre: kiírás esetén a függvényt a view-ban definiálod és kiírja az adott elemet. Ezt az elgondolást lehet használni például fa adatszerkezetekre. -
-
-
cucka
addikt
válasz fordfairlane #10415 üzenetére
Csak halkan szólok, hogy ez a regexp match-elni fog a "@asd" email címre is, érdemes lenne még dolgozni rajta.
-
cucka
addikt
válasz DeltaPower #10418 üzenetére
Jobban megnézve igazad van, elnéztem a zárójelezést.
-
cucka
addikt
Elnézést, ha belepofázok, de jól láthatóan nem értetted meg az OOP lényegét:
- Az osztályod statikus függvényeket tartalmaz, ami azt jelenti, hogy nem csináltál mást, mint egy névteret globális függvényeknek.
- A függvényeid globális változókat változtatnak, ahelyett, hogy rendes (matematikai) függvényként működnének: a függvény kap n darab bemeneti paramétert, ami alaján kiszámolja az eredményt. Ennyit csinál, nem többet. Nem módosítja a paramétereit. Nem nyúl ki a globális névtérbe. Sőt, igyekezni kell mellékhatás-mentesre csinálni (nyilván sokszor elkerülhetetlen).A fentiek miatt elkerülheted a rengeteg global deklarációt.
Továbbá itt van ez a kódrészlet:
$previous = self::find_previous($id, $users_id);
...
foreach($previous as $previous){
global $previous_pic_id;
$previous_pic_id = $previous->id;
}
- Ciklusban deklarálod a globál változót, biztos ami biztos?
- A foreach-ben érdemes kerülni a névütközést.
- A ciklusod annyit csinál, hogy végigmegy a previous tömbön, majd az utolsó elemnek eltárolja az id-ját egy globális változóba. Minek ehhez végigmenni a previous tömbön?
- Ha a previous tömb utolsó elemére van csak szükséged, miért nem azt adja vissza a függvényed?
- Mi van, ha az első képen állsz és nincs previous? Nem kezeled le az esetet, kiírsz egy üres stringet bele a html-be.
- Ugyanez a foreach megismétlődik a $current változónál, ami viszont nyilvánvalóan nem egy tömb, mert egy aktuális elem van. Ott mi szükség rá? (Vagy mégis tömb? A kódból nem derül ki, és ez nagy baj)Még:
- A $_GET['p'] értékét háromszor escape-eled ki, amíg bekerül az adatbázisba. Ha valóban van az értékben egy olyan karakter, amit ki kell escape-elni, akkor a kódod nem fog működni.
- Az empty() nyelvi elemet (figyelem, ez nem függvény) érdemes elkerülni, jól meg tudod sz*patni magad vele.
- Mivel a php-ban nem látod, hogy melyik változó milyen típusú, érdemes beszédesebb neveket adni - például ami tömb, az többes szám, vagy a függvény paramétereknél $id helyett $pic_id - így nem kell nyomozni, ha fél év múlva tovább akarod fejleszteni a kódodat, akkor el is fogod tudni olvasni[ Szerkesztve ]
-
cucka
addikt
Nem. Egy ilyen url routing szabály úgy néz ki, hogy mondjuk a
/users/{username}
útvonalat átírja úgy, hogy
/users.php?username={username}
Ez persze pszeudokódban van, a routing-ot sokféleképpen lehet intézni. Egy jól megoldott rendszeren jellemzően a php alkalmazás dönti el, hogy egy URI-hoz milyen kontrollert kell meghívni. A webszerver dolga ilyenkor csak annyi, hogy eldönti, ki tudja-e saját maga szolgálni az erőforrást (mondjuk statikus képeknél) vagy sem. Utóbbi esetben a php alkalmazás megoldja saját maga. Ez azért jó így, mert a programod viselkedése a programban lesz leírva, nem pedig egy külső program konfigurációs file-jában.Egyébként olvasgatom az utóbbi hozzászólásokat, ti tényleg ezt a PDO-t használjátok? Olyan ocsmány az egész, szívem szerint bottal sem piszkálnám.
-
cucka
addikt
válasz Sk8erPeter #10630 üzenetére
Miért olyan botrányos? Ezerszer szebb, mint a régi mysql_query()-s bohóckodások...
Pontosan azért, mert igazából nem szebb.
A lényegi különbség kb. az, hogy pdo-val megspórolsz egy változó behelyettesítést a query string-edbe, a maradék, amitől a pdo szép kéne legyen, az szintaktikai varázslat.
Ha egyszer elkezdesz orm-et használni, akkor utána neked sem fog szépnek tűnni a pdo.Meg gondolom az általad használt megoldások is a "natív" PDO-t használják a háttérben.
Amikor még php fejlesztő voltam, akkor egy, a pdo-hoz hasonló saját wrapper-t használtam (használtunk), az sem volt szép így visszagondolva .Kíváncsi lennék egyébként, hogy ha egy adott ORM lényegében egy "wrapper" a PDO-hoz, akkor az milyen overheadet jelent a gyakorlatban. (Már maga a plusz függvényhívások sokasága is overhead.)
A pdo az egy wrapper a mysql* függvényekhez, egy orm ennél sokkal bonyolultabb. (Persze, ez terminológia kérdés: általában a wrapper lényege az, hogy ad egy új interfészt, viszont könnyű súlyú, nem vezet be új absztrakciós szintet)
ORM-nél ha jól meg van csinálva a modelled, akkor az overhead alacsony, de azért el lehet rontani a dolgokat úgy, hogy jelentős legyen a lassulás. -
-
cucka
addikt
Vagy létezhet olyan, hogy pont úgy tölt fel két user képet , ami időben olyan közel lesz, hogy nem a megfelelőt kapom vissza?
Két júzer egy időben az két adatbázis kapcsolatot jelent, a last_insert_id ezt figyelembe véve működik, tehát nem fog előfordulni az eset, amiről írsz.
Permanens kapcsolatok esetén viszont jó kérdés, hogy meg van-e ez ugyanígy oldva, valaki felvilágosíthatna engem is .[ Szerkesztve ]
-
cucka
addikt
válasz pvt.peter #11780 üzenetére
Nem szeretném, hogy úgy tűnjön, leugatok a magas lóról, de ez az elképzelés úgy szar, ahogy van. Egyszerűen felejtsd el, nem lesz jó, nem fog működni, sz*pni fogsz vele.
Ezt a feladatot úgy oldod meg, hogy 1 helyett 2 táblád van: az egyikben vannak a személyek, a másikban meg a személyek extra mezői. Így tetszőleges számú extra mezőt felvihetsz tetszőleges számú személyhez.[ Szerkesztve ]
-
cucka
addikt
válasz sztanozs #11783 üzenetére
Persze így halál lesz az 'egyéb' bezőkben keresni - ha még a mezőnév sem állandó...
Összekapcsolod a két táblát join-al és kereshetsz mindenféle feltétel szerint, legyen az mezőnév vagy bármi más.Persze a mezőnevek is lehetnek külön táblában, hogy véletlenül se legyen elírva - de azért bővíthető legyen.
Ha fontos, hogy ne legyenek elírva, akkor igen, célszerű külön táblába tenni őket. Így lesz normalizált az adatbázisod. -
cucka
addikt
válasz Peter Kiss #11807 üzenetére
Az eredeti hozzászólásban írt, 20 sorban megoldható feladathoz talán mégiscsak túlzás a te próbálkozásod, ahol hosszú oldalakon keresztül csak az oop kód zaja látható. A megoldásod elsősorban nem a feladatot oldja meg, hanem azt próbálja demonstrálni, hogy ismered az php-s oop kulcsszavak használatát - lényegében pont azt mutatja be, hogy hogyan ne írj jó oop-s kódot.
-
cucka
addikt
válasz Sk8erPeter #11809 üzenetére
cucka az előző hsz.-ben pedig elég tömören elmagyarázza azt is, amit én is éreztem a konkrét kérdés kapcsán, csak ő sokkal jobban megfogalmazta.
Igen, az az elméleti okoskodás rész, ami akár elfogadható is lehet. (Nem az, ha valaki az informatikában megmondja a tutit, hogy csak és kizárólag egy módszer az elfogadható, na ő téved)
A másik oldal meg a kód, amiből lényegében a class oriented dizájn állatorvosi lova, kb. mint ha egy java programozó első php-s kódja lenne.A php egy szkripnyelv, ezt érdemes szem előtt tartani, hogy valóban php-ban írjuk a php kódot, nem pedig javaban.
-
cucka
addikt
válasz Sk8erPeter #11812 üzenetére
Azutánira: szintén egyetértek, ha valaki igazi OOP-s környezetet akar, akkor álljon át valamelyik webes Java-technológiára vagy például ASP.NET-re.
Van rengeteg "köztes" megoldás is, igazából manapság kevés olyan nyelvet használnak, ami ne lenne így vagy úgy objektumorientált - a php is ilyen.A probléma az idézett kódnál elsősorban az, hogy megpróbál túlságosan általános lenni, miközben ennek az égvilágon semmi értelme. Oop-vel könnyű olyan osztály hierarchiákat kialakítani, ahol minden komponens cserélhető, kiterjeszthető. A nehéz dolog előre látni, hogy a rengeteg lehetőség közül melyikre is lesz szükség valójában, és melyek azok, amelyek csak a program hosszát és a zajt növelik, hasznuk semmi. Például az említett kódban az összes oop rész gyengíti az alap algoritmus szemléletességét, miközben a feladathoz által nem megkövetelt komplexitást hoz be, megvalósítva azt az anti-patternt, ami "excessive accidental complexity" néven fut. (Van erre valami jó magyar szakkifejezés? )
annak az agya nyilván sokkal inkább rááll az OOP-s gondolkodásra, és nem valószínű, hogy engedni akar belőle
Szerintem a fejlesztő agya elsősorban a gondolkodásra kéne ráálljon. Mindenkinek javaslom, hogy hobbiból játszadozzon egy funkcionális nyelvvel (javaslatom a Clojure) - el fog bizonytalanítani, a szokásos pattern-ek nem működnek benne, pont ettől segít olyan sokat. Megtanít arra, hogy a feladatra és a program olvashatóságára figyelj, és ne foglalkozz semmilyen, valaki által kitalált és "one and only"-nak kikiáltott esztétikai iránymutatással.[ Szerkesztve ]
-
cucka
addikt
válasz Peter Kiss #11815 üzenetére
Tudom, hogy a PHP script nyelv, de az is baj, hogy ebből nem bír kinőni
A szkriptnyelveknek nagyon is van létjogosultsága és jövője, ne írd le őket.
A php baja leginkább az, hogy egy inkompetens fickó tervezte és mai napig a régi verziók rossz megoldásait nyögi a visszafele kompatibilitás miatt.a Zend is próbál mindig jobban arra sarkallni, hogy objektumokkal dolgozzunk
A Zend nem tudom, mire sarkall. Én úgy látom, hogy a php-ban egyre több a funkcionális nyelvekből átvett megoldás, ez pont nem az a tisztán oop-s irány.Ezt annyira komolyan gondolom, hogy hobbiként fejlesztett rendszeremben a super global tömböket se kell használni.
Úgy érzem, hogy te a lelked mélyén java-ban szeretnél fejleszteni (esetleg c#), a kérdés, hogy miért ragaszkodsz a php-hoz? Átveszed azt, amitől a java nem túl jó és kidobod azt, amitől meg a php igen. Hobbi szinten végül is mindegy, szerintem inkább érdemesebb minden eszközt arra használni, amire való.Emellett nem is szeretek úgy gondolkodni, hogy van egy feladat, aztán azt a lehető legegyszerűbb, legrövidebb módon oldjuk meg, mert mi történik akkor, ha jön egy hasonló?
Világos, viszont a túlzásba vitt általánosítás komoly veszély. Angolul "overgeneralization" néven fut ez az anti-pattern, amikor a lehető legáltalánosabb kódot szeretnéd írni anélkül, hogy tudnád, szükséges-e (kapcsolódik még ide a "premature optimization" nevű antipattern is).
Dolgoztam már ilyen, lehető legáltalánosabbra megcsinált php-s framework-el. A tapasztalat, hogy a korai általánosítás inkább ront a helyzeten, mint javít - nekünk folyamatos szopóroller volt, hogy ott volt a nagy, bonyolult keretrendszer, ami minden eshetőségre fel volt készítve, kivéve arra, amire épp szükség lett volna, tehát lehetett áttervezni/refaktorálni. A lehető legáltalánosabb kód írása papíron hangzik csak jól.Mikor van hatalmas előnye annak, ha mindent a lehető legabsztraktabb módon írunk le? Akkor, ha tesztelni is akarjuk a kódunkat
TDD-hez elég, ha moduláris a kódod, pl. globális függvényeket pont ugyanolyan jól fogsz tudni tesztelni. Persze, azért itt már előnyös az oop.
Smoke test-nek meg nincs igazán köze ahhoz, hogy oop-s vagy nem oop-s a kódod. -
cucka
addikt
-
cucka
addikt
válasz Peter Kiss #11821 üzenetére
Nem írtam le a szkriptnyelveket, de a PHP pont olyan, ami simán le tudja vetkőzni magáról a szkriptnyelvségét
Nem kell levetkőzze magáról. A szkriptnyelv nem alacsonyabb rendű, mint a hagyományos, típusos, fordított nyelvek, hanem más.
Az egyik kedvenc tech blogomon pont ma jött ki egy bejegyzés, amivel maximálisan egyet tudok érteni, lásd itt . (Érdemes a többi bejegyzést is olvasgatni, nagyon jók)Mit vett át funkcionális nyelvekből?
Utánanézve azért túl sokat nem. Vannak lambdák, van closure, már csak valamiféle "list comprehension" kéne (tervezik), továbbá ott vannak régről a map, filter, reduce, stb. eszközök. Persze az új dolgok szintaxisa igazi kendácsolás, de hát az egész php nyelv ilyen, meg van kötve a kezük a sok évvel ezelőtti rossz döntések miatt.Java-ban nem szeretnék fejleszteni, .NET-ben lehetőségem van minden nap
Na, hát csak kibújt a szög a zsákból. Igen, a .net (vagy a java, mindegy) tisztán oop-s szemléletet kényszerít rád, ez van, amikor előnyös és van, amikor annyira nem előnyös.
Mellesleg nagy feladatokat mostanában mindenhol oop elvek mentén fejlesztenek, igen, még szkriptnyelvekben is. Ami a szkriptnyelvek előnye itt, hogy a java/c# jellegzetességének számító boilerplate kódok hiányoznak.Overgeneralization-től még nagyon messze vagyunk, nyilván nem kell minden üzleti problémára egy mindent tudó solver-t írni, de azért arra oda kell figyelni, ne legyen semmi sem túlságosan összedrótozva.
Azokat a komponenseket, amelyek megállnak a saját lábukon és újra felhasználhatóak, azokat lib-eknek hívjuk. Egy egyedi szoftver egyedi megoldásaiból sosem lesz lib, sosem fogod újra felhasználni őket. Szóval akkor miért kéne magad azzal sz*patni, hogy úgy írd meg a szoftvert, mint ha egy csomó részét újra fel szeretnéd használni?
Nem azt mondom, hogy írjunk direkt szar kódot, hanem hogy a fejlesztés során megcsinált általánosítások nagy része teljesen fölösleges.Azért, mert dolgoznod kellett egy rosszul megírt keretrendszerrel, még nem jelenti azt, hogy mindenhol rémeket kell látni.
A keretrendszer jól volt megírva és elméletileg k*rvajó kellett volna legyen, a probléma, hogy a valós igények nem pont olyanok, mint amit elméletileg előre el tudsz képzelni.TDD-hez nem elég a modularitás, mert simán tudsz olyan kódot írni (OO vagy nem OO), amit egyszerűen nem bírsz tesztelniű
Miért, oop-val nem tudsz nehezen tesztelhető kódot írni, ha nagyon akarsz?[ Szerkesztve ]
-
cucka
addikt
Nem kell hozzá curl. Lényegében a galéria letöltős linked egy php oldalra fog mutatni (mondjuk oldaladneve/download_gallery.php?gallery_id=5 ). A php szkript összeszedi a galéria file-jait, bezippeli és elküldi a kliensnek. A küldés lényegében annyit jelent, hogy beállítod a megfelelő header-eket (elsősorban content-type), majd egyszerűen kiírod a zip file tartalmát a standard kimenetre (vagy csinálhatod fpassthru-val is, gyorsabb).
A kényes kérdés itt a zip-elés. Több lehetőséged van:
- A php zip eszközeivel menet közben állítod elő a zip filet. Ezzel az a baj, hogy hamar ki fog futni a memóriából a php.
- A php meghív egy shell script-et, ami elvégzi a zip-elést (parancssoros zip-el), a zip filet lerakja a temp-be. Te onnan fpassthru-val kiköpöd a standard kimenetre, majd törlöd a filet.
- Minden galéria módosításnál elkészíted a zip filet, így bármelyik galériát is szeretné letölteni a júzer, csak átdobod neki a meglévő filet. Ez jó, ha ritkán változik a galéria, viszont gyakran töltik le egyben. A zip file elkészítésére a fenti 2 pont érvényes.(#11840) Speeedfire
Ez jó, csak az alap probléma, hogy nem 1 file-ról van szó, hanem többről (galéria). Ezért a zip-elés.mod: továbbá érdemes tudni, hogy a böngészők igyekeznek intelligensen kezelni az érkező file-okat. Ezért van az, hogy egy zip filet automatikusan felajánl letöltésre anélkül, hogy varázsolni kéne a http header-ekkel. Nyilván, egy jpeg file-nál rá kell erőltetni ugyanezt a viselkedést a megfelelő header-ek segítségével.
[ Szerkesztve ]
-
cucka
addikt
válasz Speeedfire #11844 üzenetére
Így olvasva a köv. hozzászólásokat, nekem úgy tűnik, hogy kettőnk közül én értettem félre, és tényleg 1 fileról van szó.
-
cucka
addikt
válasz Inv1sus #11848 üzenetére
Az a baj, hogy szar a reguláris kifejezés, amit használsz. A minta, amire keresni kell, az úgy néz ki, hogy width="...", ahol a három pont helyén bármilyen karakter lehet, ami nem idézőjel.
Én így oldanám meg, próbáld értelmezni. A minta végén a \s az bármilyen whitespace karakterre match-el, ebből tetszőleges számút szintén kidobok, szóval a végeredményben nem lesznek fölösleges szóközök, a minta végén az i betű pedig azt jelenti, hogy kis-nagybetűket ne vegye figyelembe (case insensitive) :
function process($str){
return preg_replace(
array(
'/width=\"[^\"]+\"\s*/i',
'/height=\"[^\"]+\"\s*/i'
),
array('', ''),
$str
);
}[ Szerkesztve ]
-
cucka
addikt
válasz Swifty #11852 üzenetére
Ebben a topikba járnak kezdők, haladók és profik is. Na a kontent is pont ezt fogja tükrözni.
Ha kizárólag banális, 3 perc gúglizással megoldható, középiskolai házifeladat szintű dolgokkal találkoznék itt, akkor nem olvasnám a topikot, és szerintem ezzel nem csak én vagyok így. (Főleg így, hogy ~2 éve nem is fejlesztek php-ban )
A topik címe "php kérdések", nem pedig "php gyorssegély kezdőknek".És bocs, de pont lesz*rom, hogy lesznek látogatók, akik nem értik azt, amiről a beszélgetés folyik. Én sem értek sokmindenhez, mégsem megyek oda a megfelelő szakmai topikba emiatt panaszkodni.
[ Szerkesztve ]
-
cucka
addikt
válasz Peter Kiss #11862 üzenetére
"~2 éve nem is fejlesztek php-ban" - így egy kicsit világosabb, miért írtad azokat, amiket.
Márhogy pontosan mi lett világosabb ettől az információtól?
(Amúgy igen, maradtam a szkriptnyelv vonalon, de lehet, hogy 1 éven belül már java fejlesztő leszek, legalábbis ez a valószínű forgatókönyv)
Új hozzászólás Aktív témák
- A fociról könnyedén, egy baráti társaságban
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Kínai cégek segítik ezentúl a Teslát, a Renault-t, a Hyundait és a Toyotát
- Jövedelem
- Gyúrósok ide!
- Milyen videókártyát?
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Politika
- World of Tanks - MMO
- További aktív témák...