Új hozzászólás Aktív témák
-
#19931
instantwater
addikt
Joci93
#19930
-
#68216320
törölt tag
válasz
Joci93
#19508
üzenetére
Nem kell ezert composer rogton. Mint kiderult a macOS-en, amin a PHP 5.6 van, nem volt a mysql.default_socket beallitva a php.ini-ben. Kellet egy link a mysql.socket-hez es be kellett allitani a php konfigban. Azaz nem programkod volt a problema, hanem a dev. env. volt elszurva.
-
#18518
PumpkinSeed
addikt
Joci93
#18516
PumpkinSeed
addikt
válasz
Joci93
#18516
üzenetére
Az ilyenek amúgy például pont mehetnének egy model-be aminek pl lenne a neve imageHandlerModel vagy valami ilyesmi. Nem tudom mik a lehetőségek erre Laravel-ben de mivel alapból asszem az is MVC framework ezért biztos van rá lehetőség. Amiért én ezt a model-be tenném, mert pl. lehet, hogy más controllerek is használni akarják majd a kép átméretezést és a model-t bármilyen conrollerben meghívhatod.
-
#18517
fordfairlane
veterán
Joci93
#18516
fordfairlane
veterán
válasz
Joci93
#18516
üzenetére
... a harmadik megoldást megnézem a doksiban.
A harmadik módszer az, amit manapság javasolni szoktak. Dependency Injection, DI container, Service container, hasonló kulcsszavak mögött találod meg a témakört.
Egyébként szerintetek sem jó, ha egy metódusban 2 vagy több dolog történik? Például kép feltöltés --> méretezés --> mentés. Hanem, ezeket a lépéseket célszerűbb külön - külön metódusba szervezni?
Az attól függ, mennyire komplex egy-egy eljárás. Ha egyberakod, később nehezebb lesz a részeit újra felhasználni egy másik pontján a kódban, mivel így nem eléggé moduláris. Persze meglévő kódot később is át lehet írni, tagoltabbá tenni.
Ezen kívül azt is érdemes szem előtt tartani, hogy a kód olvasásával és értelmezésével általában nagyságrendileg több idő szokott elmenni, mint a leírásával, függetlenül attól, hogy a saját-vagy más által írt programot kell tudnod értelmezni. Egy év múlva ránézel egy metódusra, és hiába te írtad, egyáltalán nem biztos, hogy érteni fogod, mi micsoda. Ha a kódod tagolt, és egyértelmű, hogy mi miért van benne, az sokat számít.
-
#18515
fordfairlane
veterán
Joci93
#18513
fordfairlane
veterán
válasz
Joci93
#18513
üzenetére
1. Lehet úgy csinálni, hogy egyetlen kontrollerobjektumot használsz több metódussal. A közös kódrész, a "getItemDetails" külön metódusba kerül, amit a többi metódus meghívhat.
2. Lehet csinálni a két kontrollerosztálynak közös szülőosztályt, ami tartalmazza a közös kódrészt.
class IndexController extends MyController
class SubmitController extends MyController
class MyController extends Controller3. Lehet csinálni egy service objektumot, amit aztán bármelyik kontroller használhat. Ebben az esetben a service objektumot példányosítani kell az adott Kontroller konstruktorában, vagy valami service manager komponens segítségével. Laravelben is van ilyen, csak én speciel nem ismerem a Laravelt, így ebben konkrét tanácsot vagy kódrészletet nem tudok produkálni.
A framework saját controller osztályát módosítani valóban nem tanácsos.
-
#18514
PumpkinSeed
addikt
Joci93
#18513
PumpkinSeed
addikt
válasz
Joci93
#18513
üzenetére
Igazából elvben nem szabadna két kontrollernek kommunikálni egymással vagy nem tudom. De szerintem jobb lenne ezt a
Details()metódust beletenni a Controller-be. Viszont mivel gondolom a Controller a Core-ban van benne ezért ezt nem kellene csinálni a későbbi frissítések miatt. Esetleg azt lehetne csinálni, hogy betenni egy Controller-t ValamiController néven (Nem tudom mi az Index és Submit ebben az esetben) és aSubmitControllermeg azIndexControllernemextends Controller-el lenne ellátva hanemextends ValamiController, míg aValamiControllermegkapná azextends Controller-t és benne lenne aDetails()metódus. -
DNReNTi
őstag
válasz
Joci93
#18467
üzenetére
Ha egy kép csak egy gallériában szerepelhet akkor jó ez a megoldás, ez az 1:n (egy a többhöz) kapcsolat. Ha ugyan azon kép több galériában is benne lehet, akkor kell az n:m, abban az esetben külön egy tábla van csak a kapcsolatoknak fenntartva, tehát három táblára van szükség. Egy a gallériák, egy a képek, illetve egy a kapcsolat tábla, amely összeköti PK alapján a képeket és gallériákat, így lehetővé téve az n:m (több a többhöz) kapcsolatot.
Ha jók az indexek biztos nem lesz lassú, sőt, a string parse-olástól tuti lényegesen gyorsabb. Kell rá írni egy fasza SP-t, ami mondjuk galéria ID alapján visszaadja az össze képet, és akkor már adatbázis szinten le van kezelve.
-
-
supercow
őstag
válasz
Joci93
#17837
üzenetére
kimazsoláztam, asszem jó lett. Érdekes módon az echo használatával hibákat adott, print-tel viszont nem..
$param = (object)array('name' => 'test');
isset($param->name) ? ( $param->name=='test' ? print 'test' : ( $param->name=='test2' ? print 'test2' : print 'not_test2' ) ) : print "not_set"; -
#17792
PumpkinSeed
addikt
Joci93
#17791
PumpkinSeed
addikt
válasz
Joci93
#17791
üzenetére
Gondolom a jquery .value értéket írna felül amit amúgy az etdate2-nél nem lehet.
document.getElementById('stdate2').value = "valami";
/*Sikeresen felülírta*/
document.getElementById('etdate2').value = "valami";
/*Nem írta felül*/Mert az első form-ban is etdate2-nek nevezted el és ezért nem látja a hivatkozásnál a másikat.
-
DNReNTi
őstag
válasz
Joci93
#17296
üzenetére
Kíváncsi lennék mivel magyarázza meg, hogy ott lehet biztonsági rés. Arra is kíváncsi lennék mégis mit javasol akkor helyette, ami biztonságosabb. Abban meg egészen biztos vagyok, hogy biztonsági rés sokkal hamarabb keletkezik kliens oldalon, vagy akár szerver oldalon - lásd nem régiben a YouTube fatális béna hibája. Na mindegy, szerintem ne foglalkozz vele, de asszem ezt már a többiek is javasolták.
-
#17291
Sk8erPeter
nagyúr
Joci93
#17285
Sk8erPeter
nagyúr
válasz
Joci93
#17285
üzenetére
cidalainnal értek egyet, van olyan feladat, ami eleve értelmetlen, így nem biztos, hogy megéri elvállalni, szépen türelmesen el kell magyarázni a megrendelőnek, hogy baromságot akar. Aztán hátha meggondolja magát, vagy tovább kell állni (már ha van választási lehetőség). Nem akar adatbázist valami degenerált indokból, de azért valahol mégis, meg szeretne query-ket is írni kézzel, amit ja, akár phpMyAdminban is megtehetne, ha ez a kattanása, de nem, ő a spanyolviaszt akarja felfedezni.
De ha már muszáj elvállalnod, és valahova menteni kell, illetve fel is kell tudni dolgozni a tárolt adatot, akkor a txt-t vagy bármi behányt szöveget azonnal felejtsd el, valami normálisan és hatékonyan feldolgozható formátumban mentsd el, legyen az JSON, XML, stb. Ha már az SQLite is szóba kerülhet, mint lokális, fájlba írós adatbázis, akkor már nem igazán értem, miért ne lehetne egy tisztességes adatbázis (nem lebecsülve az SQLite-ot, de nagyobb adatmennyiség esetén már nyilván nem ez a hatékony megoldás), onnantól már csak egy lépés.
Mi is pontosan az indoka a megrendelőnek arra, hogy nem lehet adatbázist használni?Amúgy ha már SQL parsert kell használnod, akkor nehogy elkezdd kézzel összetákolni, mert rohadt nagy szopás tud lenni egy parser, inkább használj fel egy kész könyvtárat:
https://code.google.com/p/php-sql-parser/
http://stackoverflow.com/questions/283087/php-mysql-sql-parser-insert-and-update/283115#283115Szerk.:
(#17290) PumpkinSeed: pont megelőztél.
Amúgy egyetértek. -
#17290
PumpkinSeed
addikt
Joci93
#17285
PumpkinSeed
addikt
válasz
Joci93
#17285
üzenetére
"Ahogy mondod. Meg kéne írni, hogy a SELECT,FROM, WHERE mit csináljon
"Elnézést kedves Edgar F. Codd elsőre nem ismertem meg önt, az a helyzet, hogy nem 1970-ben vagyunk, rossz időben tetszik lenni. Már létezik az SQL, nem most kell kitalálni.
Na de most komolyan, miért kér egy megrendelő ilyen ostobaságot? Látszólag azt se tudja miről beszél, te meg hagyod, hogy ilyen hülyeségeket kérjen tőled. Az más lenne, ha komolyan megmondaná mit használj mondjuk NoSQL-t vagy valami de így, hogy ne használj adatbázist ez csak értelmetlen szavakkal való dobálózás. Fel kell világosítani, hogy kell ha adatokat akar tárolni és reális időn belül akarja visszakeresni. Használhattok .txt-t is, de ha az adatbázist a biztonságtalansága miatt nem kedvelte akkor ez azonnal meg is bukott, sőt még lassú is.
-
#17289
fordfairlane
veterán
Joci93
#17285
-
cidalain
veterán
válasz
Joci93
#17285
üzenetére
űrlap lehet a sima text beviteli mező is, az meg nem kötött. azt ír be amit akar.
az a baj hogy adott a tárhely, és nincs rajta adatbázis?
ha igen, én nem szarakodnék fájl alapú tárolással, elő kell fizetni egy normális adatbázisos tárhelyre. 10/év alatt már vannak. nem éri meg a vesződséget, amit nyerne a vámon a megrendelő elbukná a réven... -
#17280
PumpkinSeed
addikt
Joci93
#17276
PumpkinSeed
addikt
válasz
Joci93
#17276
üzenetére
Szögezzük le: Nem akarsz DB-t! De...
- "kiadja a lekérdezés eredményét"
Milyen lekérdezés eredményét? Nincs adatbázis amiből adatokat kérdezzen le.- "SELECT name FROM Test WHERE id = 1"
Hogy kerül ide SQL, mikor nincs adatbázis kezelő program se ami feldolgozza... vagy van adatbázis kezelő programod adatbázis nélkül?- "hogy a szintaxisa hasonló"
Esetleg te írod meg az adatbázis kezelőt és a hozzá tartozó strukturált lekérdező nyelvet illetve az adatok tárolására szolgáló állományokat is te generálod? Vagy hogy van ez? -
cidalain
veterán
-
#17225
PumpkinSeed
addikt
Joci93
#17223
PumpkinSeed
addikt
válasz
Joci93
#17223
üzenetére
Erre szerintem nincs beépített függvény de ha azt csinálod, hogy a egy for-al végigjárod a tömböd tartalmát majd az str_split() beépített függvénnyel azt egy karaktertömbbé alakítod és úgy vizsgálod meg akkor valószínűleg menni fog. pl.:
for($i = 0; $i<valamennyi;$i++){
$charArray = str_split($array);
for($j = 0; $j<count($sharArray);$j++){
if("}" == $charArray[j]){
echo "valami";
}
}
}(#17224) Sk8erPeter
Nem tudtam, hogy van erre függvény,
meg lehet kérdezni, hogy mi az?Gondolom az strpos(), most találtam meg.
-
#15903
Sk8erPeter
nagyúr
Joci93
#15902
-
#15900
Sk8erPeter
nagyúr
Joci93
#15894
Sk8erPeter
nagyúr
válasz
Joci93
#15894
üzenetére
"Részletes keresést $_GET[""]-el vagy $_POST[""]-al érdemes csinálni?"
A kérdés így kicsit furán hangzik. Most az a kérdésed, hogy GET-metódussal vagy POST-metódussal érdemes-e egy keresésre szolgáló űrlapot megadni (method-attribútumban)? Mert ha igen, akkor a GET-metódust szokás általános keresésekre használni, így a keresések könyvjelzőzhetők, elküldhetők másnak, stb., de ha elég összetett az űrlap, akkor nyilván az sem jó, ha minden be van hányva az URL-be, így ez esetben POST-metódus használható.
DE ami fontos, és ami miatt a kérdésed nem helyes, hogy a HTML-oldalnak semmi köze a PHP szuperglobális változóihoz, a GET és POST csupán HTTP-metódusok (amiket jelen esetben a form tag method-attribútumában adsz meg), a szerveroldal pedig az űrlap adatait fogadhatja bármi más szerveroldali nyelvvel, nem csak a PHP létezik; csak a PHP az ilyen nevű szuperglobális változókon keresztül teszi elérhetővé az ilyen metódussal - kliensoldalról - kapott adatokat. Ergo a kérdésed inkább úgy hangzana jól, hogy az ilyen-olyan keresőűrlapok adatait GET- vagy inkább POST-metódussal érdemes-e elküldeni szerveroldalra. -
#15898
fordfairlane
veterán
Joci93
#15897
fordfairlane
veterán
válasz
Joci93
#15897
üzenetére
25 checkbox esetén célszerű egy listát csinálni, és azon iterálva ellenőrizni, hogy melyik szerepel a bemenőparaméterek közt. A listában lehet egyéb opciókat is tárolni, ha bizonyos checkboxokat egyedileg kell kezelni, validálni, satöbbi.
Mivel nem írtál konkrétumot, így nehéz konkrétumot válaszolni, mindenesetre a 25 már akkora mennyiség, aminél valószínűleg érdemes generalizálni mind a checkboxok html renderelését, mind a submit feldolgozását, és az adattárolás részét. Kérdés, hogy technikailag felkészült-e vagy ilyenre vagy sem.
Alternatívaként érdemes szétnézni a PHP-s web frameworkök (Symfony, Laravel, Zend) form moduljai körül, amik pont ennek az automatizálására vannak kitalálva.
-
#15872
Sk8erPeter
nagyúr
Joci93
#15871
Sk8erPeter
nagyúr
válasz
Joci93
#15871
üzenetére
Szívesen.
"Jelenleg Eclipse-t használok."
Az is teljesen jó.Még szerkesztettem az előző hsz.-t, beleírtam, hogy tudod normálisabban kezelni a hibákat, még azt azért nézd meg.
Mondjuk én a mysqli-ről a helyedben inkább áttérnék PDO-ra, mint előbb látható volt, szebb tud lenni. A PDO-nál az előbb írt felparaméterezéssel ráadásul hibák esetén exceptionök dobódnak, az ilyen jellegű hibákat meg egy try {...} catch(...) {...} blokkban tök szépen le lehet kezelni.
(Amúgy a fentebbi kódot kézzel pötyögtem be, nem próbáltam ki, de remélhetőleg működik egyből.) -
#15870
Sk8erPeter
nagyúr
Joci93
#15869
Sk8erPeter
nagyúr
válasz
Joci93
#15869
üzenetére
Akkor már csináld objektumorientáltan, ha a lényege szintén az (és amúgy is sokkal szebb):
$mysqli = new mysqli('localhost', '*****', '******', 'test');
A hibaellenőrzés mondjuk nem objektumorientált, de még mindig jobb, mint az "or die(...)":
// check connection
if (mysqli_connect_errno()) {
$errorMsg = mysqli_connect_error();
// hiba volt, csinálj valamit a hibával ($errorMsg-ben lévő hibaüzenetet naplózd, írj ki felhasználóbarát üzenetet, ne hagyd folytatni a script vonatkozó részének végrehajtását, stb.)
}"Az "egyedi" változónevekről én tudom, hogy micsoda és az szerintem bőven elég"
Hát ez egy nagyon rossz hozzáállás. Nem elég! A kódod legyen később általad és akár más által is olvasható. Amúgy meg semmivel nem kerül több időbe normális változóneveket adni (jó, néha nem jut eszébe azonnal a legfrappánsabb név az embernek, akkor lehet, hogy 1-2 másodperccel több).
És ne Notepad++-t vagy valami hasonlót használj, hanem olyan fejlesztőkörnyezetet (IDE), ami normális támogatást ad a kódolásodhoz, és pl. Ctrl+Space-re kiegészíti a kódodat. -
#15868
Sk8erPeter
nagyúr
Joci93
#15866
Sk8erPeter
nagyúr
válasz
Joci93
#15866
üzenetére
A $bd->prepare előtti részt is oszd meg légyszi, hogy hogyan csatlakozol az adatbázishoz (nyilván a felhasználónév-jelszó infót csillagozd ki, vagy valami), és hogyan inicializálod a $bd változót. Egyébként ne használj ilyen változóneveket, mint a $bd, mert nem lehet belőle tudni, hogy az micsoda. Egy változónév legyen beszédes. Olyanokat se használj, hogy $res3, $uzenet2, $uzenet3, mert ez így katyvasz (miért pont 2? Miért pont 3?). Bár remélem csak a demókódodban vannak ilyenek. Illetve elírások: reciever --> receiver, RECIEVED --> RECEIVED.
Amúgy annyira gusztustalan ez a mysqli-s szintaktika (ezzel az $uzenet->bind_param('si', $uzenetszam, $zero); résszel), ha már ilyesmi, akkor PDO-val ezt sokkal szebben meg lehetne oldani, valami ilyesmi lenne ($idOfReceiver változó megfelelője a te kódodban az $uzenetszam):$idOfReceiver = 123123;
$hasReceivedMessage = 0;
$db = new PDO(
"mysql:host=localhost;dbname=test",
"root",
"root",
array(
PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES UTF8;',
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
)
);
$stmt = $db->prepare("SELECT COUNT(reciever) AS uzenet FROM uzenet WHERE reciever =:receiver AND RECIEVED =:received");
$stmt->bindValue(':receiver', $idOfReceiver); // vagy bindParam
$stmt->bindValue(':received', $hasReceivedMessage); // vagy bindParam
$stmt->execute();
/*
// vagy egyben:
$stmt->execute(array(
":receiver" => $idOfReceiver,
":received" => $hasReceivedMessage,
));
*/
$numberOfMessages = $stmt->fetchColumn();
echo 'Number of messages: ', $numberOfMessages; -
#15818
PumpkinSeed
addikt
Joci93
#15817
PumpkinSeed
addikt
válasz
Joci93
#15817
üzenetére
Milyen hibát dob?
Ez így szerintem azért nem jó, mert gondolom azért használtál függvényt, hogy többször felhasználd a kódot, na így most minden függvényhívásnál "feleslegesen" includeolod a config.php-t. Ez olyan mintha minden mondatod előtt bevennél egy újabb Orbitot és a mondandód végére tele lenne rágóval a szád.
-
#14698
fordfairlane
veterán
Joci93
#14697
fordfairlane
veterán
válasz
Joci93
#14697
üzenetére
Akkor valószínűleg az átirányítás nem működik. A header csak akkor működik, ha előtte nem történt írás a kimenetre, a böngésző felé (akárcsak egy szóköz vagy sortörés, vagy hibaüzenet, bármi). Ha az output buffering localhoston be van kapcsolva, akkor ezt észre sem veszed, mert ilyen esetben késlelteti a kiíratást a PHP.
-
#14687
DeltaPower
addikt
Joci93
#14684
DeltaPower
addikt
válasz
Joci93
#14684
üzenetére
1. Nyisd meg inkognitó ablakban, ha úgy is egyből beenged akkor a kódban rossz valami.
2. Ennek miért kellene leszedni a .php végződést a linkekből? Ez azt csinálja, hogy minden nem létező fájlra mutató kérést átirányít az azonos nevű php-ra. Nyilvános tárhelyre így fel ne tedd az oldalt.
Amúgy egyetértek.
"
bocses 
Új hozzászólás Aktív témák
Hirdetés
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- Újszerű Samsung 34 -es hajlított monitor - 3440x1440px / HDR10 / 100Hz / USB-C PD 90W (S34A650UXU)
- Használt iPad Pro 10. 5 cellular - 64GB + Apple Smart Keyboard + Apple Smart Cover
- Használt 2022-es MacBook Air 13 - M2-es processzor, 8GB RAM, 256GB SSD
- MacBook Pro 14" M1 MAX - 32GB / 1TB (2021) - Cseh billentyűzet - 224 ciklus / 88% - 1 év garancia
- AKCIÓ! AMD Ryzen 5 2600 6 mag 12 szál processzor garanciával hibátlan működéssel
- LG 27GR93U-B - 27" IPS - UHD 4K - 144Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDR 400
- LG 65BX - 65" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
- AKCIÓ! Apple Macbook Pro 16" 2019 i7 9750H 32GB 500GB Radeon Pro 5300M hibátlan működéssel
- ÁRCSÖKKENTÉS Panasonic Viera 37" TH-37PV8P plazma TV eladó (2 HDMI)
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest