Új hozzászólás Aktív témák
-
Speeedfire
nagyúr
válasz PazsitZ #9898 üzenetére
Én is használom, de csak egyszerűbb dolgokra. Amit te is írtál. Ilyen összetettet már inkább if else ágba rakom. Jobban átlátható a dolog. Legalábbis számomra.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
válasz Peter Kiss #9899 üzenetére
"Királyság", de nem abban a formában, ahogy írták abban a kódban, amit Speeedfire itt "idézett".
Sk8erPeter
-
cass
aktív tag
Sziasztok! Lehet, hogy rossz helyre írok, de szerintem itt vannak az ilyen programozó zsenik akik segíthetnek nekem. Először is egy IP címet szeretnék megtudni egy darab e-mail alapján. Az illető után szeretnék egy kicsit nyomozni. Ha megvan az IP cím onnan meg ki lehet valahogy szerintem deríteni, hogy milyen oldalakat látogat. Javítsatok ki ha tévedek nem értek hozzá. Előre is kösz a segítséget!
Ha szemmel mindent el lehetne intézni, az utcákon csak halottak, és terhes nők lennének.
-
cass
aktív tag
Na az IP cím már megvan, ezzel most mit tudok kezdeni? Valahogy nem lehet kideríteni, hogy hova regisztráltak vele, vagy milyen oldalakat látogattak?
Ha szemmel mindent el lehetne intézni, az utcákon csak halottak, és terhes nők lennének.
-
Speeedfire
nagyúr
Szerintem ezt így nem fogod tudni.
Más:
Adott egy ilyen kód:<?php
class IsAdmin{
public static function isAdmin() {
if(Yii::app()->isGuest) {
return false;
} else {
$user = User::model()->findByPk(Yii::app()->user->id);
if($user->admin == 1) {
return true;
} else {
return false;
}
}
}
}Megszeretném hívni, de nem akarja...
IsAdmin::isAdmin();Ezt kapom rá. A 16. sor meg a fájl vége.
Fatal error: Constructor IsAdmin::isAdmin() cannot be static in on line 16
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
válasz Speeedfire #9905 üzenetére
http://the-echoplex.net/log/php-case-sensitivity
class constructors - ez is case insensitive. Régebben meg ugye az volt a módi, hogy a konstruktor neve egyezik az adott osztály nevével. Most már a "mágikus" __construct()-ot érdemes ugye használni. Na de ettől függetlenül működik a régi módszer is.
Röviden: konstruktornak minősül, mert azonos a neve az osztályéval (case insensitivity), konstruktor meg nem lehet statikus (ahogy a hibaüzenet is elmondja).
Megoldás: adj más nevet a metódusnak, és annyi.Szerk.: jé, most lettem "PH! nagyúr". Ezt is megértem. Mindenki vendégem egy virtuális sörre.
[ Szerkesztve ]
Sk8erPeter
-
Speeedfire
nagyúr
válasz Sk8erPeter #9906 üzenetére
Na, ma is tanultam valami.t
Köszi.Stewie a nagyÚr, te Chewbacca vagy!
Grat!Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
-
válasz Speeedfire #9905 üzenetére
Ha már a kód szépségéről volt szó:
<?php
class Auth{
public static function isAdmin() {
if(Yii::app()->isGuest) {
return false;
}
$user = User::model()->findByPk(Yii::app()->user->id);
return $user->admin == 1;
}
}Persze ez a statikus összehányás nem jó ötlet.
-
Speeedfire
nagyúr
válasz Peter Kiss #9909 üzenetére
Az utolsó mondatodat nem értem, miért nem jó ötlet és miért hányás?
A kód amit írtál meg teljesen jogos.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
válasz Speeedfire #9910 üzenetére
Static dolgok használata könnyen gyorsan spagetti kódot eredményez, fogalmad sem lesz, mi zajlik a rendszerben, tesztelhetőségről ne is beszéljünk.
A másik, hogy ha ezt a kérés során folyamatosan használod mondjuk 5 alkalommal, akkor ötször fog ez így lefutni?
Kódírás folyamán mindig érdemes lefektetni pár szabályt, amit betartasz, pl.:
static változóba nem rakok semmit, ami állapotot tárol (singleton is kinyírva)
static csak olyan lehet, ami valamilyen service-szel kapcsolatos (nálam ilyen a Path osztály, ez csak a mappák, fájlok neveit machinálja string-ként, az IsAdmin cuccod ilyesmi, de rossz a megközelítés*)Ezeket igyekszem mindig betartani, de a saját kis reflection kiegészítésem miatt én is tárolok dolgokat static változóban, de azok nem is változnak, amíg az osztály maga nem változik meg. Érdemes úgy tekinteni a static elemekre ilyen szempontból, mintha a PHP nem shared nothing elveket vallana.
---
Static cuccokkal van olyan gond, hogy simán keresztülhúzod az OO elveket. Most egy felhasználóról akarod megmondani, hogy admin avagy nem admin úgy, hogy gyakorlatilag kiszeded az egészet a rendeltetési helyéről, hiszen maga a User meg tudja mondani magáról az-e, ahogyan ez látszik is.
A kereted ad hozzáférést egy user nevű field-hez, az mi? Nem tudod egész véletlenül megmondani a rendszernek, hogy oda egy profibb objektumot toljon be? Mert akkor ennyi lenne: Yii::app()->user->admin; és nincs ez a static borzalom benne a rendszerben.Maga a design is lehet rossz: nem egy bit kell arra, hogy admin-e, hanem hegeszteni kell olyan Role rendszert, amibe ezt szépen bele lehet kódolni.
---
Én is használtam Singleton-t, de utána alig bírtam kiírtani a rendszerből, nagyon rossz ötlet. Nem tudom, mennyire jött át a dolog, de ha most nem, majd rájössz.
[ Szerkesztve ]
-
PazsitZ
addikt
válasz Speeedfire #9905 üzenetére
Ha már bejelntkezett userről van szó miért nem állítod be belépéskor a setState-el hogy a user isAdmin true vagy false. Bár ekkor még implicit nincs lekezelve a belépett kilépett kérdés, de jobb esetben ezt önmagában rbac szabályokkal gondolom lekezeled a controller hívás előtt.
Jah most olvasom csak végig, hogy gyakorlatilag Athlon64+ is ezt javasolja.
(#9911) Athlon64+:
Azért a singleton se ördögtől való dolog.[ Szerkesztve ]
- http://pazsitz.hu -
-
Sk8erPeter
nagyúr
válasz papa019 #9868 üzenetére
Hátha másnak is hasznos lesz, közben privátban megoldottuk a dolgot, olykor a MultiViews letiltása csodákat tesz.
Példa, ami itt többek közt a problémákat okozta: megnyitottuk az example.com/xyz címet, de közben aktív RewriteRule is volt, plusz MultiViews bekapcsolva, de eközben - mint kiderült - volt a gyökérkönyvtárban egy xyz.php fájlunk is, így az example.com/xyz betöltésére egyből 500 Internal Server Errort kaptunk. A MultiViews bekapcsolt állapota esetén egyébként elkezd az Apache kutakodni a megfelelő kiterjesztésű fájlok után: [link]..htaccess-ben:
Options +FollowSymLinks
HELYETT:
Options +FollowSymLinks -MultiViews... és máris nem volt 500-as error.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Peter Kiss #9911 üzenetére
"Yii::app()->user->admin; és nincs ez a static borzalom benne a rendszerben."
De még mindig ott a public static function app().Sk8erPeter
-
Speeedfire
nagyúr
válasz Peter Kiss #9911 üzenetére
Ezt a staticet nem sűrűn használom, csak ha valami egyszerű értéke van csak. Igaz/hamis vagy ha esetleg szám, mint pl a user id.
Alapvetően én is példányosítok.A role based nem rossz dolog, de ennyire még nem ástam bele a témába magamat sajnos. Pedig kellene, drupalban szerettem.
A user modul is megtudja mondani végül is, de modulban is meg kellene néznem még, hogy nem-e guest. Így meg egyszerűbbnek tűnik.
PazsitZ: Az a baj, hogy ez a controller access részénél használom az expression részéhez, mivel még nincs meg a rb dolog. Oda meg hiába írom meg a setState részt, mert ugye attól még nem tudom, hogy guest vagy sem az illető.
De lehet ma nekiesek ennek a rb dolognak és megoldom azzal.
Igazából csak 3 kellene a mostani dologhoz.
guest, authenticated és adminFotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
válasz Sk8erPeter #9914 üzenetére
Igaz, de azzal nem fog tudni mit kezdeni.
---
@Speeedfire
Az egyszerűbb út csalóka. Cégnél is azt választották mindig, egy DLL kódját már több, mint egy hete hegesztem, hogy kimossak mindent a szarból (abban pl. mindig ilyenek voltak: [akármilyen]DAL.Instance(), pff (mindez mint metódushívás paramétere is akár)). -
válasz PazsitZ #9912 üzenetére
A Singleton anti-pattern, tesztelhetetlen alkalmazást eredményez, illetve fogalmad sem lesz arról, hogyan működik az alkalmazás.
Elég csak arra gondolni, mi van akkor, ha kapsz egy egyébként működő kódhalmazt, amit használni szeretnél, de rejtett dependency-k vannak benne a singletonok miatt. Sosem szabad ilyet csinálni.
Példa:
<?php
/* ... */
$controllerFactory = $this->_controllerBuilder->GetControllerFactory($this->HttpContext);
$controller = $controllerFactory->CreateController($this->HttpContext);
if (!$controller->GetType()->ImplementsInterface("\\System\\Web\\Mvc\\IHttpHandler") || !$controller->IsStateLess()) {
$sdsf = new SessionProviderFactory();
$this->SessionManager = new SessionManager($this->HttpContext, new UsersAndGroupsDataContext(), $sdsf);
$this->SessionManager->Validate();
$this->HttpContext->Session = $this->SessionManager->GetCurrentSession();
}
if (!$controller->Execute($this->HttpContext, $this->_actionInvokers->GetActionInvoker(typeof($controller)))) {
throw new \Exception("Failed to execute action: " . $this->HttpContext->Route());
}
/* ... */Itt mondhatnám én is a $this->HttpContext átadása helyett, hogy akkor HttpContext::Instance() az egyes helyeken (kihagyva a metódusok paraméterlistájából), mert itt ugyanazt jelenti, de azt eredményezné, hogy még számomra se lenne világos, minek mire van szüksége.
A példában szereplő if block egyébként még javításra szorul.
-
Speeedfire
nagyúr
válasz Peter Kiss #9916 üzenetére
Lehet, hogy csalóka. De mi számít akkor ezekben az esetekben?
Átláthatóság? Sebesség? Továbbfejlesztés? Vagy miért nem "előnyös" a static és a singleton?Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
válasz Speeedfire #9918 üzenetére
A felsoroltak közül az átláthatóság és a továbbfejleszthetőség a fontos, de már említettem azt is, hogy nem tesztelhető a logika, valamint felborítja az OO elveket némileg*.
*Attól, hogy valaki osztályokat ír, még nem feltétlenül fejleszt objektum-orientált módon. Tudom, én is bejártam az utat.
-
Sk8erPeter
nagyúr
válasz Peter Kiss #9919 üzenetére
Találtam egy jó összefoglalót arról, hogy miért is NEM feltétlenül indokolt a Singletonok használata (amiről tulajdonképpen Te is beszélsz):
http://gooh.posterous.com/singletons-in-php
"Singletons are not unique snowflakes
In languages where objects live in an application server, Singletons can be used to keep memory usage low. Instead of creating two objects, you reference an existing instance from the globally shared application memory. In PHP there is no such application memory. A Singleton created in one Request lives for exactly that request. A Singleton created in another Request done at the same time will still be a completely different instance. And it will occupy it's own memory. Those instances are not linked to each other. They are completely isolated, because PHP is a Shared-Nothing architecture. You do not have one single unique instance, but many similar instances in parallel processes. Thus, one of the two main purposes of a Singleton is not applicable.Don't construct twice, it's all right
Advocates of the Singleton in PHP often argue it's still useful to be able to limit an instance within a single request. The aforementioned database classes being the most prominent example. But the much easier solution would be simply not to instantiate a second instance. If anyone can make sure there is just one instance, it's the developer. If you need to have the same instance in many classes, use Dependency Injection. Just create one, inject everywhere. That will also save you the hassle of deconstructing your Singleton once you notice you need a second instance of it all of a sudden.
Another example where Singletons are often applied but don't make sense is classes like FrontControllers. While conceptually it makes sense to say "There may be only one FrontController", it is superfluous to ensure it from an architectural viewpoint. A FrontController is usually instantiated only once in your application's control flow anyway. If you don't write a new Foo; anywhere else, you already made sure there is just one instance. So you ain't gonna need the Singleton here. Don't express concepts in your code that are never used.Don't shoot yourself in the foot
The Singleton's other purpose (to have a global access point to the instance) is undesirable in PHP. The desire for that usually stems from having an architecture where objects pull in their dependencies. Like any globals and statics, the Singleton's getInstance() method creates coupling to the global scope. This makes Unit-Testing harder. There is ways to mitigate this, but in general, the cost to mitigate is higher than to simply avoid the Singleton in favor of Dependency Injection. This is especially true in those situations, where the Singleton is applied but never instantiated twice anyway."Itt van egy hosszabb témázás magyarul erről:
http://weblabor.hu/blog/20100727/php-egyke-ososztaly============
Hadd mondjak ellenérvet is (már úgyis megszokhattátok, hogy ez a rész is mindig jön a hsz.-eimben ):
[link]
Pont ez jutott nekem is eszembe elsőként, amit itt írnak az elfogadott válaszban, hogy pl. egy Logging class esetén tipikusan jól használható egy Singleton osztály, mert ott felesleges tesztelésekről beszélni (valszeg nem a naplózásért felelős osztály a legfontosabb, amit tesztelni kellene), plusz teljesen elfogadható lehet ennek a mintának az alkalmazása, mert más módon szépen összehozni a rendszerrel feleslegesen macerás lehet.Saját példa az, hogy bizonyos esetekben csak nagyon macerás módon, adott esetben a teljes rendszer újratervezésével lehetne normálisan beépíteni a rendszerbe egy több helyen szükséges változó Singleton nélküli használatát - tipikusan olyan rendszerekre gondolok, ahol jelenleg még nem elsősorban az OOP-szemléletet követik, hanem egyelőre inkább globális függvényekét (bár van elmozdulás az OOP irányába): mint a Drupal.
Más megoldás nyilván a globális változók használata, ami tulajdonképpen hasonló lehet a Singletonokhoz, de kicsit mégis más. Pl. Drupalnál szükségem volt már ilyenre: [link].A másik: csak hogy egy kicsit pontosítsunk, a Singleton-osztályok használata elsősorban PHP-nél felesleges. Aztán más nyelveknél vannak bőven kivételek, mint pl. egy ablakkezelő objektum használata.
Ettől függetlenül tényleg fennáll, hogy a lehető legritkább esetekben szabad használni, alapvetően a már említett szempontok miatt kerülendő. Főleg PHP-nél (lásd az idézett cikket).
===
DE további ajánlott linkek:
http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletonsSk8erPeter
-
válasz Sk8erPeter #9920 üzenetére
Singleton-t még logger osztállyal sem használnék. Van mindenre sokkal okosabb és jobb megoldás, erre pl. egy service locator lenne az egyik (e mögé be lehet tenni, hogy csak egy instance lehet mindig, de ki hogyan szereti) lambdákkal. Ez egyébként nagy királyság, a már említett DLL-ből kintre csak ennyi látszik: DLL.GetService<TService>();
-
Sk8erPeter
nagyúr
válasz Peter Kiss #9921 üzenetére
Várj, most PHP esetén milyen dll-ekről beszélünk?
"Lambdákkal"? Lehet, hogy sok volt a mai utazás, és fáradt vagyok, de most nem esik le.
Service locatorről fogalmam sincs, nem használtam még, de erről ezt találtam (nem javasolja).
Mivel már idekevertük a szezont is a fazonnal (dll-ek?), nem vágom, egyáltalán PHP keretein belül beszélünk-e a Singleton osztályok létjogosultságáról.Én szimplán azt állítottam, hogy pl. egy Logger osztálynál teljesen megfelelő megoldás egy Singleton használata, statikus metódusokkal, hogy mindenki hozzáférjen, tök felesleges bonyolítani egy ilyen osztályt. Mindent lehet még nyakatekertebben is megoldani, hogy aztán arra recskázhasson a fejlesztő, hogy ő milyen ügyes volt, de vannak esetek, amikor tökéletes időpocsékolás ilyennel rajoskodni.
Sk8erPeter
-
Tele von Zsinór
őstag
válasz Sk8erPeter #9922 üzenetére
A service locator patternre hozott példát, hogy hogy működik ez .NET alatt. Feltételezem, a kód C#-ból van, ott van ilyen szintaxisa a template-eknek. Első ránézésre valahol a Factory és a Dependency Injection keverékének tűnik.
Lambda, vagy más néven névtelen függvények. A php világban leginkább closure néven ismertek.
Becsatlakozva kicsit az épp folyó témába: nagyon sokáig használtam én is singletonokat, leginkább a már említett adatbázis-kapcsolat miatt, mert hogy abból legfeljebb egyet akarunk egy request során. Aztán amikor elkezdtem belemászni a tesztelésbe, meg láttam, mennyire is nehéz az ilyenekre épülő kódhoz unit testet írni (avagy: lehetetlen), gyorsan leszoktam róla.
Jelenleg a Dependency Injection a leginkább használt mintám, erre egy gyors és könnyen érthető megvalósítás a Pimple. Pár sorral megoldható, hogy a $app["log"] első híváskor példányosítsa a logger osztályt, a többi meg ugyanazt kapja vissza - mock osztályokkal innentől nagyon könnyen tudom például azt tesztelni, hogy egy service x függvénye y paraméterekkel meghívja-e annyiszor a loggert, ahányszor kell. Analóg módon az adatbázist (mondjuk $app["db"]) is le tudom cserélni a tesztek alatt egy erre tökéletes (akár tömbökkel működő) implementációra, amivel pontosan azt tudom tesztelni, amit akarok: a controllereimet.
És ez csak a felszín. Nagyon érdemes utánaolvasni részletesebben, kezdésnek Fabien Potencier cikksorozatának első két részét ajánlom.
-
válasz Sk8erPeter #9922 üzenetére
IoC-nál jobb a DI, de egy DLL-t elég nehéz bootstrapelni.
A tervezési minták átívelnek a nyelveken. -
CSorBA
őstag
Off:
Tudna nekem valaki mondani nyílt forráskódú, de nem ingyenes CMS-t?
-
Sk8erPeter
nagyúr
válasz Tele von Zsinór #9923 üzenetére
"Feltételezem, a kód C#-ból van"
Igen, rögtön gondoltam, de nem igazán volt világos, hogy ez most hogy jön ide, PHP-s témához, amikor kizárólag a PHP-re jól alkalmazható, itt érvényes mintákról beszéltünk korábban.
Éppen ezért mondtam, hogy most fel lehetne ilyen alapon hozni Singletonra az ablakkezelő objektumokat is, de mivel ilyen PHP-nél nincs, tök felesleges ilyenről beszélni.Lambda: jahh, oké, closure néven oké, most már ezen a néven is.
Ja, eddig is világos volt, hogy miről beszél, hogy nehéz hozzá unit testet írni. Én viszont azt mondtam, hogy vannak esetek, amikor erről felesleges beszélni, pl. most egy naplózó osztály esetén nem biztos, hogy valaki hatalmas bűnt követ el, ha nem passzolgatja inkább a controllereknek a már létrehozott példányt, hanem használ egy nyamvadt singleton-példányt, azt' kész.
Van, amikor úgy logikus, hogy 1 példány legyen valamiből, és azt csak macerás passzolgatni össze-vissza, ezért jól jön néha a Singleton minta, ennyit állítok. Aztán ha már unit testekről van szó, nyilván át kell gondolni, hogyan lehet ezt átvariálni.Egyébként az adatbázis-kapcsolódáshoz nem biztos, hogy egy request során csak egyet akarunk, ezért nem is biztos, hogy olyan jó "klasszikus" példának a Singleton alkalmazására, mert elképzelhető, hogy valaki egy request során több adatbázishoz is szeretne csatlakozni.
===================
(#9924) Athlon64+ :
ezek szerint elbeszélünk egymás mellett, nem értetted meg, miről magyaráztam. Most itt fentebb leírtam még egyszer. PHP-ről beszélünk, könyörgöm, ne keverjük már ide a C#-ot, meg a többi nyelvet, mert nyilván nagy különbségek lehetnek."A tervezési minták átívelnek a nyelveken."
Nem mondod komolyan, TÉÉÉNYLEEG??
Azért ne nézd már hülyének az embert. Inkább próbáld megérteni, miről beszél. Pl. arról, hogy attól még, mert mondjuk van értelme ablakkezelő objektumról beszélni egy másik nyelv, más jellegű felhasználása során, attól még nem biztos, hogy hasonló minta alkalmazható egy nyomorék PHP-s webalkalmazás esetén.[ Szerkesztve ]
Sk8erPeter
-
CSorBA
őstag
válasz Sk8erPeter #9928 üzenetére
Én egy komoly e-learninges (itfactory, netacademia szerű) anyagra számítottam, ennek fényében lepődtem meg
-
Sk8erPeter
nagyúr
Hát ahhoz képest ez egy lószar, csak egy kiscsávó próbál másokat oktatni, végül is nagyon kezdőknek lehet, hogy van benne hasznos infó, franc tudja, bár én más módszerrel kezdeném, igazából kezdőknek nem igazán értem, mi a francnak kéne a settype függvény például...
Sk8erPeter
-
Sk8erPeter
nagyúr
Úgy tűnik, sikerült felfedezni egy érdekes hibát a PHP beépített dátumkezelő függvényeivel kapcsolatban: [link]
A lényeg: ma ugye május 31 van, lekértem a köv. hónap napjainak számát, 31-et ír, miközben június hónap 30 napból áll csupán. A másik: a mostanihoz képest plusz egy hónapra július 1-jét írja (07-01), pedig annak június 30-ának kéne lennie (06-30).
Úgy tűnik, már Rasmus is írt a problémáról, trükközni kell azzal, hogy adott hónapban 15-e utáni dátum legyen, ahhoz képest legyen számolva.Hát ez elég gáz, nem értem, eddig hogy nem sikerült ezt kijavítani. Én most konkrétan PHP 5.3.8-at használok.
Sk8erPeter
-
PazsitZ
addikt
válasz Sk8erPeter #9932 üzenetére
Valóban érdekes probléma
$date = new DateTime();
$date->modify('last day of next month');
$nextMonth = $date->format('Y-m-d H:i:s');
$nextMonthLastDay = $date->format('d');
echo "$nextMonth";
echo "$nextMonthLastDay";Ha $date->modify('1 month'); kódot próbálod az feltehetőleg az aktuális/kiinduló hónap napszámát adja hozzá, ami 31 így produkál 7. hónap elsejét, aminek azután a napszáma már ugye 31.
[ Szerkesztve ]
- http://pazsitz.hu -
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #9932 üzenetére
Na várjunk, most fogom fel a tweet lényegét:
első:
http://twitter.com/rasmus/status/208157669452816384
második:
http://twitter.com/rasmus/status/208160760302538752Ezek szerint a PHP a GNU date-et használja, tehát igazából nem a PHP sara ez, hanem a GNU date függvényé?
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #9935 üzenetére
Mondjuk igazából a saját témaköröm inkább arról szól a Stack Overflow-n, hogy a plusz egy hónap miért viselkedik ilyen érdekesen, nem is annyira fókuszál konkrétan a hónap utsó napjára, csak hogy miért b@szódik el, ha 31-én hozzáadok egy hónapot, most jövök rá.
De ez mindenképp nagyon hasznos segítség volt.Az is igaz, hogy azt mondjuk lehetne csekkolni, hogy amennyiben ez a hónap 31 napból áll, és épp 31-e van, akkor másképp viselkedjen, konkrétan így, ahogy mutattad, és akkor ezt a kódot már fel lehetne rakni SO-ra.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #9936 üzenetére
Érdekes, hogy MySQL-ben ezt meg tudták oldani rendesen...
SELECT NOW( )
2012-05-31 17:51:15SELECT DATE_ADD(NOW(), INTERVAL 1 MONTH)
2012-06-30 17:51:15Ahogy ez is jó:
SELECT DATE_ADD( '2013-01-30 17:51:15', INTERVAL 1 MONTH )
2013-02-28 17:51:15[ Szerkesztve ]
Sk8erPeter
-
Mad_nv
csendes tag
Hello!
A napokban úgy döntöttem, hogy már nem Notepad++ -ban írom a PHP kódot, hanem Netbeans-ben (7.1.2), mert abban lehet debugolni (kiegészítővel), és egyéb kényelmi funkciókkal is rendelkezik. Feltettem hát az xDebug 2.2.0 progit, beállítotam a PHP-t is (PHP 5.3.8, XAMPP). Írtam egy rövid próba kódot, szépen megáll a breakpointoknál, sőt a változók értékeit is folyamatosan nyomon követi. Már azt hittem tökéletesen működik, de az outpot nem jelenít meg semmit egészen addig amíg véget nem ér a kód.Írtam egy példaprogramot az output tesztelésére:
echo '1';
echo '2';
echo '3';
phpinfo();
echo '4';
echo '5';Ennek az az érdekessége, hogy az echo 1-2-3-nál nem jelenik meg semmi debugolás alatt mikor odaérek(sem az output ablakban, sem a böngészőben), viszont a phpinfo() kimenete azonnal látszik, majd a 2 utána jövő echo kimenete szintén nem látszik, csak ha már véget ért a futás.
Kérdésem az lenne, hogy ez normális működés szerintetek, vagy valami bug az xdebugban?
Nem találtam választ sehol erre sajnos. Az xdebug logja nem ír semmi féle hibaüzenetet egyébként. -
-
modder
aktív tag
ha még mindig nem megy, próbáld meg a webszerveren állítani az output buffert
pl Apachenál SendBufferSize 0Amúgy ha apache modulként van fönt a PHP, el tudom képzelni, hogy automatikusan flusholja az apache output bufferét is. (nálam működött ez annó). Ha nem apacheot használsz vagy fastcgi van, akkor lehet, hogy nem ilyen egyszerű a helyzet. mindenképpen nézz utána a webszerver output bufferének is.
(sőt, akár még a böngésző is bufferelhetni, azt mondják )
[ Szerkesztve ]
-
Mad_nv
csendes tag
Megpróbáltam, hogy az egyik echo után meghívtama flush() függvényt, de az outputon továbbra sem jelent meg semmi. A php.ini-ben átírtam ezeket: implicit_flush = On
output_buffering = 0, de semmi eredmény (természetesen az apache-ot újraindítottam az ini módosítása után). Nem tudom, hogy a phpinfo() függvény hogy éri el, hogy azonnal kiküldje az outputra az adatokat. Sajnos az általad javasolt SendBufferSize értéket nem tudtam módosítani, ugyanis nem nagyon értek az apache-hoz, azt sem tudom, hogy az XAMPP alatti változatnak, van-e valami konzolja, amin keresztül módosíthatnám.
Új hozzászólás Aktív témák
- HiFi műszaki szemmel - sztereó hangrendszerek
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Politika
- Jövedelem
- LG C3: egy középkategóriás OLED tévé tesztje
- Vírusirtó topic
- Xbox Series X|S
- Samsung Galaxy A54 - türelemjáték
- sziku69: Szólánc.
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...
- Ej-Ha! Lenovo ThinkPad P53s Szép Home & Business Laptop -70% 15,6" i7-8665U 16/512 Quadro P520 2GB
- Új Lenovo ideapad 5 Pro Prémium Ultrabook 14" -30% Bivaly Ryzen 5 5600U 8GB 512GB 2,2K RADEON 2GB!!
- iPhone 13, 128GB, starlight, kártyafüggetlen, 88% akku
- Tyű-ha Lenovo Thinkpad T15 "Golyóálló" Üzleti Laptop 15,6" -50% i7-10510U 4Mag 32GB/512GB FHD IPS
- Új 2K AM5 Gamer PC R5 7600/RTX 3070 8Gb/2X8Gb 6000Mhz DDR5/500Gb SSD M2/700W 2Év gari
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest