Új hozzászólás Aktív témák
-
zka67
őstag
válasz Sk8erPeter #6301 üzenetére
Nem arról beszélek. A textarea-nak is ugyanaz az alapértelmezett fontja mint a pre-nek. Magyarul amikor beírja, ugyanúgy látja mint ha pre-vel íratná ki.
De nem tart semeddig se megváltoztatni a stílust. Azt kérte az illető, hogy ugyanúgy nézzen ki neki a szöveg, mint amikor beírja, erre pedig a pre a megfelelő megoldás.
-
Sk8erPeter
nagyúr
Szerintem elég gányolós megoldás kiíratni a hozzászólást egy fórum esetén <pre> tagekkel ellátva, és ennek a stílusát megváltoztatni CSS-sel utólag, hogy ne az alapértelmezett betűtípussal jelenjen meg. Tök másra való a <pre>, nem véletlenül más a betűtípusa sem, és nem véletlenül nem ezt szokták használni ilyen esetben - a JS-alapú szövegszerkesztők (lásd TinyMCE) is általában <br /> sortörésre alakítják a szöveget Shift+Enternél, vagy új bekezdést (<p>) hoznak létre sima Enternél. Nyilván jelen esetben az elsődleges cél a(z) (X)HTML-ben való megjelenítés, akkor ennek megfelelően is tároljuk el, és ne utólag gányoljunk a szöveggel. Szerintem.
Sk8erPeter
-
TonTomika
aktív tag
Sziasztok!
Elhatároztam, hogy a HTML+CSS mellé nagyon nem ártana, ha megtanulnám a PHP+MySQL kombót is, mert rengeteg jó dolgot lehetne csinálni benne, csak nem tudom, hogy hogyan.
Ehhez keresnék egy megfelelő könyvet (átnéztem a kezdőposztban lévő felsorolást is), megfelelő alatt azt értem, ami lehetőleg friss, releváns kiadvány, egy abszolút kezdő is megtanulhat belőle annyit, hogy utána magától is elboldoguljon és képes legyen önállóan felépíteni egy webes programot, pl tartalomkezelő rendszert vagy akár egy hírlevélküldő alkalmazást. Persze azt gondolom hogy egyetlen könyvből ennyi mindent nem lehet elsajátítani, viszont szeretnék egy képet kapni, hogy mégis milyen könyveken kéne átrágnom magamat.
Könyvből amit ajánlottak nekem az az Agyhullám: PHP és MySQL és a PHP5 24 óra alatt című kiadvány, bár erről hallottam már pár embertől, hogy annyira nem jó. (Pl hibás mintakódok.)
Gondolkodok tanfolyamon is, noha ez egy nagyobb befektetés, éppen ezért szerintem ennek úgy van értelme, ha az alapokkal már tisztában van az ember, akkor a komolyabb feladatokat már egy tanfolyam keretében tanulhatná meg. Ismer valaki ilyen helyet? Ahol tanítanak is (tudást adnak át) a pénzemért és nem csak a lehúzás megy?
Előre is köszönöm a segítséget!
[ Szerkesztve ]
-
ArchElf
addikt
válasz TonTomika #6305 üzenetére
Ha van programozási előképzettséged (és nem akarsz gép nélkül tanulni), akkor én a helyedben nem vennék könyvet: neten példakódból van elég, a php.net-en található leírások pedig szerintem bőven elegendők - főleg, hogy a community kommentek néha hasznosabbak, mint maga a leírás.
Ha nincs előképzettséged, akkor szerintem inkább vegyél egy nem nyelv specifikus könyvet (programozási alapismeretek) és próbáld meg abból elsajátítani az alapokat, majd utána az elméleti tudásra építve indulj el a netes példák és a hivatalos specifikáció alapján.AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
-
fordfairlane
veterán
válasz Tele von Zsinór #6236 üzenetére
Igazad van, sokkal korrektebben írtad le nálam.
Mindenesetre nekem a fejemben a PDO és a prepared statement szinte fixen kapcsolódott össze, írtam is rá osztályt.x gon' give it to ya
-
LW
őstag
Sziasztok.
Épp a sessionkezelést (újra) nézegettem és érdekelne, hogyan érdemes megoldani azt, hogy ha a felhasználó úgy kívánja, akkor maradjon bejelentkezve(tartsa meg a munkamenetet) a webhelyen.Példához nem kell messzire menni, itt a prohardveren is élő funkció.
Mennyire érdemes állítani a munkamenet élettartamát?
40 perc sok lenne, de ha valaki belelendül a (pl.)cikkírásba, akkor elég sok adat veszhet el, ha már nem létezik a munkamenet.
Olvastam, hogy érdemes két határt bevezetni. Egyiknél a munkamenet még létezik, de x perc inaktivitás után megerősítés gyanánt újra elkérem a jelszót és ott folytatódik, ahol abba lett hagyva. A második határ értelemszerűen a session végső lejárata.Munkamenetekről lévén szó, a biztonság nem utolsó. Minden munkamenetet SQL táblában nyilvántartok, ahol REMOTE_ADDR és HTTP_USER_AGENT tárolva vannak, ha bármelyikben eltérés van, akkor érvénytelen a munkamenet.
Mennyire érdemes még ezt bonyolítani saját session.hash generállással vagy egyébbel?A lejárt és session-ös táblában ragadt rekordokat hogyan érdemes pucolni?
Minden új bejegyzéskor egy takarítólekérdezéssel vagy van kifinomultabb módja is?üdv. LW
-
RedSign
tag
Szia!
Hát a fő kérdés szerintem, hogy mi az oldal célja és mekkora szintű biztonságra van szükséged? (minél nagyobb annál kisebb időre és annál gyakoribb megújításra). Sok trükköt lehet alkalmazni, a kérdés, hogy szükséges-e az adott oldalhoz? Persze nem tagadom minél biztonságosabb valami annál jobb...
Üdv,
RedSignhttp://www.redsign.hu
-
Tele von Zsinór
őstag
Ahogy előttem is írták: a munkamenet hosszát az alkalmazás határozza meg - komolyabb biztonságnál egyértelműen rövidebbre érdemes venni, a php alapbeállítása (1440 másodperc - 24 perc) egy elég jó arany középút. Ritkán tartom szükségesnek állítani.
Az "emlékezz rám" megoldások nem a session idő megnövelésével működnek, hanem plusz egy sütivel, ami mondjuk él egy hétig, és egyértelműen köthető egy felhasználóhoz. Az egyszerű megoldás az, ha ennek meglétét a bejelentkező oldal vizsgálja, ha létezik és érvényes, akkor rögtön továbbít is anélkül, hogy látnád a login formot.
Előfordulhat olyan helyzet, hogy egyetlen oldalon (vagy egy páron - az alkalmazásod méretéhez képest kevés helyen) kell hosszabb munkamenet, erre egy kerülőút: egy, csak azokon az oldalakon behúzott javascript, ami párpercenként egy ajax kéréssel a háttérben életben tartja a sessiont, mondjuk ötpercenként egy kéréssel legfeljebb 12 alkalommal, az plusz egy óra. Például az említett cikkírós oldalra jól jöhet, cserébe innentől JS-függő az alkalmazásod. Mai világban nem tragédia, cserébe ne feledd figyelmeztetni az ilyenre a felhasználót egy jól elhelyezett noscript taggal.
Adatbázisban tárolás, erről megoszlanak a vélemények, kap hideget is, meleget is. Akkor tagadhatatlanul hasznos, ha több gépen elosztva van az alkalmazás egy load balancer mögött, ilyenkor kénytelen vagy valami központi megoldást használni, amúgy bőven jó a php.ini-ben beállított, általában fileban történő mentés.
IP, useragent ellenőrzés. Ismét azt mondom, hogy a szükséges biztonsági szint a fő meghatározó, de: a useragent ritkán változik, az ipvel viszont vigyázz: az országban is több szolgáltató van, aminél több user van egy ip mögött, esetleg bonyolítva azzal, hogy egy user ipje is változik kérésről kérésre attól függően, melyik proxy épp van legkevésbé terhelve.
Saját hash generálás felesleges, de amikor változik az authentikációs szint (be- és kijelentkezés, plusz jog kiadása vagy annak elvétele) érdemes egy session_regenerate_id() hívást intézni, ez elég jó védelem a session fixation támadások ellen.
-
Sk8erPeter
nagyúr
válasz Tele von Zsinór #6315 üzenetére
"cserébe ne feledd figyelmeztetni az ilyenre a felhasználót egy jól elhelyezett noscript taggal."
Pont ezt alkalmazom az egyik egyelőre csak tesztoldalamon, de időközben az jutott eszembe, hogy akkor esetleg ezt is indexeli a Google, az meg furcsán mutathat a találatoknál, hogy szerepel rajta egy figyelmeztetés arról, hogy be kéne kapcsolni a JavaScriptet, vagy olyan böngészőt használni, ami támogatja azt.
Mi a véleményetek erről?Sk8erPeter
-
Sk8erPeter
nagyúr
Előző kommentekhez hozzáfűzve:
ha már JS-függő site, és cikkírások, akkor érdemes megfontolni azt a megoldást is, amit a Gmail és pl. akár a stackoverflow is alkalmaz: levél/hozzászólás/... írása esetén időszakos mentéseket készít az addigi piszkozatról, így nem vész el az irományod. Gmailnél mondjuk meg is marad véglegesen. Felhasználóhöz kötve tehát érdemes lehet piszkozatot is készíteni bizonyos cikkekről, így később is folytatható, valamint nem vész el - legalábbis nem teljesen, ha közben lejár a munkamenet. Természetesen a legjobb megoldás az, amit mostanában Neptunnál is alkalmaznak végre, hogy a munkamenet lejárta előtt figyelmeztet annak lehetséges megújítására - ha 1 percen belül nem kattintasz arra a gombra, ami ezt elintézi neked, akkor kiléptet; na, a kiléptetés előtt lehetne közvetlenül piszkozatként elmenteni a cikket.
Manapság az AJAX-os megoldások szerintem elkerülhetetlenek, nagyságrendekkel felhasználóbarátabbá és akár programozói szempontból is kényelmesebbé tehetik az oldalakat (a programozói szopásoktól most eltekintve ).Sk8erPeter
-
Tele von Zsinór
őstag
válasz Sk8erPeter #6316 üzenetére
Lehet valamennyire trükközni a noscript tag stílusával, hogy bár a domban hátul van, előrébb jelenik meg, vagy egyéb mód növeled a hangsúlyát.
A másik hozzászólásodhoz: örülök, hogy nem csak én vagyok rendszeres stack overflow felhasználó
Egy jól összerakott oldalnál az ajax megoldás nem egyszerűsít, inkább némi többletmunkát jelent - a plusz javascript, meg annak eldöntése, a szűk tartalmat akarja-e csak a user, vagy azt az egész layouttal dekorálva. És a fejlesztés úgy történik, hogy először megírod, aztán belenyúlsz egy kicsit, hogy ajax-szal működjön. Amennyire csak lehetséges, az oldalaimon törekszem a javascript nélküli használhatóságra. -
Sk8erPeter
nagyúr
válasz Tele von Zsinór #6318 üzenetére
Ja, az ötleted jó a noscript áthelyezésére, pl. milyen jó lenne erre JavaScript használata.
Igen, én is úgy csinálom, hogy megírom először teljesen JS nélkül működőképesre az oldalt, és csak azután módosítgatom az oldalt úgy, hogy AJAX-szal is működjön. Természetesen pluszmunka, de szerintem a használhatóság miatt megéri. Pl. amikor egy form-ot küldök el, akkor engem felhasználói szemmel nagyon szokott zavarni a teljes oldal-újratöltődés. Minek, amikor csak pár adatot küldök át (ha épp nem fájlfeltöltésről beszélünk, ott felőlem lehet újratöltődés, bár a Flash-es vagy iframe-es megoldás itt is sokkal szebb) - az adatok fogadásáig meg megjelenítek egy forgolódó kis ikont, hogy a felhasználó azért tudjon róla, hogy valami tényleg történik a háttérben.
Tipikus példa lehet akár a stack overflow. Tele van JavaScriptes, AJAX-os megoldásokkal, és épp ezért kényelmes a használata. Ezért mondom azt, hogy manapság az igazán modern honlapok esetén elkerülhetetlen, vagyis inkább szükséges az AJAX használata - pusztán a felhasználói élmények növelése érdekében.Sk8erPeter
-
LW
őstag
Köszönöm.
Így már minden tisztább. Nem kicsit túl akartam bonyolítani.
Adatmegmentős dolog lehet esetleg még az, ha nem létezik munkamenet a cikk beküldésekor, akkor a login oldalnak átadja a kéréssel jött cuccokat és sikeres belépés után egyből visszadobja a POST tartalmával együtt.
Zöldfülű vagyok még, de első guglizással cURL lesz hozzá a barátom.
Na irány az iskola, köszi még egyszer.
üdv. LW -
Siriusb
veterán
Sziasztok!
Néhány kérdés:mysqli_query + mysqli_fetch_array -t érdemesebb használni, vagy a
mysqli_stmt class-t? Miért?A mysqli_stmt_bind_result - nál ha SELECT * -gal dolgoznék, tényleg minden mezőnek be kell írnom egy változót, vagy bele lehet egy tömbbre rakni az eredményt?
Esetleg épp ez az - egyik - fő különbség a két módszer között, hogy itt egyenként kell definiálni a változókat a mezőknek, így csakis azokkal az adatokkal dolgozunk, amire épp szükség van?Szerk:
csak azért, mert lustaság szempontjából az első módszer az előnyösebb[ Szerkesztve ]
-
DeltaPower
őstag
válasz Siriusb #6321 üzenetére
kb ez a különbség, amit írtál.
bind_result kódtömörítésre hasznos, pl egy objektum értékeinek feltöltésénél ehelyett$tomb=mysql_fetch_array($qry);
$this->valtozo1=$tomb[0];
$this->valtozo2=$tomb[1];
$this->valtozo3=$tomb[2];ennyit írsz:
mysqli_stmt_bind_result($qry, $this->valtozo1, $this->valtozo2, $this->valtozo3);
"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser
-
PazsitZ
addikt
válasz DeltaPower #6322 üzenetére
vagy ahelyett:
list($this->valtozo1,$this->valtozo2,$this->valtozo3) = mysql_fetch_array($qry);- http://pazsitz.hu -
-
Siriusb
veterán
válasz DeltaPower #6322 üzenetére
Köszönöm a választ mindkettőtöknek.
-
Speeedfire
nagyúr
Üdv!
Kis oop gondom van. Jelenleg a bevezetés a php5 programozásba könyvet forgatom a kezeim között, adott egy ilyen sor egy osztályon belül:
echo "Szia {$this->nevLekerdezes()}!<br />";
echo 'Szia '.{$this->nevLekerdezes()}.'!<br />';Az első sor szintaktikaileg helyes, de a másik már nem. Mi a gond vele? Illetve a {} mire való itt? A könyv erre nem tér ki...
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
M.Úr
tag
válasz Speeedfire #6325 üzenetére
Ez nem OOP gond. A sztringben található { } szerepéről itt olvashatsz bővebben:
PHP Manual: Strings (complex syntax)szerk.:
A második sorba nem kell a { }. A könyv hibája... sajnos neves könyvekben is előfordulnak hibák. Néha egész súlyosak (pl. a Sam's Advanced PHP Programming egy komplett fejezete...).[ Szerkesztve ]
-
Speeedfire
nagyúr
Még most sem jöttem rá pontosan mi az a {}, ellenben anélkül megy rendesen.
echo 'Szia '.$this->nevLekerdezes().'!<br />';A könyvben csak az első sor van, ellenben én nem így szoktam az echo-t print-et használni:
echo ""; print "";
hanem csak sima aposztrófokkal
echo ''; print '';Megszoktam már ezt a szintaktikát.
[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
M.Úr
tag
válasz Speeedfire #6327 üzenetére
Hát igen, ez ízlés és megszokás dolga. Én pl. tök logikátlanul (de legalább konzisztensen) így használom:
print "A valtozo_1 tartalma: ".$valtozo_1."<br />"; -
Sk8erPeter
nagyúr
válasz Speeedfire #6327 üzenetére
Ha sok HTML-kód kerül az outputra, nem is árt, ha az aposztrófos megoldást választod. (Jó fárasztó és csúnya escape-elni a sok idézőjelet az attribútumoknál.)
(#6329) Siriusb: állítólag az aposztrófos megoldás a kiértékelés szükségességének hiánya miatt (de jól hangzott) gyorsabb lehet, mások szerint urban legend.
Személy szerint jobban szeretem inkább összefűzögetni, és aposztrófot használni, részben a fenti okok miatt (pl. esetleges sebességkülönbség plusz HTML-kód kiíratása), részben meg amiatt, hogy így szerintem sokkal jobban elkülöníthető a kód, ha böngészgetem a kódot - még ha a fejlesztőkörnyezet ki is emeli az idézőjelben elhelyezett kiértékelendő változót, akkor is sokkal inkább egybefolyik a többi kóddal. Ráadásul tömbindexelésnél vagy egyéb esetben is szintaktikai hiba lehet belőle, az összefűzögetésnél könnyebb elkerülni (számomra).Többiektől kérdezném, ha már erről van szó:
echo-zásnál mennyire használjátok azt a változatot, hogy vesszővel elválasztva íratjátok ki a különböző változókat, sztringeket, és nem konkatenálva?
Eszerint itt is lehet sebességbeli különbség, mégpedig a vesszővel elválasztott módszer javára.
Lehet, hogy értelmesebb, mint az állítólag lassúnak számító sztring-összefűzögetés, és érdemes lenne esetleg erre a módszerre átszokni.[ Szerkesztve ]
Sk8erPeter
-
Siriusb
veterán
válasz Sk8erPeter #6330 üzenetére
Na igen, ebben egyetértek, a fejlesztőkörnyezetben az általad említett módszerrel sokkal áttekinthetőbb a kód.
-
rt06
veterán
válasz Sk8erPeter #6330 üzenetére
"Ráadásul tömbindexelésnél vagy egyéb esetben is szintaktikai hiba lehet belőle, az összefűzögetésnél könnyebb elkerülni (számomra)."
a kapcsolszarojeles megoldasnal nem - az alabbi pl szintaktikailag helyes (raadasul szamomra sokkal atlathatobb, mint a ponttal torteno konkatenacio, de ez mar izles dolga
$str = "valami{$valtozo["index"][$masikindex]}megvalami";
a vesszovel elvalasztast nem igen hasznalom (echo-t sem, print-elni szoktam, de ez leginkabb megszokas miatt van csak), sot, mostanaban egyre inkabb szokok ra a printf, sprintf hasznalatara
a sebessegrol meg annyit, hogy szerintem ugysem ezen a (talan) par tizezredasodpercen fog mulni a dolog, sokkal inkabb az adatbazislekereseken, egyeb muveleteken (es ez meg mindig sehol nincs a http kapcsolaton keresztuli kommunikacio lassusagahoz)
ha javitani akarok a kodom sebessegen, nem a kiiratas lesz az elso (sokkal inkabb az utolsok kozt), aminek nekiesek[ Szerkesztve ]
Politikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.
-
Sk8erPeter
nagyúr
Ja, most a szintaktikai hibát pont nem a kapcsos zárójeles megoldásra értettem.
Persze, nem feltétlenül pont a kiíratás milyenségén kell lefaragni, de ahol lehet sebességet növelni, ott sosem árt, főleg, ha a kényelmi szempontokat nem rontja (jelentősen).
Pl. lehet, hogy csúnya, de a kódomban sokszor keverem a statikus HTML-megjelenítési formákat a PHP-vel, pusztán sebességbeli megfontolásokból (bár lehet, hogy nem dob sokat, nem mértem), hirtelen példaként (alternatív szintaktikával):
<?php
// .....
foreach($valami as $key => $value) :
?>
<div>blabla sokszor: <?php echo $value;?>
................
</div>
<?php
endforeach;
?>Persze ezt csak akkor, ha nagyon muszáj (pl. nagyon sok kiírandó HTML-kód van), mert különben gány lesz a kód.
Nyilván mindent egybevéve kell a sebességen javítani, ahol lehet, de olykor apróságok is számíthatnak sok kicsi sokra megy alapon.Az, hogy a kiíratást valaki kapcsos zárójellel vagy egyéb módon csinálja, tényleg csak ízlés kérdése.
Sk8erPeter
-
LW
őstag
Sziasztok.
Egy érdekes anomália jött elő az este és már kezd hangulatom lenni.Egész eddig wampot használtam békében, nyugalomban. Kis keretrendszeremet fejlesztgettem és azt kezdtem észrevenni, hogy bizonyos táblákat(14ből 2) nem tudok megnézni phpmyadminban, Böngészőm fejemhez vágta, hogy Connection was reset.
Gondoltam én, velem nem szórakozik semmi, rakok fel egy EasyPHP-t is. Beállítom, működik is. Nem kelik el 2 perc, ugyan azt tapasztalom. Ugyanakkor PHPból kiadott lekérdezések probléma nélkül futnak.
A Connection was reset rendszerint akkor jön elő phpMyAdmin esetében, ha egymás után két lekérdezést(lapot váltok) hajtok végre gyorsan.
Találkozott valaki efélével?
üdv. LW -
Siriusb
veterán
Keresztkérdés:
Firefox-ban, ha úgyzárom be a böngészőt, hogy egy fülön az adott oldal nyitva van, s a böngésző következő indításakor (annak beállítása folytán) szintén ott figyel az említett oldal, a sütik, melyek csak a munkamenet végéig lettek volna érvényesek, nincsenek törölve, csak kacarásznak egyenesen a képembe. Mi erre a megoldás? -
jeges
senior tag
-
Siriusb
veterán
válasz Tele von Zsinór #6337 üzenetére
Persze, de más böngészőnél, pl. chrome nem így működik, a böngésző bezárásával törlődik a süti. Lehet ezt valahogy kényszeríteni ff-nél is?
-
Speeedfire
nagyúr
Ismét egy kis oop kérdés lenne. A könyvben adott egy kódrész:
class TulajdonsagObjektum {
private $_tulajdonsagok = array (
'nev' => null,
'szuletesidatum' => null
);
function __get($tulajdonsagnev) {
if(!array_key_exists($tulajdonsagnev, $this->_tulajdonsagok)) {
throw new Exception('Ervenytelen tulajdonsag-érték!');
}
if(method_exists($this, $tulajdonsagnev. 'Lekerdezes')) {
return call_user_func(array($this, $tulajdonsagnev . 'Lekerdezes'));
}
else {
return $this->_tulajdonsagok[$tulajdonsagnev];
}
}
function __set($tulajdonosnev, $ertek) {
if(!array_key_exists($tulajdonosnev, $this->_tulajdonsagok)) {
throw new Exception('Ervenytelen tulajdonsag-ertek');
}
if(method_exists($this, $tulajdonosnev . 'Beallitas')) {
return call_user_func(array($this, $tulajdonosnev . 'Beallitas'), $ertek);
}
else {
$this-> _tulajdonsagok[$tulajdonosnev] = $ertek;
}
}
function szuletesidatumBeallitas($szd) {
if(strtotime($szd) == false) {
throw new Exception('A szuletesi datumnak egy ervenyes naptari napnak kell lennie!');
}
else {
$this->_tulajdonsagok['szuletesidatum'] = $szd;
}
}
function koszontes() {
echo 'Szia! '.$this->nev.' vagyok! '.$this->szuletesidatum.' -an/en szulettem';
}
}
$obj = new TulajdonsagObjektum();
$obj->nev = "Szabi";
$obj->szuletesidatum = '1985. 08. 27.';
$obj->koszontes();
$obj->szuletesidatum = 'piros';A könyv szerint ki kellene írni a Szabit és a születési dátumot és utána egy hibaüzenetet, hogy a piros nem megfelelő dátum.
Ehelyett az egészet egy errorba rakja nekem.Fatal error: Uncaught exception 'Exception' with message 'A szuletesi datumnak egy ervenyes naptari napnak kell lennie!' in D:\munka\web\!!!oop\index.php:80 Stack trace: #0 [internal function]: TulajdonsagObjektum->szuletesidatumBeallitas('1985. 08. 27.') #1 D:\munka\web\!!!oop\index.php(71): call_user_func(Array, '1985. 08. 27.') #2 D:\munka\web\!!!oop\index.php(94): TulajdonsagObjektum->__set('szuletesidatum', '1985. 08. 27.') #3 {main} thrown in D:\munka\web\!!!oop\index.php on line 80
php 5.3.0 van fent.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
jeges
senior tag
válasz Speeedfire #6339 üzenetére
uncaught exception -> nincs try/catch, ami elkapja
szerk: nézd meg itt
[ Szerkesztve ]
-
Speeedfire
nagyúr
Akkor már tudom Sk8erPeter mire célzott a gányolt kóddal...
Így módosítottam a végét, de csak a hibát írja ki. A helyes részt nem, pedig az 1985.08.27. helyes dátum formátum elvileg.
try {
$obj = new TulajdonsagObjektum();
$obj->nev = "Szabi";
$obj->szuletesidatum = '1985. 08. 27.';
$obj->koszontes();
$obj->szuletesidatum = 'piros';
}
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
}Caught exception: A szuletesi datumnak egy ervenyes naptari napnak kell lennie!
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
jeges
senior tag
válasz Speeedfire #6341 üzenetére
szerintem próbáld külön a köszöntésig egy ciklusba (megjegyzem, logikailag nekem egyébként is az tűnik egy teljes ciklusnak), meg a végét (ami hibás) egy másik try-catch-be
szerk: így valahogy:
$obj = new TulajdonsagObjektum();
$obj->nev = "Szabi";try {
$obj->szuletesidatum = '1985. 08. 27.';
}
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
} if (!isset($e)) {$obj->koszontes();}try {
$obj->szuletesidatum = 'piros';
$obj->koszontes();
}
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), "\n";
} if (!isset($e)) {$obj->koszontes();}[ Szerkesztve ]
-
Speeedfire
nagyúr
A könyv végére sírni fogok ezektől a dolgoktól...
Kivettem a piros részt is és így it hibát ír ki, szóval máshol lesz a gond szerintem. Heggesztem még a kódot, de így kicsit ciki ha már a könyvben sem jól van írva...
Ha ezt átírtam true-ra akkor jó volt.
if(strtotime($szd) == false) {[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
jeges
senior tag
válasz Speeedfire #6343 üzenetére
próbáld meg a dátumot így: 1985-06-27
és írd vissza false-ra, mer' az strtotime() == false a hibás
(azaz szerintem nem volt jó true-val, csak nem dobott hibát - ez a kettő jelen esetben nem ugyanaz) -
jeges
senior tag
válasz Speeedfire #6345 üzenetére
a php számára ez nem dátum, hanem egy "sima" string. bizonyos formátumokat felismer, másokat Neked kell megmutatni a programnak. php manual-ban le van írva, bár nem a legvilágosabb része a dokumentációnak. a yyyy-mm-dd formátum jó szokott lenni.
-
Speeedfire
nagyúr
Akkor a könyvben nem értem miért így volt.
Illetve ezt sem pontosan értem:
return call_user_func(array($this, $tulajdonosnev . 'Beallitas'), $ertek);
return call_user_func(array($this, $tulajdonsagnev . 'Lekerdezes'));Itt a Beallitas és Lekerdezes sztingeket mire használja?
[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
j0k3r!
senior tag
-
jeges
senior tag
válasz Speeedfire #6347 üzenetére
ezt így "látatlanba' " nem könnyű megmondani.
az első valamely class egy példányának (ő lenne a $this) a "$tulajdonosnev" metódusát hívja meg a "Beallítas" paraméterrel. Feltételezem, hogy a tulajdonosnév eljárás machinálására szolgál, és az adott paraméterrel a tulajdonosnév beállítása történik meg. A második hasonló. (nincs elírva az első soron a tulajdonos? inkább tulajdonság lehet, nem?)joker: #6325-ben a válasz
[ Szerkesztve ]
-
Speeedfire
nagyúr
Bevezetés a php5 programozásba. Igazából az oop miatt érdekelt a könyv, azt írták sokan, hogy nagyon jó...
jeges:
De igen, el lett írva. Ellenben én nem nagyon látom ilyen opciókat, jobban mondva nem látom értelmét ezekenk a kifejezéseknek a függvények szempontjából.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
Új hozzászólás Aktív témák
- Az iPadOS-re írt appokra is díjat vet ki az Apple
- Amlogic S905, S912 processzoros készülékek
- Path of Exile (ARPG)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Építő/felújító topik
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- Mindent megtudtunk az új Nokia 3210-ről
- sziku69: Fűzzük össze a szavakat :)
- Sony MILC fényképezőgépcsalád
- További aktív témák...
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen