Új hozzászólás Aktív témák
-
#13235
Sk8erPeter
nagyúr
cucka
#13227
Sk8erPeter
nagyúr
Jaja, ez így szebb lehet, habár annyi hátránya mondjuk van, hogy így kétszer kell végigmenni a tömbön 1 helyett, ami meg lehet, hogy felesleges (bár sanszos, hogy futási időben nem tesz hozzá sokkal többet, max. ha óriástömbről van szó).
Asszem amúgy 5.3-tól vannak lambdák, igazából illene már az osztott tárhelyeken áttérni erre, ha még nem tették. -
#13225
Sk8erPeter
nagyúr
Speeedfire
#13222
Sk8erPeter
nagyúr
válasz
Speeedfire
#13222
üzenetére
szívesen!
-
#13221
Sk8erPeter
nagyúr
Speeedfire
#13215
Sk8erPeter
nagyúr
válasz
Speeedfire
#13215
üzenetére
Kétszer szerepel a lezáró </td>, ez így hibás szintaktika.
Gondoltam jelzem, mielőtt elkezdesz vele szívni.
A második lezáró helyett egy </tr> kéne oda.(#13218) Speeedfire :
így is át lehet rendezni, hogy ne kelljen neked a $data változó (nem mintha olyan sok vizet zavarna, de végül is tényleg nem muszáj használni):if($specs) {
$tablerows = '';
foreach($specs as $key => $spec) {
if($spec != '') {
$tablerows .= sprintf('<tr> <td> %s: </td> <td> %s </td> </tr>', $key, $spec);
}
}
if($tablerows != '') {
echo '<table>';
echo sprintf ('<tr><td colspan="2"><strong>%s</strong></td></tr>',
Shop::t('Product Specifications'));
echo $tablerows;
echo '</table>';
}
}most csak gyorsan összedobáltam
-
#13219
Sk8erPeter
nagyúr
cucka
#13214
Sk8erPeter
nagyúr
Félreértetted, eddig sem tömbindexekről volt szó, arra kérdezett rá, hogy hogyan vizsgálja, hogy "asszociatív tömb értéke" üres-e. Tehát pontosabban az asszociatív tömb kulcsainak/indexeinek értékét szeretné vizsgálgatni, hogy az egyenlő-e az üres stringgel.
Egyébként meg pont ebben az esetben nem látom be, miért is ne lenne jó akár az empty()-t is használni, hacsak nem azért, mert nem fejezi ki pontosan a kódot kutatva, mire is szeretnénk vizsgálgatni (üres string); de működést tekintve jelen esetben az elvártak szerint működne... Ha bármely olyan eset igaz abból, ami az empty() esetekre vonatkozik, akkor nem íratunk ki semmit.
-
#13210
Sk8erPeter
nagyúr
Speeedfire
#13209
Sk8erPeter
nagyúr
válasz
Speeedfire
#13209
üzenetére
Hümm, eszerint támogatnia kellene:
http://stackoverflow.com/questions/11321708/netbeans-scss-file-autocomplete-just-like-css-file/12198873#12198873
Próbáld meg innen letöltve:
https://code.google.com/p/scss-editor/downloads/list -
#13207
Sk8erPeter
nagyúr
Peter Kiss
#13204
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13204
üzenetére
De elég félrevezető a Notepadhez és a NetBeans-hez hasonlítani, mert a SASS/SCSS se nem szövegszerkesztő, se nem egy komplex fejlesztőkörnyezet
, ez igazából olyasmi, mint egy szkriptnyelv, ami szabványos CSS-re "fordul", megfelelő előfeldolgozóval.Amúgy közben itt találtam egy nagyon gyors összehasonlításra (LESS vs. SASS vs. Stylus) elég jó diasort: http://www.slideshare.net/presidento/css-elfeldolgozk.
Kissé hosszabban:
http://net.tutsplus.com/tutorials/html-css-techniques/sass-vs-less-vs-stylus-a-preprocessor-shootout/ -
#13203
Sk8erPeter
nagyúr
tildy
#13196
Sk8erPeter
nagyúr
Szarul fogalmaztam meg azt a részt, így utólag elolvasva. A generálásnál igazából template-ezést akartam írni, valamint azt, hogy előre megírt sablonokat, kereteket, jól bevált CSS reset fájlokat, a grides megvalósítást elősegítő SASS-kódrészleteket szoktak sokszor felhasználni, és hasonlók. Csak már nem volt kedvem jobban kifejteni, és a végét összecsaptam.
-
#13202
Sk8erPeter
nagyúr
Peter Kiss
#13200
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13200
üzenetére
"mint a Notepad vagy a Netbeans"
Heh? Ezt most ugye csak poénnak szántad? -
#13201
Sk8erPeter
nagyúr
Speeedfire
#13197
Sk8erPeter
nagyúr
válasz
Speeedfire
#13197
üzenetére
DeltaPower leírta, miről szól.
Ez nem osztott tárhelyes téma. Lokális környezetben viszont nagyon jól hasznát tudod venni, megírod a SASS-fájlt, legeneráltatod ebből a CSS-kimenetet (figyelteted a változásokat az adott könyvtárban, és fájlmentéskor automatikusan legenerálódik a CSS-fájl belőle, majd frissíthetsz is a böngésződben), majd a végeredményt feltöltheted (a generált CSS-fájlokat, persze érdemes a *.scss fájlokat is feltöltve is megtartani). Gyorsítja a munkádat a CSS-ben pöcsölés helyett. Mindenképp érdemes kipróbálni, újrafelhasználható kódokat tudsz vele írni, egymásba ágyazott tulajdonságaid lehetnek, használhatsz változókat a kódodban, akár matematikai kifejezéseket lehet kiértékeltetni vele a kódodban, feltételvizsgálatokat használhatsz, ciklusokat írhatsz vele, stb., szóval rengeteg olyan lehetőség nyílik meg így, amire egyébként CSS-ben nincs lehetőséged, kényelmessé teszi a melót, tényleg fasza. Ha szintaktikai hibát követtél el, akkor a mentéskor, a konzolon fog általában látszani a para (vagy ha van hozzá jó progid, pl. beépülő egy IDE-ben, még jobb). Kukkantsd meg ezt, itt van egy csomó kódrészlet, elsőre nem minden triviális, de ki kell próbálni, meg utána kell olvasni, és akkor nagyjából megvilágosodsz. Lehet használni a szintaktikáját amúgy a jsFiddle-ön is, ha a Languages-nél kiválasztod az SCSS-t, szóval akár ott is próbálkozhatsz, ha most localhoston nincs kedved. -
#13195
Sk8erPeter
nagyúr
#36268800
#13193
Sk8erPeter
nagyúr
válasz
#36268800
#13193
üzenetére
Soakhoz csatlakozva ez innentől már erősen OFF topic, nem annyira PHP-s kérdés, hacsak még nem a szerveroldali kimenetgenerálásról, template-ezésről van szó.
De hogy választ is írjak:
A táblázatokat jogosan nem szokás ajánlgatni, mert macerás, kisebb rugalmasságot kínál legfőképp olyan esetben, amikor az oldal tele van ilyen-olyan lebegő-úszkáló elemekkel, blokkokkal; az egymásba ágyazott táblázatok kódja ráadásul gusztustalan, plusz a böngészőre felesleges többletrenderelési feladatokat ró. Erre az ember leginkább akkor jön rá, amikor már megpróbálkozott mindkét módszerrel, és látta, hogy összességében tényleg nem véletlenül ajánlgatják a dives megoldást, nem puszta hype-olásból. Ha megnézed, manapság a népszerű oldalak nem táblázatos felépítésben készülnek, nem véletlenül; ergo ez jobban bevált. (Nyilván nagyon sokan még mindig megrögzöttségből azt mondják, hogy márpedig a table is pontosan ugyanolyan jó, és hülye az, aki az új divatot nyomatja - nem kell rájuk hallgatni. Valószínűleg nem kellett még szopniuk undorító egymásba ágyazott táblázatokkal. Tényleg nem erre találták ki. Ettől függetlenül nagyon sokan sajnos túlzásokba esnek, és még a ténylegesen táblázattal megoldandó feladatokra is képesek diveket alkalmazni, és aztán CSS-sel ráerőltetni a display:table, display:table-row, display:table-cell, stb. kényszermegoldásokat, ami meg már megint nagyon gány. A layout tehát ne táblázat legyen, viszont ha neked tényleg egy táblázat kell a tartalmi részre (pl. adatok rendezett megjelenítésére), akkor az maradjon is táblázat.)
Jól gondoltad, azt sem két perc megtanulni, a sitebuild igazából külön "szakma". A sitebuilderek sokszor grides, pl. SASS-sal támogatott megoldásokat is igénybe vesznek a munkájuk gyorsítása érdekében (pl. Zen Grids, de kismillió példa van még). A layoutot valóban generálni szokás, de erre saját motort nem hiszem, hogy kezdőként megérné írnod. Max. ha gyakorlásnak szánod. -
#13187
Sk8erPeter
nagyúr
Speeedfire
#13186
Sk8erPeter
nagyúr
válasz
Speeedfire
#13186
üzenetére
Végül is egy felhasználónak lehet külön állandó lakcíme vagy levelezési címe, és egy szállítási címe...
Semmi gond nincs abból, ha a kettő szinkronban van. A cím pont, hogy elég ritkán változik. Szerintem nem történik semmi tragédia, ha itt ennél duplikáció van.
Hogy nálad nincs country, az pedig könnyen pótolható. Legfeljebb mindegyiknél "hu" lesz a kód, aztán annyi.Amúgy ezt írják:
"Note that this Module does NOT handle User/Admin authentification. You have to do this by yourself, either by CAuthManager, CDbManager, the yii-user-management or the srbac Module. Instructions on how to integrate this Module with the Yii User Management Module will be available soon, it is already prepared"De amúgy biztos van Yii-hez más webshopmodul is, ezt amúgy is fikázzák páran a kommentekben, amennyit láttam, hogy gányolások vannak benne, megpróbálkozhatnál esetleg egy másikkal is, nehéz elképzelni, hogy ne lenne valami bevált webshop extension Yii-hez is, hátha van olyan, aminél normálisan leírják a felhasználók adatainak lazán csatolt kezelését.
-
#13178
Sk8erPeter
nagyúr
Speeedfire
#13176
Sk8erPeter
nagyúr
válasz
Speeedfire
#13176
üzenetére
Migrálni a saját meglévő tábláid adatait az új táblákba, a kritériumoknak megfelelően, úgy, hogy az új webshopba megfelelően bekerüljenek a termékek, most így konkrétumok nélkül csak általánosságokban lehet tanácsot adni.
Ha van a migrálásra/importálásra valami jóféle, rugalmas "keretrendszer" (mint a Drupalos Migrate modul), akkor az a legjobb. De nézz utána, van-e valami "híd" a két rendszer összehozására. Pl. Drupal esetén volt a Drupal saját táblái és a Gallery2 összehozása esetén, tudtommal ott kicsit gányolósan úgy működött, hogy minden felhasználói adaton történő változás mentődött a másik táblában is, ez mondjuk nem a legjobb megoldás, nem biztos, hogy egy hiba esetén szinkronban lesz a két adat. Szóval a legjobb talán az lenne, ha azonos felhasználói adatbázisban dolgozna a kettő.Melyik webshop ez?
-
#13166
Sk8erPeter
nagyúr
Dave-11
#13164
Sk8erPeter
nagyúr
válasz
Dave-11
#13164
üzenetére
Ne viccelj már... csak gondold végig, mi mindent kell tudnia egy webshopnak. A manapság népszerű webshopokat is évekig fejlesztették, gondolj csak bele: biztonsági rések, plusz szolgáltatások, fizetési lehetőségek, AJAX-osítás, képfeltöltés, rendes kategorizálás, menürendszer (utóbbi kettő fastruktúrában), rendes admin-felület, jogosultságok, és még nagyjából egy órán át sorolhatnám.
Vannak különálló webshopmotorok, és vannak CMS-ekbe (Drupal, WordPress, stb.) beépülő webshopmodulok/pluginek is, igen nagy kódbázissal.
Könnyű végiggondolni, hogy egyedül egyáltalán nem megtérülő vállalkozás fejleszteni saját webshopmotort, de általában csapatban sem.
De egy új webshop kezelésének megtanulása is sok időt igényel, ha nem csak alapfeladatokról van szó. -
#13144
Sk8erPeter
nagyúr
fordfairlane
#13138
Sk8erPeter
nagyúr
válasz
fordfairlane
#13138
üzenetére
Igen, ebben igazad van. Habár kérdés, hogy valósítja meg valaki, hol keletkezzen a fatális hiba, vagy akár egy exception mondjuk itt, akkor, ha a fájl nem létezik, vagy akkor, amikor példányosítani akarja valaki az osztályt.
-
#13137
Sk8erPeter
nagyúr
fordfairlane
#13135
Sk8erPeter
nagyúr
válasz
fordfairlane
#13135
üzenetére
Gondolom csak szemléltetés akart lenni, de sztem nem árthat egy
if(file_exists('classes/' . $class . '.class.php')){
// ...
}
ellenőrzés is előtte, végül is a file_exists() relatíve gyors. -
#13125
Sk8erPeter
nagyúr
rt06
#13123
Sk8erPeter
nagyúr
Volt hosszas témázás róla itt a topicban, érdemes lenne átfutnod:
http://prohardver.hu/tema/php_kerdesek_2/keres.php?stext=singleton -
#13116
Sk8erPeter
nagyúr
Speeedfire
#13115
Sk8erPeter
nagyúr
válasz
Speeedfire
#13115
üzenetére
Ebben a topicban úgy látszik, már nem lehet KORRIGÁLNI egyes mondatokat a helyes infók érdekében, mert valaki biztos, hogy magára veszi.
Miért lenne "belekötés" egy egyszerű korrekció? 
-
#13114
Sk8erPeter
nagyúr
Speeedfire
#13110
Sk8erPeter
nagyúr
válasz
Speeedfire
#13110
üzenetére
A jQuery még mindig nem framework, hanem csak egy library...
-
#13097
Sk8erPeter
nagyúr
Speeedfire
#13096
Sk8erPeter
nagyúr
válasz
Speeedfire
#13096
üzenetére
Újraindítottad a webszervert, miután átírtad?
A Default timezone-nál is "Europe/Budapest" kéne, hogy szerepeljen, de nálad az a default UTC, szóval valami tényleg nem okés. -
#13079
Sk8erPeter
nagyúr
Tele von Zsinór
#13078
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#13078
üzenetére
Jó is, hogy jelezted.
Na igen, a placeholderek használata is jóval elegánsabb megoldás. -
#13074
Sk8erPeter
nagyúr
Tele von Zsinór
#13069
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#13069
üzenetére
Értem, ettől függetlenül viszont szerintem érdemes elkerülni az idézőjel használatát tömbindexeléskor, és lehetőleg egyéb esetekben is - természetesen ez pusztán szubjektív megítélés, de én rendkívül olvashatatlannak tartom a stringben "elrejtett" változók használatát a konkatenálás helyett.
Szóval szerintem PHP-ben idézőjel helyett aposztróf. -
#13061
Sk8erPeter
nagyúr
#68216320
#13058
Sk8erPeter
nagyúr
válasz
#68216320
#13058
üzenetére
Jól csináltad, ez localhoston, fejlesztői környezetben nyugodtan maradhat így. Ahogy tildy is mondta, arra viszont figyelj, hogy a notice-ok kijelzését viszont nem szabad úgy hagyni éles környezetben, ott, ahol már külső szemlélők olyan információkat is láthatnának ezáltal, amit nem szabadna (értsd: egy rossz szándékú illetőnek minden plusz információ csak további segítség). Éles környezetben is el kell azonban kapni minden hibát, azokat naplózni, és a felhasználónak csak "felhasználóbarát hibaüzenetet" megmutatni. (Pl. a felhasználó ne tudja, a kód hányadik sorában lett valami elrontva, vagy konkrétan mi volt a hiba.)
-
#13055
Sk8erPeter
nagyúr
#68216320
#13052
Sk8erPeter
nagyúr
válasz
#68216320
#13052
üzenetére
Semennyire nem elfogadott, és nem helyes, mert notice-t kapsz, ha úgy használod.
(#13054) Speeedfire :
úgy is megy, de valamelyest lassabb lehet a változó-behelyettesítések (vizsgálata) miatt.
Szóval tényleg érdemes aposztrófot használni, mondjuk ha változóval kell konkatenálni, úgy is jobb szerintem olvashatóság szempontjából. -
#13009
Sk8erPeter
nagyúr
oleslie
#13004
Sk8erPeter
nagyúr
válasz
oleslie
#13004
üzenetére
Ezt a reakciót most nem egészen értettem, annyira nem nagy elvárás egy osztott tárhelyen sem, hogy legyen cron-futtatási lehetőség, manapság olcsó tárhelyeknél is jellemző, hogy be lehet állítani időzítetten lefuttatott scriptet pl. egy cPaneles felületen, pár kattintással.
(#12994) Soak :
jah, most esett le, hogy ezt mire mondtad, hogy 1 perc a legkisebb egység, OK, sorry, félreértettelek, igazából csak a lényeget néztem be, hogy cucka 30 másodpercet írt, nem pedig percet, pedig még idéztem is.
Lehetséges megoldás az egyszerűek közül. -
#13008
Sk8erPeter
nagyúr
cucka
#13001
Sk8erPeter
nagyúr
Először is: nyugi, tudtommal egyelőre csak a lehetőségekről és miértekről beszélgetünk, és nem én akarom így vagy úgy megoldani, mert engem nem érint, hanem visszakérdeztem, hogy támaszd alá picit jobban, amit mondtál, mert érdekelt, de a hsz.-ed végére kissé behergelted magad.
"Először is szögezzük le, hogy alapnak veszem, hogy egy játéknál nem oldal újratöltéssel oldjuk meg a kliensoldali frissítéseket, hanem ajax-al."
Őő, ja, de ez nyilvánvaló, szerintem erről nem is érdemes témázni, mivel evidens.Amit viszont én szögeznék le előre a félreértések elkerülése érdekében, mert fontos, hogy alapvetően én is jobbnak látom a cronos megoldást, valszeg én is azzal csinálnám, ha én lennék a fejlesztője, mivel ütemezett feladatra használjunk ütemezőt, végül is pont arra való. Tehát én nem a cron ellen beszélek, hanem érdekes témának láttam megvizsgálni a másik oldal lehetőségeit is, ha már felvetették a többiek, hogy meg lehetne oldani anélkül is, tehát azt is érdemes megbeszélni, hogy mi történne abban az esetben, ha NEM cronnal történne a dolog. Én pedig csak azokra a dolgokra reagálok/kérdezek rá, amik esetleg elsőre teljesen egzakt fogalmazás híján (számomra) kérdésesek lehetnek (vagy legalábbis engem érdekelnek). Oké?
Úghogy az "ezt az egész baromságot pusztán azért, mert valamilyen hülye okból kifolyólag nem vagy hajlandó arra, hogy az ütemezett feladatot a pontosan erre a célra kitalált feladatütemezővel futtasd" (kicsit behergelődött) mondatot nem vettem magamra, mert nem rám vonatkozik.Lock-okra:
Igazából direkt előre kihangsúlyoztam, hogy elsősorban magára az ellenőrzésre kérdeztem rá, nem pedig az írási műveletekkel kapcsolatos aggályaidra, mert mint említettem vala, az még érthető is, de nekem úgy tűnt, hogy a lock-ok emlegetése kapcsán Te rátapadtál kőkeményen az írás-témára. De aztán utána meg simán az ellenőrzés-téma kapcsán is azt emlegetted, hogy a többiek várni fognak az erőforrásokra. Most szűkítsük le a kört simán arra, hogy kiolvasod az értéket ÉS az utsó módosítás dátumát, majd utóbbinál még egy összehasonlítást is végzel az aktuális dátummal, megnézed, amúgy mi a pálya, kéne-e frissíteni. Akkor itt még ne vegyük azt, hogy mi van, ha igen (akkor növelni kéne) - ebben az esetben ugye Te sem arra gondoltál, hogy írási művelet híján drasztikusan csökken a szerver teljesítménye nagy felhasználószám esetén?Egyébként az ütemezett scriptben feltételezem, nem árt ellenőrizni, hogy a júzer épp online-e, mert ha offline, akkor gondolom nem kéne növelni a mannáját, szóval akkor a böngészőből való kilépés esetén küldeni kéne egy requestet a szerver felé, hogy na cső, akkor távoztam, azt meg beírni adatbázisba, hogy most már nincs szükség buzerálásra az adott júzernél.
Mondjuk jobb lenne ismerni jobban egy ilyen játék működését, én ilyeneket nem szoktam tolni (kinek van ilyenre ideje?), úgy kicsit könnyebb lenne beszélni az elméleti lehetőségekről.===
(#12995) Tele von Zsinór :
na ja, ez az ütemezős dolog jó példa, alapvetően ez így tök jogos. De tényleg jobban kéne ismerni egy ilyen játék működési elvét, mert konkrét implementációt nem tudok, csak sejtéseim vannak róla. -
#12993
Sk8erPeter
nagyúr
cucka
#12989
Sk8erPeter
nagyúr
"Továbbá biztosítani kell, hogy ez esetben óránként (vagy akármikor) csak és kizárólag egyszer fusson le, ezt nem teljesen triviális jól megcsinálni."
Ezt nem igazán értettem. Miért, mi benne a bonyolult?"fölösleges minden egyes olvasási műveletnél lefuttatni az ellenőrzést, hogy kell-e frissíteni, tekintve, hogy az olvasások száma várhatóan sokkal nagyobb, mint az írásoké. Plusz ez web, itt több szálon történik a dolog, tehát lock-okat is kell alkalmazni, szóval tovább rontod az alkalmazásod teljesítményét."
Az írásra vonatkozó rész még okés, de maga az ellenőrzés miért lenne olyan nagy gond? Eleve az aktuális manna értékét ki kell olvasni, akkor még az utolsó írási művelet dátumát kiolvasni, majd aktuális dátummal összevetni minden, csak nem egy igazán erőforrás-igényes művelet. (Jó, ha nagyon akarom, ilyen alapon az aktuális dátum és idő lekérdezése miatt szükséges OS-szintű rendszerhívás is erőforrás-igényes.)
Hangsúlyozom, itt az ellenőrzéssel kapcsolatos aggályaidra reagáltam elsősorban, nem az írási műveletekre. Bár hozzáteszem, az ilyen szinten egyszerű félóránkénti (!) írás csak elég durva felhasználószámnál jelenthet szerintem gondot, szóval picit úgy érzem, ebben az esetben túl van parázva a dolog. Ha ötpercenkénti írási műveletekről lenne szó, akkor jogos.(#12990) Soak :
hogy a másik oldalhoz is szóljak
"> A cron pedig simán futhat akár 30 másodpercenként is.
Alapból nem, de nyilván megoldható."
Ezt hogy érted? Az adott script futtatása olyan időközönként fut, ahogy konfigurálod... Itt mi az, hogy "alapból"?"> Továbbá a cron az maga egy daemon, ami pont arra van, hogy megoldja ezt a problémát, minek erre fejleszteni egy másik daemont?
Fejleszteni nem kell, mert már megtették mások, ezért nem nehezebb semmivel mint egy cron job-ot beállítani. Ha már feltételezem a LAMP környezetet akkor miért ne? Sokkal jobban illeszthető a környezetbe és egyszerűbben is konfigolható. ( a futás gyakoriságától kezdve a kiépitett logolásig) ."
Másik daemont fejleszteni? Nem világos. Mire? Az időzített feladatok futtatására? Vagy nem vágom. -
#12979
Sk8erPeter
nagyúr
csepelball
#12974
Sk8erPeter
nagyúr
válasz
csepelball
#12974
üzenetére
Ez Drupallal egyszerűen* összekattintgatható, még scriptelned sem kell hozzá.
Létrehozol egy "Szolgáltatók" nevű content type-ot, a szálakba rendezett kommentelés innentől eleve biztosított, hozzáadsz tetszőleges mennyiségű űrlapmezőt (szolgáltatások listájához lehet, hogy taxonomy-t kell majd használnod, megvalósítástól függően; árak felviteléhez is megvalósítástól függő a megoldás), értékeléshez pedig a Fivestarnál nem nagyon ismerek egyszerűbben összeklattyogtatható értékelésre szolgáló modult.
Vagy biztos WordPress-szel is megoldható, azt nem ismerem.
De nem két perc, arra számíts. Ajánlott szakirodalom magyarul: http://nagygusztav.hu/drupal-7-alapismeretek.Szerk.:
*: kezdetben semelyik CMS nem egyszerű, SŐT. Nagyon nehéz az elején. De megéri legalább egyszer ráérezni az ízére, mert egész komplex oldalakat is akár "gyorsan" össze lehet hozni vele azután. Persze egy CMS mindig sokkal erőforrás-igényesebb lesz, mint egy erős, igényesen kódolt és használt framework. -
#12978
Sk8erPeter
nagyúr
Speeedfire
#12972
Sk8erPeter
nagyúr
válasz
Speeedfire
#12972
üzenetére
Konkrétabban?
-
#12965
Sk8erPeter
nagyúr
RootRulez
#12961
Sk8erPeter
nagyúr
válasz
RootRulez
#12961
üzenetére
Ne azt a leírást használd, ennél ezerszer korszerűbb megoldások is vannak már nagyon régóta. Ráadásul elavult kódot használ, és valszeg nem annyira könnyen konfigurálható, mint pl. ez: http://jqueryui.com/dialog/#modal. De ahogy DeltaPower is mondta, ez OFF topic, JavaScript topicba tartozna inkább. Aztán plusz tipp, hogy ne idegesítsd a felhasználóidat az össze-vissza ugráló popupokkal, mert szidni fogják az egyik hozzátartozódat.
-
#12959
Sk8erPeter
nagyúr
Hege1234
#12956
-
#12955
Sk8erPeter
nagyúr
futár
#12950
Sk8erPeter
nagyúr
Hát pedig tévedsz, DeltaPower jól mondta, nem kell a v3-hoz API-kulcs. Itt röviden összefoglalják: [link]. Lényeg: 2-eshez még kötelező volt, 3-asnál NEM az.
De ha nem elég bizonyíték, itt van egy nagyon egyszerű példa, mindenféle API-kulcs használata nélkül: http://jsfiddle.net/aknYP/4/
itt találsz még párat...De hogy mire lehet jó az API-kulcs használata:
https://developers.google.com/maps/documentation/javascript/tutorial?hl=hu#api_key"Using an API key enables you to monitor your application's Maps API usage, and ensures that Google can contact you about your application if necessary. If your application's Maps API usage exceeds the Usage Limits, you must load the Maps API using an API key in order to purchase additional quota.
* Google Maps API for Business developers must not include a key in their requests. Please refer to Loading the Google Maps JavaScript API for Business-specific instructions.
[...]
By default, a key can be used on any site. We strongly recommend that you restrict the use of your key to domains that you administer, to prevent use on unauthorized sites. You can specify which domains are allowed to use your API key by clicking the Edit allowed referrers... link for your key."===
(#12949) futár :
"Ez egy idióta dolog"
Ezek fényében nem túl hiteles, hogy engem kritizáltál amiatt, hogy gagyinak/fosnak neveztem az általad korábban emlegetett kódot, amely iframe-használatot erőltetett (bár akkor még nem is láttunk kódot, csak ahogy bemutattad, az alapján nem volt túl meggyőző), itt viszont egy annál ezerszer komplexebb és alapvetően jól működő dologról van szó...
Azért kell új kulcsot beszerezni a 2-es változathoz is, mert történtek változások a Google-alkalmazások körül, azok nyilvántartásában, lett ez a konzolos dolog, amit be is linkeltél, a változtatásokhoz való adaptálás érdekében meg frissíteni kell a kulcsot.Egy oldalon én is API-kulcs használata nélkül jelenítem meg a térképeket a v3-as API segítségével (pontosabban Drupalban egy modul kódja jeleníti meg, de beregisztrált API-kulcs nélkül).
-
#12939
Sk8erPeter
nagyúr
futár
#12931
Sk8erPeter
nagyúr
Itt senki nem civakodott, és senki nem ordította le más fejét, senki nem lett sárba tiporva, valószínűleg Te vagy egy kissé túlérzékeny, ha ezt így értékelted. Szerencsére DanielK éretten és korrekt módon válaszolt, nem sértődött meg, hanem érdemben reagált, szóval vele lehet kommunikálni akkor is, ha kritikát kapott.
Szerintem semmi gond nincs azzal, ha itt kritizáljuk egymás kódját, arra való a fórum, és nem vagyunk porcelánból - hidd el, az én kódjaimat, javaslataimat is kritizálták már bőven, és ha volt benne érdemi információ, amiből megtudom, hogy mit rontottam el, mit kellene másként, akkor összességében még örültem is neki, mert abból mindenki tanul.
Amúgy ha korábban belinkelted volna a kapcsolatfelvételre szolgáló kódot, akkor hozzá lehetett volna szólni érdemben is a kódhoz. Egyébként csak felhívnám a figyelmedet, hogy a Te munkádat sehol nem kritizáltam, így nem volt értelme magadat védelmezni, bizonyítgatni, hogy van olyan terület, amiben Te vagy a jobb, elhiszem, de senki nem mondta, hogy ez ne lenne így. Azon a területen meg Te kritizálhatnád az én tanácsaimat, és jól is lenne ez így."Kicsitt régebb óta vagyok itt mint te"
Ezzel nem tudom, mire gondoltál, arra, hogy Te másfél évvel korábban regisztráltál? De mindegy is, felőlem valaki tegnap óta is lehet PH-tag, ha érdemi kritikákat fogalmaz meg a fórumon, akkor teljesen irreleváns, hogy mióta van itt... -
#12937
Sk8erPeter
nagyúr
DanielK
#12930
Sk8erPeter
nagyúr
válasz
DanielK
#12930
üzenetére
Nincs mit, örülök, hogy ilyen korrekten reagáltál, és nem vetted magadra, és Te értetted, hogy nem a sértés, hanem a kiigazítás volt a célom.
(Örülök, hogy végre van egy ember, aki nem sértődik meg azonnal izomból, hanem érti a lényeget, pedig ez ritka. )Amúgy ránézve a futár által belinkelt kódra, végül is annyira nem katasztrófa, bár nem egészen értem, minek írt egy wrappert tulajdonképpen a PHPMailer osztály köré, amikor az alapból is tartalmaz csatolmány-hozzáadást, meg picit fura getterei, setterei vannak, stb., de valószínűleg annak fejlesztője azért ajánlotta az iframe-es megoldást, hogy egy az egyben bedobható legyen egy oldalra, és ne kelljen elmagyarázni, hogyan lehet megfelelően használni a levélküldő osztályt.
De így már legalább belelátunk.
Ja, a formnál az is teljesen jó, amit Te alkalmaztál, hogy kiírtad fölé a köszönőszöveget, aztán alatta megjelenik attól még a form. -
#12929
Sk8erPeter
nagyúr
futár
#12890
-
#12928
Sk8erPeter
nagyúr
DanielK
#12894
Sk8erPeter
nagyúr
válasz
DanielK
#12894
üzenetére
Azért nem jó megoldás, mert undorító. Ez a "célt elértem vele, úgy, hogy a kódomtól egy normális programozó üvöltve hányna", nem túl jó hozzáállás a programozásnál.
(#12901) DanielK :
"javascripttel újratöltöd az oldalt vagy ajaxxal a divet."
Ez viccnek is rossz...(#12902) DanielK :
"de miért akarod eltüntetni? ez nem szokás, főleg, ha új üzenetet akar küldeni neked. nem felhasználóbarát..."
Bocs, de ezt is muszáj kommentálnia valakinek, és most megint én leszek az a szemét k×csög.
Egy kapcsolatfelvételi űrlapnál miért az az alapvetés, hogy az első levél elküldése után hadd küldjön egyből egy másikat? Miért ne lenne "felhasználóbarát" megoldás megköszönni, hogy elküldte a formot, de most már hagyjon békén? Ez a "felhasználóbarát" szó itt nem túl helytálló amúgy sem. Igazából mindkét megoldásra lehet magyarázatot találni, de az nem egy rossz megoldás, hogy megköszöni a form elküldését, de nem jeleníti meg még egyszer. Szóval kicsit túlságosan rápörögtél erre a témára, feleslegesen (vagy ötször visszakérdeztél, miért tünteti el ).Viszont legalább abban egyetértünk, hogy a kliensoldali ellenőrzés semmit nem ér, az csak a szervert kíméli a felesleges formküldözgetéstől, meg a júzert a felesleges hosszabb várakozástól, valaki kikapcsolja a JS-t, és vége is a nagy mágikus ellenőrzésnek kliensoldalon.
Mivel írtad, hogy kezdő vagy a dologban, ezért kérlek, ne vedd sértésnek, amiket írtam, vagy ha erősen fogalmaztam, de gondoltam nem árt némi visszajelzés, hogy ne csak a téves infó maradjon meg.
(#12925) DanielK:
"Mondjuk én jobb szeretem a mézesbödön (honeypot) ellenőrzésket (kevesebb hely is kell neki). Persze az kevésbé hatásos, mint a racaptcha, de felhasználóbarátabb."
Ez így nem feltétlenül igaz, hogy kevésbé hatásos. Attól függ, hogy van megvalósítva. Pl. a Drupal Honeypot modulját úgy oldották meg, hogy elrejt egy tök átlagos névvel ellátott formmezőt (pl. "website" vagy hasonló), ami miatt egy spamrobot azt hiszi, hogy az egy kitöltendő mező, ezért mohón ki is tölti, viszont szerveroldali ellenőrzésnél ez eleve hibának minősül, hogy a mező ki lett töltve; aztán a második fokozat az, hogy még egy timestamp-alapú ellenőrzés is van, meghatározod, hogy pl. egy adott űrlapot 5 másodpercen belül nem szabad elküldeni, ha ezen az időtartamon belül küldi el valaki, akkor az hibának minősül, tehát nem fogadod el a küldött adatokat (nem mented adatbázisba, nem küldesz emailt, stb.).
A drupal.org-on (a hivatalos Drupal-oldal) erős tesztelésnek vetették alá ezt a modult, CAPTCHA-megoldások nélkül, és bebizonyosodott, hogy igen hatékony előszűrő, ezért ezt be is élesítették az oldalon, mint állandó megoldást. -
#12855
Sk8erPeter
nagyúr
lordjancso
#12854
Sk8erPeter
nagyúr
válasz
lordjancso
#12854
üzenetére
Ja, hát akkor írni kell valami tisztességes reguláris kifejezést, biztos a kommentek között is van pár ilyen példa php.net-en a strip_tags-nél, meg kész megoldások is találhatók rá némi keresés után.
-
#12853
Sk8erPeter
nagyúr
fordfairlane
#12846
Sk8erPeter
nagyúr
válasz
fordfairlane
#12846
üzenetére
Azért ez engem is megdöbbentett, hogy most komolyan arról megy a vita, hogy érdemes megspórolni require használatával sok-sok fájl include-olása esetén is totál irreleváns időt, viszont cserébe belerakni az alkalmazásba egy potenciális hibalehetőséget, amikor ezernyi más dolog van, amit sokkal-sokkal fontosabb optimalizálni, mint például épp az általatok is említett adatbázis-indexelés, azzal való kommunikáció, a query-k minősége (!), az I/O műveletek sebessége (akkor már mondjuk sokkal érdekesebb az is, hogy SSD-n fut-e a szerver, és így tovább).
-
#12852
Sk8erPeter
nagyúr
lordjancso
#12827
Sk8erPeter
nagyúr
válasz
lordjancso
#12827
üzenetére
Nem fog lefutni, mivel direkt azzal kezdtem, hogy "ha előtte kiszedted a HTML-tageket", pl. strip_tags()-zel...
-
#12826
Sk8erPeter
nagyúr
DeltaPower
#12817
Sk8erPeter
nagyúr
válasz
DeltaPower
#12817
üzenetére
"aposztróf és idézőjel nélkül nem fognak neked működőképes javascript kódot írni
fromCharCode"
De ez mitől fog lefutni, ha előtte kiszedted a HTML-tageket, különös tekintettel a <script> tagekre? -
#12791
Sk8erPeter
nagyúr
Ndruu
#12790
Sk8erPeter
nagyúr
Drupalnál is "benne van a kódban" a felhasználónév-jelszó páros, egy settings.php nevű fájlban, és ez fizikailag nincs is "elrejtve", rooton kívülre helyezve (sites/default/settings.php), egy $databases tömbben vannak benne az adatok. Érdemes külön fájlra rakni a felhasználónév/jelszó párosokat, de ettől önmagában még nem lesz "biztonságos" az alkalmazásod; a kódban valahol úgyis include-olni kell (ld. Drupal is include-olja; vagy beolvasni a fájl tartalmát, majd bezárni, stb.). Amit linkeltél, ott arról beszél, hogy külön konfigurációs fájlba érdemes rakni ezt az adatot (Drupalnál a settings.php is az), aztán megoldani a fájl megfelelő védelmét a verziókövető rendszernél (hogy ne legyen nyoma a jelszavaknak), meg beállítani a konfigurációs fájlon a megfelelő jogosultságokat (pl.).
De ettől még az alkalmazás ezer helyen tartalmazhat biztonsági réseket, tehát mindenhol figyelni kell, hogy ne kerüljenek ki szenzitív adatok, figyelni kell az SQL Injectionre és még ezer más dologra is. Ennyi alapján csak általánosságokat lehet mondani, mint az előbb leírtak is. -
#12754
Sk8erPeter
nagyúr
Siriusb
#12751
Sk8erPeter
nagyúr
válasz
Siriusb
#12751
üzenetére
[A-Za-z0-9-]+
Ennél a reguláris kifejezésnél egyébként érdemes tisztában lenni azzal, hogy ez ténylegesen csak A-Z-ig terjedő nagybetűkre, a-z-ig terjedő kisbetűkre, valamint a 0 és 9 közt lévő számokra illeszkedik, plusz a kötőjelre, pedig egy URL más karaktereket is tartalmazhat (például alsóvonás (_), szóköz, pont, vessző, plusz karakter, stb.).
Szóval ez csak akkor működik jól, ha van valamiféle transliteration az URL aliasokra, amely csak ezekre a karakterekre korlátozza a lehetséges aliasokat (az egyebeket helyettesíti). -
#12725
Sk8erPeter
nagyúr
alitak
#12724
Sk8erPeter
nagyúr
válasz
alitak
#12724
üzenetére
Most ez kábé olyan hibaleírás volt, mint a "nem működik, mi lehet a gond?" Azt sem írtad, milyen hibaüzenetet kapsz a külső adatbázishoz kapcsolódásnál. Ennyi alapján nem lehet segíteni.
Egyébként PDO-val is lehet csatlakozni a Firebird/Interbase-hez:
http://php.net/manual/en/ref.pdo-firebird.php
amivel amúgy is jóval igényesebb lenne. -
#12704
Sk8erPeter
nagyúr
cucka
#12703
Sk8erPeter
nagyúr
Ja, így már érthető, de nem azt mondtad korábban, hogy HA NULL AZ ÉRTÉKE, mert akkor egyből érthető lett volna:
http://php.net/manual/en/function.isset.phpisset — Determine if a variable is set and is not NULL
már eleve ez van a doksiban.
Szerintem is totál degenerált dolog ez ilyen formában, mivel rohadtul félrevezető...Viszont ez működik:
$a = array(0=>null);
var_dump( array_key_exists(0, $a) ); // --> TRUE!visszatérve arra, amit írtál:
var_dump(in_array('s', array_keys(get_defined_vars()))); //-> TRUE
na ne már... ezt minden validálásnál így csinálod? Az összes, adott scope-ban elérhető változót lekéred egy tömbbe, és végigszaladgálsz rajtuk, csak hogy megtudd, egyetlen adott tömb egy adott kulcsa létezik-e? Akkor már nem értelmesebb kissé a fentebb említett array_key_exists()? Kicsit kevésbé tűnik erőforrás-igényesnek, eleve kevesebb adatból kell kibogozni a kérdésünkre a választ. -
#12702
Sk8erPeter
nagyúr
#68216320
#12696
Sk8erPeter
nagyúr
válasz
#68216320
#12696
üzenetére
"php.ini-ben lehet beállítani valahol alapértelmezettként az error_reporting-et?"
Jaja:
http://www.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting"Illetve emlitetted az if( ! empty( $_POST['valami'] ) )-t. Inkább ez vagy az isset() ?"
itt tudod megnézni bővebben:
http://php.net/manual/en/function.empty.php
mondjuk a lényege már ki lett vesézve. A kettő nem ekvivalens, csak arra céloztam, hogy az empty()-ben eleve "benne van" egy isset()-vizsgálat is, tehát ez nem fog notice-t dobni, ez is nyelvi elem (nem függvény):
"No warning is generated if the variable does not exist. That means empty() is essentially the concise equivalent to !isset($var) || $var == false."
Tehát ha a !isset($_POST['valami']) igaz, akkor az is igaz, hogy empty($_POST['valami']). De az empty() ezentúl még lehet akkor is igaz, ha az adott változó érték nélkül lett deklarálva, vagy annak értéke egyenlő a következők valamelyikével: "", 0, 0.0, "0", NULL, FALSE, array(). Pont ezért lett korábban az a végkövetkeztetés, hogy ha általános validációt szeretnél, akkor arra nem feltétlenül alkalmas az empty(). De ha az előbbi értékek közül egyik sem felel meg, akkor kényelmes eszköz lehet, de ennél is igaz az, hogy ettől még nem biztos, hogy jó: a kódod nem mondja meg az azt olvasó számára egyértelműen, hogy milyen értékeket vársz el, bár ettől függetlenül valamelyest beszédes is. Csak azt megzavarhatja, aki nincs tisztában az előbb írtakkal, hogy ha mondjuk egy felhasználó éppen 0-t ír egy adott űrlapmezőbe, akkor is igazzal fog visszatérni az empty(), és ez nem minden esetben jön jól.=======================
(#12699) biker :
"de a ===-nek is van szerintem hátránya: "0" === 0 FALSE szerintem, mert az első sztring a másik num
nem?"
De igen, ahogy írtad, a "0" === 0 az hamis, mivel a három egyenlőségjellel típusvizsgálatot is végzel, és ez nagyon jól is van így. Szóval ez nem hátrány.
Ha már ennyire belementünk: van például az intval() függvény is:
http://php.net/manual/en/function.intval.php
na ez is teljesen alkalmatlan vizsgálatra, mert az intval("asd") eredménye például 0 lesz, ami nyilvánvalóan nem jó. Tehát PHP-ben elég kacifántos lehet adott esetben egy validáció. -
#12701
Sk8erPeter
nagyúr
cucka
#12697
Sk8erPeter
nagyúr
"Tehát az isset true-val fog visszatérni bármilyen változóra, ami nem létezik"
Hogy micsoda?
Ha van egy ilyened:
$valami;
az isset($valami) FALSE-szal fog visszatérni;
A $valami = 1; után már TRUE-val.
Hogy térne vissza true-val? Vagy csak elírtad?"Jól látható, hogy a neve ellenére az isset()-nek valójában semmi köze ahhoz, hogy egy változó (vagy tömb index) definiált-e vagy sem."
Az előbbi azt igazolja, hogy de igen, van köze hozzá (PHP 5.3.8-ban legalábbis biztosan, Te nem tudom, hányas változatról beszélsz, hol volt ez valaha érvényes (4-esnél simán lehet, ezt nem tudom), én az általad említett dologgal nem találkoztam még).
Ahogy arra is false-t ad vissza, ha a $nincsilyen változód nincs beállítva sehol hogy, és nyomatsz egy olyat, hogy isset($nincsilyen->tokmindegy), ahogy ugyanez igaz a $nincsilyen['tokmindegy'] ellenőrzésére is.
Ez most akkor pont annak ellenkezője, amit írtál, szóval nem értem az állításodat."(Ennek eldöntésére a get_defined_vars() való)."
Hmm?
Hogy jön ide a get_defined_vars(), amikor csak egyetlen változó meglétét szeretnéd ellenőrizni? Ez a függvény egy komplett tömböt ad vissza az adott scope-ban elérhető lokális/globális/szerver/környezeti változókról, tehát tartalmazni fogja a $GLOBALS tömb dolgait, a $_SERVER dolgait, és így tovább... ezután ezen a tömbön fogsz kiadni egy isset()-et, és akkor ugyanott vagy, vagy ezt most hogy értetted?
Nem az array_key_exists() vagy property_exists() és társai valamelyikére gondoltál?"A gyarkolatban ebből az következik, hogy az empty() teljesen alkalmatlan bármire, visszatérési értékének semmi köze ahhoz, hogy "üres"-e a változó értéke vagy sem. Javaslom, soha, semmilyen körülmények között ne használd az empty()-t, ez egész egyszerűen egy rosszul kitalált nyelvi elem a php-ban."
Mondjuk akkor még lehet értelme, ha a "", 0, 0.0, "0", NULL, FALSE, array() és értékadás nélkül deklarált $var változók közül egyik sem felel meg neked, és megköveteled, hogy mindegyiktől különbözzön mondjuk adott mező
Ha például egy adott mezőt kötelező kitölteni, vagy mondjuk 0-nál (0.0-nál) nagyobb szám megadására van szükség, akkor végül is ellátja a feladatát, de ettől függetlenül azzal egyetértek, hogy általános validációra nyilván alkalmatlan. -
#12695
Sk8erPeter
nagyúr
#68216320
#12694
Sk8erPeter
nagyúr
válasz
#68216320
#12694
üzenetére
"miért nem jó, ha közvetlen if( $_POST[valami] ) módon vizsgálom egy űrlapmező kitöltését"
Azért nem jó, mert ha nincs beállítva a $_POST tömbben a "valami" kulcs, akkor a szigorúbb hibajelzés (pl. error_reporting(E_ALL | E_STRICT); ) bekapcsolása esetén kapsz egy notice-t:
"Notice: Undefined index: valami in ...../FAJLOD.php on line XYZ"
azért fontos ezekre figyelni, mert a későbbiekben problémád származhat belőlük, ezért érdemes eleve úgy tervezni a kódot, hogy legyen alternatíva, ha már eleve a kulcs sincs beállítva. Tehát először ellenőrzöd, megvan-e egyáltalán a kulcs, ha nincs, akkor nem is foglalkozol tovább a potenciális értékeivel.
Közvetlen "veszélye" a notice-on kívül nincs a dolognak, inkább csak rejtett hibaforrás lehet rosszabb esetben, ezért érdemes rá eleve felkészülni: nem sokkal növeli a kódbázis méretét, viszont legalább elkerülsz egy apró hibalehetőséget. -
#12693
Sk8erPeter
nagyúr
#68216320
#12692
Sk8erPeter
nagyúr
válasz
#68216320
#12692
üzenetére
Hogy mi? Szerintem te voltál itt kioktató, azt éreztetted, hogy márpedig te jobban tudod, elmagyaráztad, hogy miért is marhaság, amit én írtam, visszakérdeztél, hogy "dolgoztál már C-vel?", ugyan "miért ne lenne jó?", és leírtad, hogy "azt még gondold végig". Ezután hozzád hasonlóan én is kifejtettem a véleményem arról, amit írtál.
De bántás nem volt benne (cinizmus valóban, de nem a sértés feltett szándékával). De várj, hol volt a hozzászólásodban segítségkérés? Mert én azt nem láttam benne, hanem sajnos csak pont, hogy kioktatást. -
#12691
Sk8erPeter
nagyúr
#68216320
#12690
Sk8erPeter
nagyúr
válasz
#68216320
#12690
üzenetére
Dolgoztam már C-vel, de ez hogy jön ide? Sehogy.
A két nyelv összehasonlításának nincs is igazán értelme. Eleve más az alapvető céljuk. Ezenkívül ha már összevetjük, a C nyelv eleve jóval szigorúbb, mint a PHP, sajnos (szerencsére?) a PHP olyan nyelv, aminek segítségével kezdők is nagyon gyorsan és egész egyszerűen össze tudnak tákolni-gányolni funkcionálisan "működő", de attól még akár hibákkal telerakott kódot is (aztán legfeljebb a hibajelzéseket elnyomják, és meg is van minden oldva...).
Egyébként attól még, mert valami kényelmes, önmagában nem biztos, hogy jó is. Pl. ha a kódodban az a "kérdés", hogy a "pista" egyenlő-e a 0-val (== használata esetén), akkor nem biztos, hogy jó, ha a válasz "igen" (mert egyébként nem egyenlők). Az üres stringre ("") még OK, de így nem, ezzel persze neked nem kell egyetérteni (meg amúgy is, ez van, ezt kell szeretni).
A magyarázatot meg köszi, nem kérem, mert én is ezt magyaráztam itt."Például, ha tudni akarom van-e értéke egy form mezőnek if( $_POST['valami'] ){}"
Hát ez elég rossz példa volt, mert ha így csinálod, akkor rosszul csinálod. Először is nem biztos, hogy be van állítva az adott kulcs a $_POST tömbben az űrlap elküldésekor, elég csak a radio buttonökre vagy a checkboxokra gondolni. Először azt kell ellenőrizni, hogy egyáltalán létezik-e a tömb adott kulcsa (isset($_POST['valami'])), aztán lehet ellenőrizni, nem egyenlő-e egy üres stringgel, ha már az értékét akarod majd vizsgálgatni, de ekkor már lehet azt a módszert is használni, ha nagyon akarod, amit használtál, bár ez így szerintem nem teszi egzakttá, jól olvashatóvá a kódot. Esetleg az isset()-et és az üres stringre való csekkolást lehet egy empty()-vel helyettesíteni ( if( !empty($_POST['valami']) ) { // van bepötyögött érték } ). Persze ha szereted szívatni magadat, kikapcsolhatod a notice-ok kijelzését még a fejlesztés idejére is."Azt még gondold végig, hogy hogyan tudna numerikus 0-t küldeni egy űrlap. Sehogy. Textként megy és neked kellene kiszedni belőle a numerikus értéket, mint ahogy C-ben van. A PHP lazán kiszedi a string elejéről."
Ja, hogy szerinted az egyetlen összehasonlítási alap az lehet, hogy valaminek az értéke űrlapból (a $_POST tömbből) jön....?
És szerinted annak is örülni kell, és sokkal jobb, hogy ha írsz egy olyat, hogy
echo '10xyz'+10;
vagy azt, hogy
echo array_sum(array('10xyz', 10));
akkor mindkét esetben kijön az, hogy 20?
Akkor azt hiszem, te megtaláltad a magad számára tökéletes nyelvet, amiben szabadon lehet gányolni.Ezeket azért "még gondold végig"...
-
#12689
Sk8erPeter
nagyúr
#68216320
#12687
Sk8erPeter
nagyúr
válasz
#68216320
#12687
üzenetére
Nem értem a magyarázatodat, hogy attól még miért lenne "jó" az automatikus konverzió pl. egy összehasonlításnál...
Még csak logikai összefüggés sincs a két dolog között. Pl. begépelte a felhasználód, hogy "pista", te meg szerveroldalon összehasonlítod azzal, hogy 0-e a mező: if("pista" == 0){ // akkor lesz valami, ha 0 az érték, márpedig nem az }. Akkor ez ilyen értelemben miért is "jó"? -
#12623
Sk8erPeter
nagyúr
Soak
#12622
Sk8erPeter
nagyúr
3 egyenlőségjel használata esetén nem fogja kiírni.
Bővebben:
http://php.net/manual/en/language.operators.comparison.php
If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value.
<?php
var_dump(0 == "a"); // 0 == 0 -> true
var_dump("1" == "01"); // 1 == 1 -> true
var_dump("10" == "1e1"); // 10 == 10 -> true
var_dump(100 == "1e2"); // 100 == 100 -> true
switch ("a") {
case 0:
echo "0";
break;
case "a": // never reached because "a" is already matched with 0
echo "a";
break;
} -
#12605
Sk8erPeter
nagyúr
PiXeL90
#12599
Sk8erPeter
nagyúr
válasz
PiXeL90
#12599
üzenetére
Pár tanács:
A functionöket nem egy hatalmas if-be kellene raknod. El kellene kerülnöd a teljesen olvashatatlan kód írását, például az $a, $b, $c, $d, $f, $szv, $sz1 és hasonló, külső olvasó számára teljesen értelmezhetetlen változónevek használatát (ilyenekkel tele van a kódod). Meg a helyesírási hibákat, ha már magyarul kódolsz lásd $oszessen Meg a CSS-kódban a style1, style2, style3, stb. class-ok használatát. HTML-kódnál az #urlap azonosító sem túl kifejező - milyen űrlap? Mire szolgál az az űrlap? Hidd el, sokkal jobban jársz hosszú távon, ha inkább jó hosszú, de értelmezhető neveket adsz mindennek, ami a kódodban van, neked is sokkal jobb lesz hosszú távon, mert később is átlátod a kódodat, meg külső szemlélő számára is valamennyire olvasható marad. Ne vedd magadra, nekem is szóltak és szólnak, ha gányoltam/gányolok. 
(Meg javaslat, hogy futtasd át a HTML-kimeneteden a w3c validátorát: http://validator.w3.org/#validate_by_input)
Plusz kapcsold be fejlesztés idejéig a legmagasabb szintű hibajelzést (pl. kódod elejére
error_reporting(E_ALL|E_STRICT);
), és akkor már az elején kiszűrhetsz jópár hibalehetőséget.Azt írtad, az a gáz, hogy a submit1 elnevezésű gombot kétszer kell elküldeni. Nem futtattam le a kódodat, úgyhogy nem tudom, mit kellene csinálnia, de gondolom összegeznie, hogy hány darabot akar rendelni a vevőd a nem tudom micsodából. Mi az oka, hogy a nagy if-en belül a $_SESSION['select2'] változót használod, miért nem a $_POST tömböt? A sok-sok case is elég durva (gondolj bele, mi lenne, ha 1000 darabot lehetne rendelni a termékedből, akkor 1000 db case-t csinálnál?), így aztán már annyira nem volt kedvem kibogarászni, hogy mit csinálsz vele, de ami feltűnt, hogy miért jó, hogy így állítod be a session-változódat:
$_SESSION['select2'] = strip_tags($_POST['select2']);
mire lesz jó neked ez a strip_tags, ha tömbszerűen akarsz végigmenni rajta, azzal a for ciklussal? Sőt, kettő ilyen for ciklusod is van, azt sem értem, minek. -
#12598
Sk8erPeter
nagyúr
PiXeL90
#12597
Sk8erPeter
nagyúr
válasz
PiXeL90
#12597
üzenetére
Minimális konkretizálás nélkül nem fogunk tudni segíteni, mert rébuszokban beszélsz.
Nyilván senkit nem izgat itt különösebben a Te konkrét kódod, de segítséget kértél, mi meg ha szeretnénk segíteni, akkor a problémát is értenünk kell.
Lehet pszeudokódot is írni, vagy behelyettesíteni hülye nevekkel (alma, Béla, Pista, zsiráf). -
#12592
Sk8erPeter
nagyúr
fordfairlane
#12591
Sk8erPeter
nagyúr
válasz
fordfairlane
#12591
üzenetére
Ja, hát végül is azt is lehet, csak számomra konzekvensebb, hogy akkor kiíratom üresen. Meg szerintem jobban néz ki a ternary operatorral, mint a külön ifekkel.
Persze, ez jogos, érdemes akkor már template-ezést csinálni. -
#12589
Sk8erPeter
nagyúr
fordfairlane
#12588
Sk8erPeter
nagyúr
válasz
fordfairlane
#12588
üzenetére
"illetve inkább
<input name="szelesseg[<?php echo $x;?>]" type="text" size="15" form="form1"<?php if(isset($_POST['szelesseg'][$x])) : ?> value="<?php echo $_POST['szelesseg'][$x];?>"<?php endif; ?>/>
"inkább:
<input name="szelesseg[<?php echo $x;?>]" type="text" size="15" form="form1"
value="<?php echo isset($_POST['szelesseg'][$x]) ? $_POST['szelesseg'][$x] : ''; ?>" /> -
#12586
Sk8erPeter
nagyúr
Soak
#12581
Sk8erPeter
nagyúr
Hát de ez nem jó, mert először végigrohangászol a tömbön, hibát keresve, aztán ha minden oké, akkor array_sum-mal még egyszer végigrohangászol a tömbön, ekkor már összegezve a számokat. Felesleges lépések, ahelyett, hogy egyszer mennél végig rajta, nem sokkal több karakterrel. Legalábbis szerintem a foolproof megoldás érdekében jobb lehet talán a foreach, ízlés kérdése, én nem szeretem a plusz felesleges lépéseket.
Később gond lehet, ha optimalizálni kell.(#12582) Soak :
az előbbi alapján nem meglepő. -
#12585
Sk8erPeter
nagyúr
PiXeL90
#12583
Sk8erPeter
nagyúr
válasz
PiXeL90
#12583
üzenetére
Beletehetsz bármilyen egyedi azonosítót is, akár így is létrehozhatod az elemeidet:
<input type="text" name="mystuff[ezmegaz]" value="10" tabindex="1" />
<input type="text" name="mystuff[amaz]" value="666" tabindex="2" />akkor ilyen lesz a $_POST tömbben:
array (
'mystuff' =>
array (
'ezmegaz' => '10',
'amaz' => '666',
)
) -
#12580
Sk8erPeter
nagyúr
PiXeL90
#12573
Sk8erPeter
nagyúr
válasz
PiXeL90
#12573
üzenetére
Használd tömbszerűen.
Például:<div>
<input type="text" name="mynumbers[]" value="0" tabindex="1" />
<input type="text" name="mynumbers[]" value="1" tabindex="2" />
<input type="text" name="mynumbers[]" value="2" tabindex="3" />
<input type="text" name="mynumbers[]" value="3" tabindex="4" />
<input type="text" name="mynumbers[]" value="4" tabindex="5" />
<input type="text" name="mynumbers[]" value="5" tabindex="6" />
<input type="text" name="mynumbers[]" value="6" tabindex="7" />
</div>aztán járd be:
$sum = 0;
if(isset($_POST['mynumbers'])){
foreach($_POST['mynumbers'] as $numberKey => $numberValue){
if(is_numeric($numberValue)){
$sum += (int)$numberValue;
}
}
}
echo $sum;Szerk.:
sorrendben haladtam, úgyhogy elkéstem, a Soak által ajánlott array_sum() azért nem jó, mert ha a textfieldben például azt adod meg, hogy "10asd", akkor 10-et hozzáad az array_sum()-mal, pedig ez ebben a formában nem szám. Szerintem elég gáz, hogy ez így működik, de ez van. -
#12568
Sk8erPeter
nagyúr
DeltaPower
#12567
Sk8erPeter
nagyúr
válasz
DeltaPower
#12567
üzenetére
Ja, hát igen, ez igaz, sajnos a könyvtári függvények tele vannak ilyen következetlenségekkel...
-
#12566
Sk8erPeter
nagyúr
Coyot
#12563
Sk8erPeter
nagyúr
"van ez így, én az alap str_ függvények paramétereit nem bírom megjegyezni, mondjuk szarul is vannak megírva"
Dehát minek azt megjegyezni, ha ott a zzinternet? Amúgy melyikre gondolsz, hogy szarul van megírva?(#12548) spammer :
hát nem vágom, ennyi alapján nincs ötletem, hacsak nem bugos verziót nyomattál fel, akkor nem tudom, mi lehet az oka, de ha kideríted, engem is érdekel. -
#12547
Sk8erPeter
nagyúr
Laffesz
#12537
Sk8erPeter
nagyúr
válasz
Laffesz
#12537
üzenetére
"Nem tudom esetleg gyorsabb lenne-e ha nem egy tábla lenne, hanem kettő, minden nyelvnek egy-egy."
Nem tartom túl jó ötletnek, hogy minden nyelvhez létrehozz egy-egy pontosan ugyanolyan szerkezetű táblát... szóval ne bontsd szét táblánként. Egyébként az biztos, hogy a táblaszerkezetet újra kell gondolnod, mert gondolj bele, ha négy nyelved van mondjuk, és egy csomó tartalomhoz még egyáltalán nem érkezett fordítás, akkor ha ugyanannak a táblának a hu, en, de vagy es mezőjében nincs tartalom, akkor ezeknél mindenhol NULL szerepel, egymás mellett, az meg nem jó ötlet. Lehet az id ÉS a nyelv is elsődleges kulcs. De ezt ne itt beszéljük meg, hanem inkáb a MySQL- vagy SQL-topicok valamelyikében. -
#12546
Sk8erPeter
nagyúr
spammer
#12545
Sk8erPeter
nagyúr
válasz
spammer
#12545
üzenetére
Akkor lassú, amikor adatbázis-kapcsolatot is használsz, vagy ha egy tök egyszerű, csupán néhány PHP-s függvényhívást tartalmazó oldalt megnyitsz, akkor is?
Kipróbálhatnád esetleg IIS-sel is, Web Platform Installer segítségével gyorsan, kattintgatósan összehozható, ha mondjuk itt a WPI-ben rámész, hogy mondjuk telepíteni szeretnéd a Drupalt, akkor egyből behúzza a MySQL-t, PHP-t, meg a többi dolgot, amit fontosnak tart (pl. cache-elést elősegítő dolgok), meg a végén megkérdezi, mi legyen az admin-jelszó a MySQL-hez. Persze előtte szedd le az EasyPHP-t.
-
#12527
Sk8erPeter
nagyúr
DeltaPower
#12526
Sk8erPeter
nagyúr
válasz
DeltaPower
#12526
üzenetére
Na, akkor már hárman mondtuk, hogy nincs rendesen indexelve.
-
#12523
Sk8erPeter
nagyúr
Jinxb1rd
#12508
Sk8erPeter
nagyúr
válasz
Jinxb1rd
#12508
üzenetére
"Ami probléma nekem az a design, sztem elég tré és ráadásul 3 féle css-ből áll össze"
Na várj, most az elFinderről beszélsz? Már elvesztettem a fonalat.A CKEditornál furcsák a hibák, amikről beszélsz, na de persze 2 év alatt sok változás történhetett, a 4-es változat nem olyan rég jött ki, adhatnál neki egy próbát.
-
#12522
Sk8erPeter
nagyúr
Laffesz
#12521
Sk8erPeter
nagyúr
válasz
Laffesz
#12521
üzenetére
"Ezt a táblát egy phpmyadmin adatbázisban tárolom"
Nincs olyan, hogy "phpmyadmin adatbázis"... a phpMyAdmin csupán egy böngészőben használható eszköz a MySQL-szerverek dolgainak (adatbázisok, táblák, felhasználók, stb.) kezelésére, mindez PHP nyelven megírva. Az adatbázisodnak semmi köze hozzá, hogy annak a tartalmát phpMyAdmin vagy más eszköz felhasználásával nézegeted.Az a 10 perc elég durván soknak tűnik ennyi adatnál. Indexelve van(nak) rendesen az a tábla (azok a táblák), ami(k)ből lekéred az adatokat? Ha XML-fájlba nyomva ennyivel gyorsabban dolgozta fel az adatokat, akkor ott szerintem valami gáz lesz az adatbázissal.
Egyébként kerülő megoldásként az egy gyorsan megvalósítható dolog lenne, hogy "felszeletelve" jeleníted meg folyamatosan az adatokat, ha már tényleg ennyire elképesztő bugyuta kérést kaptál, hogy mindent egy oldalon jeleníts meg (már az ötletet sem értem, minek egy oldalra kicseszni az egészet, amikor ilyen adatmennyiség átláthatatlan, ha azért, hogy keresni lehessen benne, akkor nem a böngésző keresőjét felhasználva kellene ekkora adatmennyiségben, hanem egy tisztességes AJAX-alapú keresőben), mégpedig úgy, hogy mondjuk az első 100 (vagy akármennyi) találatot megjeleníted, aztán folyamatosan töltögeted hozzá az adatok többi részét AJAX-szal.
Arra gondolok, hogy az első 100-at mondjuk megjeleníted így:
SELECT * FROM `szotar` LIMIT 0 , 100
aztán a következő 100-at így:
SELECT * FROM `szotar` LIMIT 100 , 100
azután:
SELECT * FROM `szotar` LIMIT 200 , 100
SELECT * FROM `szotar` LIMIT 300 , 100
és így tovább.
Ezeket mindig AJAX-szal töltögeted hozzá, így legalább már használhatóvá válik az oldal...De alapvetően szerintem az adatbázison kellene javítgatni valamit, megfelelő indexeléssel, ilyesmikkel...
-
#12507
Sk8erPeter
nagyúr
lakisoft
#12502
Sk8erPeter
nagyúr
válasz
lakisoft
#12502
üzenetére
Ja jó, közben látom megoldottad, hogy ne neked kelljen érveket felhozni.
-
#12506
Sk8erPeter
nagyúr
Jinxb1rd
#12499
Sk8erPeter
nagyúr
válasz
Jinxb1rd
#12499
üzenetére
Szívesen, majd írhatnál esetleg visszajelzést, hogy mit sikerült kihozni belőle.
"Szvsz CKEditor kissé gagyi, előző honlapon azt használtam, de..."
Heh? Az gagyi? Ez szerencsére közel sincs így, sőt.
Én a TinyMCE-t hosszas kapcsolatunk után épp a CKEditorral "csaltam meg", majd végül inkább utóbbi mellett döntöttem. CKEditor: "tágas" API, nagyon jó dokumentáció, aktív support, Drupalhoz, Joomlához való külön támogatás, ASP.NET Control (hót egyszerűen kezelhető, percek alatt beüzemelhető!), Java Tag Library, mindez a TinyMCE-ről sajnos nem igazán elmondható. ("Tovább is van, mondjam még?")Ezenkívül az Inline editora szerintem nagyon üt annak egyszerűségével és könnyű beüzemelhetőségével:
http://ckeditor.com/demo#inline
Az sem lehet véletlen, hogy a Drupal 8 core-ba hosszas válogatás után végül a CKEditor került be az amúgy igen meggyőző Aloha Editorról, ennek okáról a Drupal atyjának egyik blogcikkében olvashatsz:
http://buytaert.net/from-aloha-to-ckeditor"Since that announcement, CKEditor has caught up, and now offers feature parity to Aloha Editor when it comes to our needs. Frederico Knabben, creator of CKEditor, has reached out to offer whatever support he can to make CKEditor and Drupal work together better. They already prototyped a convincing alternative to Aloha Editor's killer "Blocks" system (which is an excellent match for Drupal's need to manage content within text content in a structured manner). In addition to that, we found that CKEditor is more mature in terms of APIs, documentation, and ecosystem around the project. Hence, after days of research and weeks of further discussion, the consensus is that CKEditor is now our best choice.
Therefore, we are going to switch from Aloha to CKEditor for Drupal 8 core. By making this switch, we will not only have a more mature WYSIWYG editor, but we also free up resources to work on other parts of Drupal's authoring experience. The CKEditor team has committed to fix the 8 functional gaps that we've identified in their two next upcoming releases."
-
#12505
Sk8erPeter
nagyúr
lakisoft
#12502
Sk8erPeter
nagyúr
válasz
lakisoft
#12502
üzenetére
"(#12498) lakisoft válasza cucka (#12497) üzenetére
[...]
2. nagyon nem vagy képben az adatbázisok terén.
"
Hahó, nyugalom, ez egy szakmai topic, nem kell egyből személyeskedéssel kezdeni, sokkal többet érsz szakmai érveléssel, amikor kifejted, hogy szerinted a másik miért is mondott valamit rosszul.Lehet, hogy csak nekem nem sikerült kisajtolni a hozzászólásaidból, de sajnos nem látom a válaszokat a cucka által felvetett kérdésekre, pedig engem is érdekelne...
Ki tudnád fejteni, milyen verziókövetésre és milyen frameworkökre (!!) gondoltál? -
#12495
Sk8erPeter
nagyúr
Sk8erPeter
#12494
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#12494
üzenetére
Esetleg ha nem válna be, kipróbálhatnád, amit Speeedfire kolléga a másik topicban ajánlott, CKEditor + http://elfinder.org/:
http://prohardver.hu/tema/weblap_keszites/hsz_6272-6274.html
itt módosítgatta kicsit:
http://prohardver.hu/tema/weblap_keszites/hsz_6288-6288.html -
#12494
Sk8erPeter
nagyúr
Jinxb1rd
#12478
Sk8erPeter
nagyúr
válasz
Jinxb1rd
#12478
üzenetére
Nem lehet, hogy valami ilyesmibe futottál bele, mint az alábbi?
http://serverfault.com/questions/329257/deny-all-request-for-any-setup-php-or-upload-php
Vmiért úgy gondolta itt egy szerver üzemeltetője, hogy jó lesz tiltani globálisan az upload.php-t a TinyMCE-nél. Bár ahogy írod, csak a "folder" query stringnél nem jön be a dolog, de lehet, hogy valami ilyesmi van a háttérben. Esetleg nézd meg, saját .htaccess-ben nincs-e ilyen szabály. Ahhoz még túl korán van, hogy hirtelen vágjam, saját .htaccess-ből ezt felül tudod-e bírálni, próbáld meg.
-
#12475
Sk8erPeter
nagyúr
kkdesign
#12474
Sk8erPeter
nagyúr
válasz
kkdesign
#12474
üzenetére
"Az is megfelelne, ha egy komplett kész kódot tudnék belepakolni az oldalba, csak valósítsa meg ezt"
Nem hiszem, hogy ez "kompatibilis" a szakdolgozat-készítés elveivel....
A CMS használata szakdolgozathoz viszont adott esetben igenis jogos lehet, például ha eköré épül a téma, vagy van egy komolyabb cél, amit ennek igénybe vételével oldottál meg. De ha lopsz-csalsz, akkor az már plágium. Vagy lemaradtál a közelmúlt eseményeiről?========
(#12453) jeszi : szívesen!
-
#12451
Sk8erPeter
nagyúr
jeszi
#12450
Sk8erPeter
nagyúr
flock($fp, LOCK_EX)
exclusive lock-ot raksz a fájlra írás előtt, majd flock($fp, LOCK_UN) kóddal pedig feloldod a zárolást. Ez most a korábbi fwrite()-os példádra vonatkozik.
Ennél viszont egyszerűbb talán a file_put_contents() megoldása, mert itt a fentit végzi el helyetted automatikusan, ha beállítod a LOCK_EX flaget.
Arra viszont figyelj, hogy ez csak PHP 5.1.0-tól elérhető, győződj meg róla, nálad magasabb verziószámú PHP fut-e.
A hivatalos oldalon található egy egyszerű példa, ami pont hozzáfűzést ÉS zárolást mutat be, neked pedig pont ilyen kell, ha a korábbi példádból indulok ki:$file = 'people.txt';
// The new person to add to the file
$person = "John Smith\n";
// Write the contents to the file,
// using the FILE_APPEND flag to append the content to the end of the file
// and the LOCK_EX flag to prevent anyone else writing to the file at the same time
file_put_contents($file, $person, FILE_APPEND | LOCK_EX); -
#12445
Sk8erPeter
nagyúr
jeszi
#12444
Sk8erPeter
nagyúr
Különösebben nem tanulmányoztam át a kódodat, de a $fields_string miért nincs inicializálva egy üres stringgel? Ha valami query stringet építesz össze, akkor miért nem a http_build_query() függvényt használod?
Fájlba írásra miért nem a file_put_contents() függvényt használod, a FILE_APPEND flaggel az egyszerűség és szebb kód érdekében? -
#12428
Sk8erPeter
nagyúr
Tele von Zsinór
#12427
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#12427
üzenetére
Csatlakozom, BME-n is eléggé jellemző, hogy az emberek a szakdogájukat LaTeX-ben írják, meg van külön dokumentumszerkesztős óra ezzel kapcsolatban (ahogy a Worddel kapcs. is).
-
#12425
Sk8erPeter
nagyúr
DeltaPower
#12422
Sk8erPeter
nagyúr
válasz
DeltaPower
#12422
üzenetére
Miért, a LaTeX halott vagy Magyarországon ismeretlen?
-
#12420
Sk8erPeter
nagyúr
Agyasima
#12419
-
#12410
Sk8erPeter
nagyúr
Agyasima
#12403
Sk8erPeter
nagyúr
válasz
Agyasima
#12403
üzenetére
Ez segíthet az alapok megértésében:
Nagy Gusztáv: Web programozás alapismeretek
http://nagygusztav.hu/web-programozas(mondjuk szerintem a webprogramozás egy szó, de mindegy
) -
#12409
Sk8erPeter
nagyúr
Vision
#12408
Sk8erPeter
nagyúr
válasz
Vision
#12408
üzenetére
"Egy random junior/senior C++ programozó mindig többet fog keresni, mint egy random junior/senior php programozó."
Jaja, ez igaz. Én inkább csak arra gondoltam, hogy ettől függetlenül vannak jó fizuért PHP-s állások (nem saját tapasztalatból beszélek, mielőtt kérdeznéd)."Ott volt a kérdés, hogy másfele induljon-e? Azt pedig úgy értelmeztem, hogy más szakterület irányába induljon-e."
Ja, lehet, hogy így értette, én elsőre másképp értelmeztem, azt hittem, arra gondol, hogy akár magyar nyelvű tutorial helyett tudunk-e ajánlani valami nagyon frankó angol nyelvű alternatívát. -
#12407
Sk8erPeter
nagyúr
lezso6
#12406
Sk8erPeter
nagyúr
válasz
lezso6
#12406
üzenetére
Ez így van.
Egyébként gondolom értetted Te is, mire gondolok, hogy egyes cégeknél jó állásért meglepő fizukat lehet hallani még PHP-munkakörben is.
Meg azért írtam, hogy "trollkodás", amit válaszolt, mert az volt a kérdés, milyen tutorialt nézzen meg, nem az, hogy belevágjon-e és jó fizut fog-e kapni, vagy sem. -
#12405
Sk8erPeter
nagyúr
Vision
#12404
Sk8erPeter
nagyúr
válasz
Vision
#12404
üzenetére
A jó kis szaftos trollkodás.
Amit írtál, az megint az "attól függ"-kategória, önmagában szerintem nem helytálló. Egyébként azzal viszont egyetértek, hogy a PHP renoméja nem túl jó, ennek sajnos meg is van az oka, ezért jó sok meló szarul fizet, és például egy ASP.NET-es melót szvsz nagyobb eséllyel találsz több fizuért. -
#12398
Sk8erPeter
nagyúr
Atti575
#12394
Sk8erPeter
nagyúr
válasz
Atti575
#12394
üzenetére
Teljesen felesleges itt az adatbázis- és tábla-létrehozó query-d. Ezt nem így szokás elintézni, szóval amíg nincs az alkalmazásodban ez a tábla automatikus létrehozása az alkalmazásból egy jó helyre beépítve, addig inkább hozd létre manuálisan az adatbázist és a táblát. Úgyis csak egyszer kell. Viszont csúnyává teszi a kódodat, hogy ott van ez a query, plusz egy felesleges terhelést ró a webszerverre és az adatbázis-szerverre is.
Ezt a hozzászólásomat nem láttad? >>> [link]
Itt egy használhatóbban kinéző kód van.========================
(#12397) fordfairlane :
bár látványosan ignorálod a neked címzett hozzászólásaimat, az azokban esetleg számodra feltett direkt kérdéseket valami elég furcsa okból, azért megkérdezem: miért nem próbálsz inkább jobb szokást belenevelni az újoncba, pl. PDO-kódok használatával, hibaelnyomás (lásd @ karakter) használata helyett normális hibakezeléssel? Most érted, az is egyfajta "felelősség", hogy mi milyen segítséget adunk itt valakinek. -
#12386
Sk8erPeter
nagyúr
oleslie
#12385
Sk8erPeter
nagyúr
válasz
oleslie
#12385
üzenetére
Ennek semmi köze az Ubuntuhoz...
Nem véletlen, hogy deprecated az általad írt megoldás, és ezért nem kell ám anyázni
http://php.net/manual/en/language.references.pass.php"Note: There is no reference sign on a function call - only on function definitions. Function definitions alone are enough to correctly pass the argument by reference. As of PHP 5.3.0, you will get a warning saying that "call-time pass-by-reference" is deprecated when you use & in foo(&$a);. And as of PHP 5.4.0, call-time pass-by-reference was removed, so using it will raise a fatal error."
Miért lenne "belekötés" egy egyszerű korrekció? 
Hogy jön ide a get_defined_vars(), amikor csak egyetlen változó meglétét szeretnéd ellenőrizni? Ez a függvény egy komplett tömböt ad vissza az adott scope-ban elérhető lokális/globális/szerver/környezeti változókról, tehát tartalmazni fogja a $GLOBALS tömb dolgait, a $_SERVER dolgait, és így tovább... ezután ezen a tömbön fogsz kiadni egy isset()-et, és akkor ugyanott vagy, vagy ezt most hogy értetted?
Ha például egy adott mezőt kötelező kitölteni, vagy mondjuk 0-nál (0.0-nál) nagyobb szám megadására van szükség, akkor végül is ellátja a feladatát, de ettől függetlenül azzal egyetértek, hogy általános validációra nyilván alkalmatlan.
"
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
- Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
- AKCIÓ! MSI B450 R5 5500 16GB DDR4 512GB SSD RTX 2060 Super 8GB GDDR6 Rampage Shiva Zalman 500W
- Huawei Nova Y70 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! SAPPHIRE NITRO+ RX 7900 XTX 24GB GDDR6 videokártya garanciával hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest