- Garmin topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Yettel topik
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- Milyen okostelefont vegyek?
- Samsung Galaxy A55 - új év, régi stratégia
- Samsung Galaxy S23 Ultra - non plus ultra
- One mobilszolgáltatások
- Elkészült és telepíthető az Android 16
- Mobil flották
Új hozzászólás Aktív témák
-
#12200
mobal
nagyúr
Sk8erPeter
#12199
válasz
Sk8erPeter
#12199
üzenetére
Szerveroldalon: készítek egy bélyegképet, majd konvertálom jpg -re megadott mérettel és mentem, továbbá regisztrálom az adatbázisba!
Köszi, ez a reguláris kifejezés tökélete!
mobal,
-
#12198
mobal
nagyúr
Sk8erPeter
#12197
válasz
Sk8erPeter
#12197
üzenetére
Képfeltöltéshez kell. Ugye elpostázom a base64 kódolt "képet", majd feldolgoznám!
-
#12197
Sk8erPeter
nagyúr
mobal
#12196
Sk8erPeter
nagyúr
És ennek mi lenne a lényege?
itt van egy példa, itt tesztelheted:
http://preg_replace.onlinephpfunctions.com/minta:
/data:image\/(jpeg|jpg|png|gif|bmp);base64,/kód:
$pattern = '/data:image\\/(jpeg|jpg|png|gif|bmp);base64,/';
$replacement = '';
$subject = 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAUUAAAEyCAYAAABtU8IkAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9kLDAkfAXFvbGkAACAASURBVHja7L1pjLRdeh50nXOepaq73+/7Zsafx7GCnR9ICJIIsciISBECQZzEa2awx4sAy2Ds8Sz2OPxACigRP5ATLE88tuPxgmI7Nt7HIzKOAQsF4gghEIsIiCUoDrHjxJOZb3nf7q56lnMOP6ru+q666zzVVd1P11tVfW6p1d21PMt5zrnOvV43kCVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsmTJkiVLlixZsjwF+QoAvw7gcwA8gBsA/yeAH89Dk+XIJKqfLFlGl29PTDT5+V/z8GTJoJjlqcn/tQUUfyoPT5YMilmemrRqkv1JACWA1wC8Nw9PlgyKWU5FzIiT7DGOmyXLY4Finq9ZkmJH2nG37cRaXgPw7wH4GwDeANAvf/8mgO8B8GyPHf49AD4D4BaLAM+PJr7zVVgEgORc/xDArwD4lxOf/Tp1/J8YuI6fUJ/7ugee9yH395TlnwTwYwD+9nKMegCfB/DfA/gzd8ylXWTMuQoAXwbglwB8dmld/R0A3wfg3Xdcx33mUpYjMUPiHabJVy4nxLbP/y6Af2nH8/1V9f//RJ91AH7yjnN9XB3/AsA1vf+/D1zH/0GfuVl+7yHnvc/9PXX5agDzO8b5bwP4ffc0n8eeq9+NRVbG0HWmgPEhcynLCYDin1jucrt8Zz4w2bZ95wWA/4g++xd2PNe/r87x8/ReAPBqQnsI9JlfVO/f97z73t9Tli8G8PaO4/zj9wDFx56rqZ/vTRzjIXMpy5GBo5ZXlio/f+bXAPxhAPXy968nduFnd5xnDuDrAUzU5/4JBVy/B+BfBVAB+KMAfofeu8V6MOh96hx/TB37y7eYzg857z73d3x+GGt3WvzOudXfy+/cR76Xjvk/A/insQjsfQmAX0hoYfvM18eaqx2A7wRwCeAfB/A/qPf/1ohzOMsJgOLH1Pu/uTQNWAoA/5363J++4zxDpsP3qc99o3r/a9T730PvTQA8p/f+rPrun9tiOj/kvPvc38HBriiKJLANAd5dP8aYh0SA/1/63j+r3vsSddybPefrY81VreX/0YQlgBHnUpYjB8W/qd7/ioHjfJX63N+84zz/ysBx/kf1Oe1XukpoAiw/S+/9F+q9/5Le+6WRz7vr/R30eQogMpAJWMprCZC7ExAT2uUoOK6OGfacr481V/+gev9d6n0/8lzKcuSgqP0/7xk4zheoz715x3m+dOA4b+zpz/mtLbvwm3gnZcMAeIve+/qRz7vr/Y0uZVluAFZd14NAxiC4DyBqMJTvkpZ5H/l9WARevhfA/7bDfNz2/mPN1VcS2ua263joXMpy5KCondZu4Dh6ovR7TjSRbs8Jdau+X6vF8YeXr/9B9Z3Lkc+76/2NZhqzWTwEevKZlCmt39tFQggxhJAE3OXfu8h7APzHAP4f7JcBcdd8fay56va8jofOpSxHDoqf33H3fV197vN3nKcYOM7zPSdUysT66YQ/6KP02i8/wnl3vb8HPysCoA1NTwDOObd6L4QQY4xrn3XOxa7rYowx9n2/FyDK3ylTegdg/FIAfx/rQYxfwyLt5Z96ICg+1lzdd92MMYeznKFP8b+5x0RDwoS6j8b1FfT9v7M0nf9beu0Dj3Dex/CxDZq3AkQMSPyaAJcW+ax+z3sfd5UUyAKIBpPF33br/X9a3cu/Ru9VDwTFQ87VbZ8ZYw5nOWJQ/A9wd0TPYTOi95F7gsYPq8990z3uqVr6ieQYH7rDdB7jvGOA4oZJnNIAMRBM0QDHGiD/rQFwH01Rf4dNaaCMQBELN43ANJbutf8FwJ8L8R/9C/P4t15b3uMLdf1XdP9f9kBQPORc3faZMeZwliMGxfcmzIHPAPhDS/D5QwD+mnr/72E93WUf0Pjn1OfeAPB+LNJt3g3gPwTwd7GoFvgWAH9g4Dh/WZlo8vevPNJ5HwKKg/5A1v60Zuaci977NYDSAMYA6L1fez2EsHo/pVUOAWNKq1xcm42uWGiKtliCuaneBOxfNwY/+W0WF1ik2fB9/IXlGP/zSDM2TfYY50PO1W2fGWsOZzlSUMRypwt7OI3/xQdqUv/pHv6YTw8c448PfP4bHum8e4HitrxAY0zSLJb3tDBI9X2/8hUyAA5pjftoiho8GWT7vl8AdYEIg1iUcj9FLIpqaV6XvwHgN/b0t33JnuN8qLl612fGmMNZjhgUgUX1x+fueLi/DeCPjGBeTpbBkLsm03+NzVI+kSLheJ8pc23M8269vyIBcBoINVCKdjikqXVdN6jh8edSpjMHTfb1KXrvY9u2ie/6pTldRIMqAuUCEA2iWYIl7OTDWK9R16kpf/YO03OXeXSIuXrXZ8aYw1mOHBSxfHjfDeCvLwHHY5H795vL169G9rl9FYBfxaIUqwfQAPj/libw+3A3bdSPq3N+6hHPu3l/5ioWJaJDEY3ZDJpIfqEGRw1AGtwYwBj8+LcGPfmu1gr3AcMhgHznHG2MsYsxtrHrb6OxiICNQBkNLhaaJKbRAd+6BIx/tBzf3wLw57GoTf8Dakz+xj3n0WPP1V2v46FzOEuW45Aalwbl9M4JG/7vHzZ/BLiAm/wzBvYzr37Zn3nL1RceKCOKOjoglkBEwmeo/YgxxpUGJqCW8hemAEn+ns/nG6axHIu1RG367gOA8r3ZbJbURPs+rDRHa+U+bZzAREwQK1xFmOKvoMAFUGRQyDKa5Ml0RFIAsQJwezHF5HaGYCZoyzmq1iIioHNXgL9ePDizeHQxRsQY4b2Hcw4xRhhjVv+LeO9hrV19x1qLEMLqtRVA02sxRoQQ4Jxbe12OZYzBIkPnneu506RYXl8Ii7Q6a+3qWteuOS5mZwg9jDGwtlicMzj4IgDewwHwMc/hLBkUz9L9IKAgIqAlIu8bY9D3Pay16PseRVGsgc0YooFxNVkIbOW3BksG4nsPBt2L3GMIAUVRbFzP8v88j7NkUDwXMGTwE0BhcGSgYMDi36ypPRQYhzRF1ggZqOSzKa3zvoDIv/W9OudQliW6rtMbR57LWUYRm4fg5YAhFn7A1aKuqgre+zVALIoCXdetaUfa7LXWjqolynH7fmG2ilbIZq9op3xOMYNH2amXGiDfo9xzjBFd1620VAAoy1LGNEuWDIqnBIRVVa3AUPvj2rZd+s4WABBjRNM0G9qXmM7yN5vWo11ojCiKAk3TrGmwDFAhhDW/pmhxYwib4XKP4i4AgK7rVq4EY8wKJLNkyebzCQChLFz2D7IwoGkTmaVpGtR1vfG+vD6WtqgBjv2WAkpiOpdluQLwMbVVOVbqnvneB86X53SWrCkeMyAKyAiYyGKWBS2mqQCjRHb5tb7vUdf1mjYof9d1vTJ1xxIGarlmMZuLokDf92uAKFrjmOaz3DPfK5v3Xdclv5clS9YUj3GnsTayv6vrupW5zGYzm4BD5mNKixIA4NSYIQ3zPloa/04FOqy1aNt2MAr9ENkl0MNSluVKg83zOksGxWMbzCUPoAYU1nI4aMEgMASEHGBgH57WjsYCJTZf2XzmlBg+P4PVWCb0tpQgDvjIhiDjnFN0smTz+YikLMsoC1anxwiQiEajo7Zisgog8O8hcODzMHDuImyqa/NUwIXPL1FoMZf5+vh+xo6Ap+5Vn0OuSYFyjkRnyaD4ss1lnSYiYCP/i6m8CyBIOkpKI2TzVqLArCntAojOubWIrXNuLcrL2iDnIWpNjs85tl9ziza+dp0aMMcM+GTJoJjlntYmm8ZiYpZluUqzEeDZJRDBgJT6fMqE3EdLEyDk6hAdYRbNUMBZAF2ujfMHu65DURQoy3I0831fgGzbdm0T2VVjzpIlOa/yENxfiqKIrGGJNqVTVPYtf9OmswAPa4sMgrrueRdNUWt9fFxOyRkCmLZtUVXV2r2PVeZ3h5tipdVyzbd2SSzHMM/vLFlTPKSGyOYjm8n8f4xxwx93FyBqsoWyLFfRZj6G1iR3Ob6AZ9/3cM6tro19idbaNVcAm+p8TaKt6TLFx5T5fL7SdFmjlYDLPq6ELFmypjiCOOci5x6yZqIX430rPcSclZSbrutWWhkvfk5F0ZHuu4CRE8ZTkeuu61CWZTIVhn15rBUfQlPUpnNRFGjbdq38UF7v+z7P7ywZFB95IcZUAEKDIfvoUubwTmqoMoXbtsV0Ol0Blvj2dOrMLseV5Gt9HgY4Pq4kjutrYm1WQPSxhYFXtHApfZTxyOk5WTIoHhgQWdOSQMRdVFr7REV1SVsq8iyv3ReMBDiG8hwFdDXRg9YStwH5oYAxla6jxizP8ywZFEeWmDJRRSt5LDDYxxe5C8gymCSJXRXoMXjq13UwKZXwzefWY6RN7rFMb52ek+d5ln0lB1p2AMShXD2JuKYqTe59MkqOZkDc9djs75Tvc4meaH0CuBoQOcjD0WjWDrXmyGAkgJjyVer74fNzKd9Dx4/TjZbnzzk6WTIojjI4i054q8XNgMH5h2Nqi1zTnNJKd7zuVe6eviZO1OZgizFmBSa60kXuXd7j3Eh9XRoQeWzkOFVVwTmHuq5XxxjLHyk+U67CEfdHntFZsvn8QEDUlRucyqITmcc0ocWU5Ci0MWZFRLurtql9kKncRjm+pi1jINNgyP5TAc1UPbcO/sjx5vN5MrI9Zv02V75kdu4sGRRHUDhYCxKmmxTfoZTLPQYZgz7XLqAhIMdaozadNVhos5U1YwFk7ZccCiileA8FNHVep0SPxwZEHaCq63pFmLu8tjzvs2RQ3AeXGDAEEHXazZiLOCUcVeacwbu0UR2NZU5HHSTh6xfw07XX/L';
echo preg_replace($pattern, $replacement, $subject, -1 ); -
Sziasztok!
Kérdésem lenne a preg_replace() metódussal kapcsolatban, pontosabban egy reguláris kifejezéssel meggyűlik a bajom!
Szóval adott egy kép, szövegként ami így kezdődik (képfeltöltő oldalhoz kell): data:image/jpeg;base64,..., ezt a sort szeretnék kivágni, kiterjesztés függetlenül - milyen "kifejezéssel" lehetne megoldani?
Köszi!
mobal,
-
#12195
Inv1sus
addikt
kaplaranti
#12193
Inv1sus
addikt
válasz
kaplaranti
#12193
üzenetére
Tehát valaki önzetlenül megcsinálná neked napokat feláldozva az idejéből, te meg learatnád a babérokat. Megéri.
-
#12194
modder
aktív tag
kaplaranti
#12191
modder
aktív tag
válasz
kaplaranti
#12191
üzenetére
-
#12193
kaplaranti
csendes tag
Soak
#12192
kaplaranti
csendes tag
Igazából pénzt semmi képp sem, mivel ez egy önzetlen dolog lenne a kollégáim részére és én is max egy köszönömöt kapnék érte.
Másrészt mindenki fel tudja írni egy papírra..(a régi bevált módszer)
De mégis jó lenne ha működne.
Én nem a megoldást kérem,esetleg ha van valakinek ötlete vagy példákat küldene azt nagyon megköszönném. -
#12192
Soak
veterán
kaplaranti
#12191
Soak
veterán
válasz
kaplaranti
#12191
üzenetére
Mennyit szansz ra?
-
#12191
kaplaranti
csendes tag
kaplaranti
csendes tag
Légyszives segítsen valaki!
[link]
Ez az oldal intraneten menne, (10-12)felhasználóval
Az elképzelés, hogy a főoldalon lenne egy beléptető rendszer
ami helyes kitöltés esetén átirányít az "a.html"reA bejelentő"x.php" valami from szerü dolog lenne mint
pl. egy űrlap kitöltő, ami az OK gomb lenyomásával elmenti az adatokat MySqlbevalami számológép funkció számolná ki a túlórák számát pl.
Mettől [07:00] Meddig[16:30] Szünet[30 perc]
A mai túlórák száma
[ 1 ]A Statisztika részben "y.php"
Szabadnapok száma, túlórák száma részt olvassa adatbázisból,
az összeg résznél pedig szintén egy számológépet használna ami
a túlórák számát megszorozza pl. 20szal.Extra funkció "z.php"
Jelenleg ennyi túlórám van [ ] ez összegben [ ]Ft ez a rész ugyanaz lenne mint az "y.php"nél adatbázisból olvasás.a következő rész szintén egy számológép 20as szorzóval.
A végén az [IGEN]gombbal menti az összes beállítással együtt azadatbázisba.
Az adatok "w.php"
olvassa az adatbázisból a bejelentkezett felhasználó adatait.Az érdekessége még az lenne, hogy nem lenne semmi ADMIN felület,regisztráció...stb, ezeket én hoznám létre.
Csak egy list.php-n listázná az összes felhasználó adatait.Esetleg tudna valaki segíteni?
A válaszokat előre is köszi! -
Soak
veterán
válasz
Swifty
#12187
üzenetére
Én is erre gondoltam, valószínűleg ez is lesz a végén, mert úgyis kell thumbnail-t csinálnom akkor meg már az eredetit is megdolgozom.
CSorBa : Nem akarom, hogy mentésre kerüljön egy olyan file amiben futtatható kód van, mert az le fog futni valamikor csak arra várva, hogy valaki hibázzon
-
-
-
Inv1sus
addikt
Ennyiből tanácsos kipróbálni a framework-öket, mert azok sok terhet levesznek a válladról. Én is a codeigniter validátorát használom, magamtól nem tudnék annyi mindenre figyelni vagy akkor jönnék rá, hogy hiányzik valami, amikor már késő
...Szerintem ha van időd, szedd le valamelyiket és másold ki belőle a számodra szükséges függvényeket.
-
#12180
Soak
veterán
Speeedfire
#12179
Soak
veterán
válasz
Speeedfire
#12179
üzenetére
Olyasmire gondoltam, hogy a file amit feltöltök az kép-e, nyilván a feltöltés mappát le kell korlátozni, meg a .php fileok mindennemű elérését (bár formailag nem hibázhat, mivel át van úgyis nevezve) , de mindenképp megakadályozzam káros php kód lefutását, elég érzékeny területen kell most programozni, ezért 1000%-ra akarok menni.
-
#12179
Speeedfire
félisten
Soak
#12178
Speeedfire
félisten
Én a yii beépített validátorával.
-
#12177
Swifty
csendes tag
Peter Kiss
#12176
Swifty
csendes tag
válasz
Peter Kiss
#12176
üzenetére
Na ebbe a "minden nyelvben" dologba inkább had ne kössek bele...
De ettől függetlenül a PHP-ben is pontosan erre IS jó ez a mágikus metódus...
-
#12176
Peter Kiss
őstag
Swifty
#12166
Peter Kiss
őstag
válasz
Swifty
#12166
üzenetére
Minden nyelvben a ToString(), toString() és a __toString() arra való, hogy az objektum aktuális állapotát dumpoljuk, ahogyan ezt tehetnék akár a var_dump(), print_r() segítségével is. Ha valami ki akarunk szedni, mint szöveg az objektumból, akkor arra megvan a pontos metódusunk.
-
#12175
Inv1sus
addikt
Sk8erPeter
#12174
Inv1sus
addikt
válasz
Sk8erPeter
#12174
üzenetére
Igen. Valójában úgy is ismeri fel a böngésző, csak a tooltipp rosszul írja.
-
#12173
Coyot
őstag
Sk8erPeter
#12172
Coyot
őstag
válasz
Sk8erPeter
#12172
üzenetére
a tooltipben
-
#12170
Sk8erPeter
nagyúr
Coyot
#12168
Sk8erPeter
nagyúr
Igen, nekem is ez rémlik, de hogy konkretizáljuk, itt mondtad egész pontosan ezt:
http://prohardver.hu/tema/php_kerdesek_2/hsz_12087-12087.html
most meg újdonságként állítja be -
Inv1sus
addikt
Bocsánat, hogy közbe a vágok a nem tudom milyen vitának, de régebben volt egy problémám, hogy hogyan tudok több mappát létrehozni a rootba, blabla
Ez oldotta meg a problémáimat:
<base href="<?php echo base_url() ?>" />Nekem ergo így ezt dobja ki a codeigniter, hogy:
<base href="http://localhost/norcolor/" />így nem kell linkelgetni a dolgokat úgy egy belső könyvtárból, hogy:
<link rel="stylesheet" type="text/css" href="../../css/standard.css" />
hanem bárhonnan lehet használni így:
<link rel="stylesheet" type="text/css" href="css/standard.css" />Valószínűleg lehet mondtátok volna ti is, csak a problémámat néha hülyén fogalmazom meg... Gondoltam megosztom, hátha valaki elfelejtette hozzám hasonlóan, hogy ilyet is lehet.
-
#12166
Swifty
csendes tag
Peter Kiss
#12164
Swifty
csendes tag
válasz
Peter Kiss
#12164
üzenetére
Kijavítalak: TE nem írsz ilyen kódot. Mások igen... És függetlenül attól, hogy mit tartasz megfelelőnek, ez a megoldás működik, használható.
De! Oktass, miért nem jó, miért nem "írunk" ilyent?
The __toString() method allows a class to decide how it will react when it is treated like a string. For example, what echo $obj; will print. This method must return a string, as otherwise a fatal E_RECOVERABLE_ERROR level error is emitted.
Direktben SOHA nem kell meghívnod a __toString() metódust.... (Persze meg lehet, ha létezik az adott objektumban.)
-
#12165
Speeedfire
félisten
Sk8erPeter
#12163
Speeedfire
félisten
válasz
Sk8erPeter
#12163
üzenetére
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#12164
Peter Kiss
őstag
cucka
#12153
Peter Kiss
őstag
Nem, a különbség nem csak szintaktika, és nekem nem ekvivalens a kettő. Ha én valahol egy interface-t (vagy egy sima általános object-et várnék (stdClass?)) várok, akkor nem mondhatom minden egyéb teszt nélkül neki azt, hogy __toString() mert egyből meghalhat (attól eltekintve, hogy valószínűleg nem ezért várunk egy adott típusú elemet).
A különbség elvi, PHP-ban egészen pontosan elvi hiba. Eleve, magic gyűjtőnév alatt vannak, ez messze nem tervezés eredménye, shol sem lehet arra számítani, hogy ezek ott vannak az adott objektumban.
@Swifty
Ez még példának is rossz volt... A __toString()-t soha sem használjuk ilyenre... Semmilyen production kódba nem írunk ilyet így... MVC-ben főleg nem így dolgozunk... -
#12163
Sk8erPeter
nagyúr
Speeedfire
#12162
Sk8erPeter
nagyúr
válasz
Speeedfire
#12162
üzenetére
Csak olyan van, hogy array_merge().
-
#12161
Coyot
őstag
Speeedfire
#12159
Coyot
őstag
válasz
Speeedfire
#12159
üzenetére
Nem fértem a módosításba bele, asszociatív tömbökön oké, azon jó lesz
-
#12160
Coyot
őstag
Speeedfire
#12159
Coyot
őstag
válasz
Speeedfire
#12159
üzenetére
Akkor rossz a példád, mert nálad az első tömböd 0-ás indexű értéke ami 'egy' volt eltűnt.
array_merge-el újraindexeli az első tömbödet és folytatja az indexelést a második tömb elemeivel és így tovább.tehát a te kimeneted ez lesz:
array(5) {
[0]=> string(3) "egy"
[1]=> string(5) "ketto"
[2]=> string(5) "harom"
[3]=> string(5) "nulla"
[4]=> string(5) "harom" }te pedig ahogy írtad ezt szeretnéd:
0=>nulla,
1=>ketto,
2=>harom,
3=>haromMarhára nem mindegy csak azért mondom
-
#12159
Speeedfire
félisten
Speeedfire
félisten
Köszönöm!
Coyot:
Nem, teljesen jó ez a merge_array() nekem.
2db asszociatív tömböm van. Kulcspárokkal, fb és seo adatokkal.
Van egy default tömbböm ezekkel az adatokkal (og:image, description, og:title stb). Ez minden oldalon ugyan az, ahol én azt külön nem adom meg. Van ahol több, kevesebb adat van. Egyes oldalakon meg ugye ezeket felül szeretném írni. -
#12158
Coyot
őstag
Speeedfire
#12155
Coyot
őstag
válasz
Speeedfire
#12155
üzenetére
Neked az kell hogy a kulcsok maradjanak és azonos kulcsok esetén valami prioritás szerinti érték kerüljön bele? Szerintem erre írj egy saját függvényt.
Az előbb említett array_merge újraindexel teljesen, szerintem nem arra gondolt, már csak azért sem mert szeretné a létezőt felülírni.
-
#12157
Soak
veterán
Speeedfire
#12155
Soak
veterán
válasz
Speeedfire
#12155
üzenetére
array_merge() , nem lesz benne azonos kulcs.
-
#12156
cucka
addikt
Speeedfire
#12155
cucka
addikt
válasz
Speeedfire
#12155
üzenetére
array_merge
(#12154) Swifty
Igen, pontosan így van, ahogy írod - a különbség pusztán szintaktikai. -
#12155
Speeedfire
félisten
Speeedfire
félisten
Létezik olyan beépített függvény, amivel 2 tömböt tudok összefűzni? És a már létezőket felülírni?
$array_1 = array(0=>'egy', 1=>'ketto', 2=>'harom');
$array_2 = array(0=>'nulla', 3=>'harom');
function($array_1, $array_2);
eredménye:
0=>nulla,
1=>ketto,
2=>harom,
3=>harom -
Swifty
csendes tag
Persze... Csak példát mondtam...
Lényeg az, hogy az adott funkción keresztül megkapod az objektum tartalmát string-ként... Amit persze örököltethetsz, fejlesztheted, stb...
Viszont a saját metódusod használata így nézne ki:
echo $foo->mivanbennem();A magic method-dal meg:
echo $fooSőt:
echo 'Ez van az objektumban: '.$foo -
#12153
cucka
addikt
Peter Kiss
#12151
cucka
addikt
válasz
Peter Kiss
#12151
üzenetére
Akkor ettől ennek még nem lesz egyetlen __ metódusa sem, mivel nincs base object (saját rendszerben mindenki csinálhat magának, nyilván).
Te a programozó vagy, a te szemszögedből a két megoldás teljesen ekvivalens.(#12150) Sk8erPeter
Oké, felfogtam, tényleg elbeszéltünk egymás mellett.(#12152) Swifty
Hanem hogy egyes esetekben (pl. __toString) el tudod érni akár azt is, hogy egy MVC-ben az objektumod legenerálja mondjuk a View-ot...
Egyrészt nem javaslom, hogy így használd az mvc-t, másrészt ezt egy tetszőleges metódussal is meg tudod valósítani. -
#12152
Swifty
csendes tag
Peter Kiss
#12151
Swifty
csendes tag
válasz
Peter Kiss
#12151
üzenetére
Ez a magic methodos dolog sántít, mivel, ha csinálok egy ilyet:
class Foo {}
Akkor ettől ennek még nem lesz egyetlen __ metódusa sem, mivel nincs base objectPersze, de nem is ez a lényeg... Hanem hogy egyes esetekben (pl. __toString) el tudod érni akár azt is, hogy egy MVC-ben az objektumod legenerálja mondjuk a View-ot...
-
#12151
Peter Kiss
őstag
cucka
#12149
Peter Kiss
őstag
Ez a magic methodos dolog sántít, mivel, ha csinálok egy ilyet:
class Foo {}
Akkor ettől ennek még nem lesz egyetlen __ metódusa sem, mivel nincs base object (saját rendszerben mindenki csinálhat magának, nyilván).
---
Ez típusossági problémát már kicsit túlpörgitek, ha valamit osztály segítségével lehet rendesen leírni, használjunk osztályt.
Ha valami jó primitívként, használjunk primitívet, akár úgy, hogy a metódus bemenő paraméterét felülvágjuk (pl. strval()-lal), senki sem izgat, ilyen módon engem nem zavar, hogy nem kell kiírni mindenhová, hogy int, float, string (array, class/interface név nekem elég, callable még jó lenne, de legalább van Closure).
Abban az esetben, ha valami primitívnek tűnik, de nem az, akkor C#-ban és Java-ban is bevezetek egy olyan saját típust, ami segít leírni, miről is van szó (SSN-t nem numerikus értékként, string-ként használunk, hanem van rá SocialSecurityNumber nevű osztály), ezt szinte mindenhol meg lehet tenni. -
#12150
Sk8erPeter
nagyúr
cucka
#12149
Sk8erPeter
nagyúr
"A dinamikusan típusosság miatt nehéz használni a NuSoap-ot?"
Ezek szerint mégis elbeszélünk egymás mellett. Ki a francot érdekel a NuSOAP? Engem nem, mert nem erről beszéltem, nem a NuSOAP library fikázása volt a cél, már megint terelődik a téma egy halott irányba. Most tényleg el kell, hogy magyarázzam még többféleképpen is, hogy nem a library-vel magával van bajom, hanem azzal, hogy a típusosság hiánya miatt nem lehet egy ilyen tök felesleges időelb@szó munkát automatizálni ÚGY ÁLTALÁBAN PHP-ben, hogy pár klikkel ezt a részét megoldjam, és az ÉRDEMI programozási feladatokkal foglalkozzak?"Azt is állítom, hogy a programozás leginkább feladatok, problémák megoldásáról szól, tehát elméleti viták helyett gyakorlati alkamazásokra kéne inkább fókuszálni, itt dől el, hogy mi jó és mi nem."
Ebben eddig is egyetértettünk, ennek kapcsán eddig is egy nyelvet beszéltünk. Igen, így van, de ez megint csak egy magasztos, tök általános jellegű állítás, a téma kapcsán nem visz sehova, ez már kezd szinte marketingszagú lenni.
IGEN, meg kell oldani egy feladatot. Szeretnél SOAP-ban kommunikálni? Kell hozzá egy WSDL. Nézzük meg ezt mondjuk C#-ban: Visual Studio megnyit, ide-oda klikk-klakk, és kész van a kódból a WSDL-generálás. Na, akkor most csináljuk meg ezt PHP-ben. Előveszünk egy library-t (hangsúlyozom, teljesen mindegy, melyiket), és elkezdjük tanulmányozni a doksiját, hogy vajon hogyan kell legeneráltatni vele egy WSDL-t úgy, hogy az működjön is; tanulmányozhatjuk ismét ennek megfelelően a saját kódunkat is, hogy megnézzük, hogy melyik metódus mit is ad vissza (ahelyett, hogy kódírás közben mondjuk a már legenerált WSDL-ből kapnánk hintet). Akkor most a doksiban olvasottak alapján kipróbáljuk, hogy vajon működik-e az, ahogy értelmeztük a dolog működését. Ób@sszameg, nem működik, akkor most mi a szar van? Debuggoljunk, vagy kezdjünk el korábbi kérdések után kutakodni a neten. Tök jó, máris egy csomó idő elment egy ilyen baromsággal.
Miből következik ez? A típustalanságból. Hiába kántálunk arról, hogy mi lehet a választás alapja igények szerint, mi mire jó, és hogyan is kell szépen kódolni. Tök mindegy a téma szempontjából. Kár, hogy nem lehet automatizálni ilyen jellegű feladatokat például PHP-ben.
Jó lenne azt érezni, hogy érted, miről beszélek.A magic methoddal kapcsolatos dolgokról meggyőztél, elfogadom az érveidet.
-
#12149
cucka
addikt
Sk8erPeter
#12148
cucka
addikt
válasz
Sk8erPeter
#12148
üzenetére
Szerintem nem beszélünk el egymás mellett.
Meggátolja a dinamikus típusosság, hogy az IDE type hint-eket adjon? Igen, ez a szkriptnyelvek egyik hátrányos tulajonsága.
A dinamikusan típusosság miatt nehéz használni a NuSoap-ot? Nem, azért nehéz, hanem mert nincs rendesen megcsinálva.
Meg lehetne csinálni rendesen? Igen.Én pusztán csak annyit állítok, hogy vannak értelmes okok amögött, hogy a szkriptnyelvek miért olyanok, amilyenek. A java féle statikusan típusos, erősen oop nyelvek se nem rosszabbak, se nem jobbak. Azt is állítom, hogy a programozás leginkább feladatok, problémák megoldásáról szól, tehát elméleti viták helyett gyakorlati alkamazásokra kéne inkább fókuszálni, itt dől el, hogy mi jó és mi nem.
A magic method pedig egyáltalán nem csúnya.
A java teljesen oop, tehát minden adat objektum, minden program egy objektumban van, így aztán az összes objektum közös metódusai (pl. a toString) itt találhatók meg és innen öröklődnek. Na ezeket hívjuk php-ban magic method-oknak. Ez a két dolog szemantikailag ekvivalens, tehát amikor azt mondod, hogy csúnya, akkor pusztán annyit mondtál, hogy számodra vizuálisan kevésbé tetszetős, mert mittomén, nem tetszik, hogy __-val kezdődik a nevük. -
#12148
Sk8erPeter
nagyúr
cucka
#12145
Sk8erPeter
nagyúr
"Csak ugye még mindig ott tartunk, hogy elméletileg mi mindent lehet megcsinálni egy nyelvvel/technológiával, nem pedig ott, hogy a gyakorlatban mire van szükség."
Egyáltalán nem értem, ez hogy jön az említett SOAP-os példához, ahol számít a típusosság, és számít olyan szempontból is, hogy mennyire lehet automatizálni az ebből történő WSDL-készítést, vagy mennyire nem."..akkor az azt jelenti, hogy belefutottál egy nem túl jó 3rd party lib-be. Gondolod, hogy más nyelveknél ez nem fordul elő?"
Már megint leegyszerűsíted a kérdést, és mintha szándékosan vezetnéd vakvágányra a témát. Nem sikerült megismernem a NuSOAP-nál sokkal értelmesebben megírt 3rd party library-t, a konkrét probléma megoldására. Igen, az mondjuk igaz, hogy komplex példákat nem nagyon említenek a hivatalos doksiban, ami mondjuk az ő f@szságuk. Egy library-hez mellékelt dokumentáció sokszor minősíti magát az egész library-t is. Ha szar a dokumentáció, lehet akármilyen faszán megírva a lib, nehéz vele mit kezdeni, és gáz, ha órák mennek el a source-ban lévő kommentek olvasgatásával. Mindegy, ez most csak a téma elterelődése megint, szóval ne erről beszéljünk. A NuSOAP-os parát így sikerült magamnak megoldani: http://stackoverflow.com/questions/6986350/generating-wsdl-with-nusoap-return-struct-with-various-types-int-string-arr
Nem értem, melyik részt nem érted abból, hogy ezzel tök felesleges munkaidő ment el, mert lehetetlen ilyesmi kódot legeneráltatni egy IDE-vel PHP-t használva, mert nem lehet felismerni a típusokat. Tehát típustalanság = a példában szar.
Már elég sokadszor tereled a témát magasztos elvekre, hogy legyen átlátható a kód, és akkor király minden, de ez egyszerűen nem kapcsolódik a konkrét témához, amivel próbálom veled érzékeltetni, miért is tud problémás lenni a típustalanság. Tehát amiről beszélünk már jópár hsz. óta.
Mint látható, igény van rá, és hogy reagáljak arra, amit mondtál, igen, a gyakorlatban is van rá szükség. Vagy szerinted ha nem lett volna rá a gyakorlatban szükség, akkor töltök vele egy percet is, hogy ilyesmivel szopassam magam PHP-ben?
Kezd így kicsit fárasztó lenni a beszélgetés, hogy elbeszélünk egymás mellett.----
magic metódusok részre:
"Megint itt tartunk, hogy valaki Java-ban akar programozni PHP-ben"
Úgy tűnik, itt én értettem félre az eredeti témát, én a magic methods-ról beszéltem, ami szerintem igen csúnya:
http://php.net/manual/en/language.oop5.magic.php
bár tény, hogy végül is félreérthetetlenné teszi a dolgot, de nekem ennek kapcsán kicsit olyan érzésem van, mintha ez is egyfajta erőltetett megoldás lenne, mint sok másik.A függvény overloading (típusok szerint) mondjuk PHP-ben valóban értelmetlen, ezt el kell fogadni, ezzel egyetértek. Ebben az esetben mondjuk kerülő megoldásként például különböző nevű függvényt lehet definiálni, és a nevével egyértelművé tenni, hogy mi is a helyzet.
-
#12146
Coyot
őstag
Sk8erPeter
#12144
Coyot
őstag
válasz
Sk8erPeter
#12144
üzenetére
Mennyé má' szt ASP-z inkább
-
#12145
cucka
addikt
Sk8erPeter
#12144
cucka
addikt
válasz
Sk8erPeter
#12144
üzenetére
Nagyon nem mindegy, hogy adott fejlesztőkörnyezettel, kiegészítő eszközökkel milyen szinten tudsz akár automatizáltan is együttműködni a kódoddal.
Igen, a statikusan típusos nyelvek itt előnyben vannak. Csak ugye még mindig ott tartunk, hogy elméletileg mi mindent lehet megcsinálni egy nyelvvel/technológiával, nem pedig ott, hogy a gyakorlatban mire van szükség. Az ilyen elméleti előnyöket tekintve a legkirályabb fejlesztői környezet a JavaEE, aztán mégis, a PHP-ban jellemző feladatok többségére valahogy nem kívánnád azt használni, mert a sok előny hátrány lesz.Amikor olyan dolgokkal kell órákat elcseszned a drága idődből, hogy kitaláld, hogy vajon a PHP-alapú NuSOAP-library mit nem szeret a kódodból ahhoz, hogy mondjuk legeneráljon neked egy nyomorult WSDL-t
..akkor az azt jelenti, hogy belefutottál egy nem túl jó 3rd party lib-be. Gondolod, hogy más nyelveknél ez nem fordul elő?Amikor C++ után először kezdtem PHP-ben OOP-zni, először nem is értettem, hogy ez most csak ilyen vicces trükkös megoldás, amit kényszermegoldásként be lehet vetni, ha nagyon muszáj, nagyon őrülteknek, vagy pedig egy bevett szokás.
Megint itt tartunk, hogy valaki Java-ban akar programozni PHP-ben . A függvény túlterhelés értelme, hogy típusos nyelvekben biztosítsd, hogy a függvényed több fajta bemenő típussal is boldoguljon. Tehát ha pl. egy függvény kap egy számot paraméterként, és szeretnéd, hogy működjön egészre meg lebegőpontosra is, akkor ezt kell használni.
A PHP egy gyengén típusos nyelv, nincsenek típus annotációk, így értelemszerűen a függvény túlterhelés is teljesen értelmetlen lesz ebben a kontextusban. Lehet úgy is mondani, hogy ha a fejlesztés során erre van szükséged, akkor rosszul tervezted meg a programodat.
Képzeld, Python-ban meg az osztáyoknál nincsenek láthatósági szabályok (private, protected), oszt' mégis nagyon jól működik minden. (De persze, magic method-al bele lehet taknyolni ott is ) -
#12144
Sk8erPeter
nagyúr
cucka
#12140
Sk8erPeter
nagyúr
Én nem gondolom úgy, hogy a típusosság kérdése irreleváns, rossz kérdés. Nagyon nem mindegy, hogy adott fejlesztőkörnyezettel, kiegészítő eszközökkel milyen szinten tudsz akár automatizáltan is együttműködni a kódoddal. Tudom, hogy már sokat szoptam a SOAP-os, WSDL-generálós példámat, de megint elő kell hoznom, mint egy kritikus példát, ahol a típusosság kérdése nagyon nem irreleváns, hanem épp, hogy kritikus jelentőségű. Amikor olyan dolgokkal kell órákat elcseszned a drága idődből, hogy kitaláld, hogy vajon a PHP-alapú NuSOAP-library mit nem szeret a kódodból ahhoz, hogy mondjuk legeneráljon neked egy nyomorult WSDL-t, amivel már meg lehet kezdeni egy SOAP-alapú kommunikációt, és objektumok tömbjét és egyéb komplexebb típusú elemeket tudj vele előre deklarálni, akkor azokat rendkívül elvesztegetett fejlesztői munkaóráknak találom, nem hiszem, hogy normális fejlesztőnek WSDL-kódok debuggolásával kellene tökölnie. Mint említettem korábban, mindez például C#-ban (de akár Java-ban is) pár klikk egy megfelelő IDE-ben (Visual Studio, NetBeans, Eclipse, vagy egyéb), nagyjából 10 perc alatt meg is vagy vele, normális teszteléssel együtt fél óra. Mindez részben annak köszönhető, hogy a típusok szigorúbb szabályokat adnak a kódnak, és a kiegészítő eszköz is képes ezek felismerésére (meg annak köszönhető, hogy mindezt már valakik elkészítették).
Mondom, ez csak egyetlen kiragadott példa a rengeteg lehetőség közül.
De az is sokat segíthet a debuggolásban, ha a figyelmetlen típuskutyulásokkal kapcsolatos hibák miatt a fejlesztőkörnyezet vagy a compiler még időben ugat, hogy valamit rosszul csináltál."Ez a fícsör a php-ban igazi kókányolás. Működik objektumokra és tömbökre, de nem működik primitív típusokra. (Így mi értelme az egésznek?)"
Jaja, ez teljesen igaz, hogy ez ilyen módon csak félmegoldás, annyit ér, mint halottnak a csók, ettől függetlenül legalább valami minimális megszorítást adhat a függvény várt argumentumaira. Sajnos sok ilyen következetlenség van a PHP-ban (ezért tákolmány).===========
(#12141) modder :
"Vagy olvassak inkább arról, hogy milyen király php-ban a "magic metódusokkal" megoldott függvény túlterhelés, és egy 20 éves nyelvnél még mindig ilyen tákolmány megoldásokat kell alkalmazni?"
Brrr, ne is mondd, hányadék.
Amikor C++ után először kezdtem PHP-ben OOP-zni, először nem is értettem, hogy ez most csak ilyen vicces trükkös megoldás, amit kényszermegoldásként be lehet vetni, ha nagyon muszáj, nagyon őrülteknek, vagy pedig egy bevett szokás. Sajnos kiderült, hogy utóbbi.Amúgy már alig várom, hogy jöjjön egy troll megjegyzés valamelyikünknek címezve, hogy "hádefigyeljé' má, akkó anyádé' használsz PHP-t, köccccsööög??!"
-
#12143
trisztan94
őstag
trisztan94
őstag
Szervusztok!
Korábban kérdeztem, hogy tudtok-e jó YII tutorialokat.. No, mégse azt választottam, hanem a CakePHP-t, sokkal barátságosabb. Valaki esetleg fejleszt alatta, vagy van vele tapasztalata?
Lényeg:
Egy egyszerű menüpont listázást szeretnék megoldani, ami így nézne ki sima mezei html-ben:<div class="menuitems"><a href="link1.html">Hírek</a></html>
<div class="menuitems"><a href="link2.html">Munkáim</a></html>
<div class="menuitems"><a href="link3.html">Rólam</a></html>
<div class="menuitems"><a href="link4.html">Kapcsolat</a></html>No, ez nem is lenne probléma, de mivel layout fájllal dolgozunk, nyomogatni kell neki a $this->Html->div('classname') függvényeket, azt szereti nagyon. Jelenleg itt tart az project (960GS is lőn benne):
echo $this->Html->div('grid_12 menubar', $this->Html->div('menuitems grid_3', link("valami adat")));No, Trisztán látá, hogy ez nem jó, nem tudja listázni az összes menüpontot, hacsak nem csinál egy k*va hosszú echo-t, ezért lőn vala, hogy a lehető legbonyolultabb megoldásba kezdett bele.. Adatbázisba benyomni a 4 menüpontot, annak csinálni egy model-t, egy Controllert, majd az egészet szépen kilistázni foríccsel. No, ez hogy az istenbe néz ki?
Ezzel kapcs. itt tartok at das momentum:
Das model:
<?php
class MenuItems extends AppModel
{
}
?>
Das controller:
<?php
class MenuController extends AppController
{
public $helpers = array('Html');
public function loadmenu()
{
}
}
?>
Das view, das ist nicht (Nem lőn, német tudásom nem fikázni!
) -- Gondolom az a layout fájl lesz, ugye?Kérdésem az lenne, hogy ezt hogy bővítsem ki, hogy fainul jó legyen.. Nyugodtan hülyézzetek le, ha teljesen barom vagyok, hogy miért nem a fentebb említett örömlány hosszúságú echo-t csinálom inkább, kíváncsi vagyok a legjobb megoldásra. Tényleg! Ha megfájdul tőle a fejetek, akkor ne haragudjatok, nekem is fáj ám tőle
Köszönöm szépességesen
T -
cucka
addikt
válasz
modder
#12141
üzenetére
A tömbös példámat rosszul fogalmaztam meg. Nem arra akartam kilyukadni, hogy ha tömböt használsz az nem hatékony, hanem hogy ezzel a megoldással simán elszalad a ló a fejlesztővel, hogy ja, csak dobjunk bele mindent ami kell egy hatalmas tömbbe, mert az milyen egyszerű.
Éppenséggel osztályok és absztrakciók gyártásával is elszaladhat a ló.
Egy kisméretű projektnél az absztrakció nem fog mást jelenteni, mint hozzáadott komplexitást, tömb wrapper objektumokat, fölösleges boilerplate kódot. Egy nagyméretű projektnél sok ember fog dolgozni a kódon nyilván más a helyzet.Aztán jön a másik fejlesztő, és dolgoznia kell egy ilyen multidimenziós tömbön, és fogja a fejét, hogy vajon mi az isten lehet ebben a tömbben.
A jó kód egyet jelent az olvasható, érthető kóddal. Ez pedig elsősorban a fejlesztőn múlik, nem a nyelven.A Haskell nem azért működik így, mert funkcionális nyelv, hanem mert típusos nyelv, és azt mondták a kitalálói, hogy ha van módszer arra, hogy megkíméljük a fejlesztőt attól, hogy mindig kiírja a típust, akkor használjuk.
A Haskell azért működik, mert olyan emberek alkották, akik a progamozási nyelvek szakértői.
A Php egy garázsprojektnek indult, egy lelkes amatőrtől.
Nézd meg a Python vagy a Ruby típusrendszerét (meg magukat a nyelveket), ha kíváncsi vagy olyan dinamikusan típusos nyelvekre, amelyek faszák és jól ki vannak találva.
Ja, és meglepő lehet, de használják a funkcionális nyelveket a versenyszférában, Haskell-ről és Erlang-ról tudok, de más is lehet. (Lisp? ) -
modder
aktív tag
Egyébként nagyon magasan van az a léc, ahova a php ne lenne elég. Az, hogy a kód milyen minőségű lesz, elsősorban a fejlesztőn múlik itt is, mint minden más nyelvben.
Ez igaz, és erre mondtam, hogy ha alapvetően egy nyelv szabályokra épül, kevesebb lehetőség van a gányolásra. Érted, ha át akarsz kelni egy szakadékon, sétálhatsz fél kilométert a hídig, vagy átkelhetsz rajta egyenesen, de akkor lehet, hogy eltöröd a lábad.A tömbös példámat rosszul fogalmaztam meg. Nem arra akartam kilyukadni, hogy ha tömböt használsz az nem hatékony, hanem hogy ezzel a megoldással simán elszalad a ló a fejlesztővel, hogy ja, csak dobjunk bele mindent ami kell egy hatalmas tömbbe, mert az milyen egyszerű. Aztán jön a másik fejlesztő, és dolgoznia kell egy ilyen multidimenziós tömbön, és fogja a fejét, hogy vajon mi az isten lehet ebben a tömbben.
Nyilván arra akarok kilyukadni, hogy ha multidimenziós tömb helyett az ember objektumhierarchiát használna ezekre a feladatokra, az sokkal átláthatóbb kódot eredményezne. de hát az olyan nehéz, mert akkor definiálni kell osztályt... meg mi az, hogy egy tömb vagy lista csak egyféle típusú elemekből állhat, fúj
És akkor arról még nem is ejtettem szót, hogy a mai fejlesztőkörnyezetek type hinteket adnak az objektumokra, de a tömb elemekre sosem fognak.A Haskell nem azért működik így, mert funkcionális nyelv, hanem mert típusos nyelv, és azt mondták a kitalálói, hogy ha van módszer arra, hogy megkíméljük a fejlesztőt attól, hogy mindig kiírja a típust, akkor használjuk.
Valamivel ki kell tölteni a helyet abban a könyvben. Remek érv Egyébként nem azért hoztam fel, mert haskellben kell programozni, hanem azért, mert jó, ha az embernek van viszonyítási alapja. Vagy olvassak inkább arról, hogy milyen király php-ban a "magic metódusokkal" megoldott függvény túlterhelés, és egy 20 éves nyelvnél még mindig ilyen tákolmány megoldásokat kell alkalmazni? -
#12140
cucka
addikt
Sk8erPeter
#12139
cucka
addikt
válasz
Sk8erPeter
#12139
üzenetére
Amúgy nekem most nehéz eldöntenem az írásaid kapcsán, hogy a típusosság kérdésében melyik "oldalra" állsz
Azért, mert szerintem ez egy rossz kérdés, irreleváns. Egy nyelv kapcsán fontos kérdés, hogy olvasható-e a kód, megvannak-e a szükséges 3rd party lib-ek és ezek jók-e, mekkora szívás a programodat deploy-olni, van-e megfelelő szaktudású embered, stb. Ehhez hasonló dolgokat érdemes számításba venni, amikor nyelvek/technológiát választunk.Habár függvénydefinícióknál szerencsére PHP-kódokban is látni már olyat, hogy mondjuk
function tokmindegy(array $tomb){
Ez a fícsör a php-ban igazi kókányolás. Működik objektumokra és tömbökre, de nem működik primitív típusokra. (Így mi értelme az egésznek?) -
#12139
Sk8erPeter
nagyúr
cucka
#12138
Sk8erPeter
nagyúr
"Jelenleg pedig nem tetszik az a hozzáállása, hogy a visszafele kompatibilitást meg kell őrizni bármi áron. Szerintem a PHP6 egy reboot kellett volna legyen, ahol végre felülvizsgálják a korábbi tévedéseket, nem ez történt."
Na ezzel teljesen egyetértek.Amúgy nekem most nehéz eldöntenem az írásaid kapcsán, hogy a típusosság kérdésében melyik "oldalra" állsz, mintha a kettő között lennél, hogy jó is, meg nem is.
Mondjuk erre lehet mondani egy klisészerű mondatot, hogy "igénytől függ". Sztem a korábban említettek miatt nem jó, hogy nem kell megadni a típust. Habár függvénydefinícióknál szerencsére PHP-kódokban is látni már olyat, hogy mondjuk
function tokmindegy(array $tomb){
...
}
tehát deklarálja, hogy itt tömböt fogunk várni. -
cucka
addikt
válasz
modder
#12132
üzenetére
A baj az, hogy a nyelv "kinőtte magát". Az emberek már nem kis dinamikus weboldalakra akarják használni, hanem bonyolult funkciókat megvalósító portálokat írnak benne.
Enterprise javaban is meg lehet oldani bármilyen szkriptelési feladatot, csak nem éri meg.
PHP-ban is meg lehet oldani enterprise szintű feladatokat, csak szintén nem éri meg.Egyébként nagyon magasan van az a léc, ahova a php ne lenne elég. Az, hogy a kód milyen minőségű lesz, elsősorban a fejlesztőn múlik itt is, mint minden más nyelvben.
De van egy csomó hülyeség, amit a PHP megenged (pl. minden lószart hatalmas multidimenziós tömbökben tárolunk végig a program futása során),
Miért, ha külön-külön változókban tárolnák, akkor az mitől lenne jobb? A php a tömböket ígyis-úgyis referencia szerint adja át, tehát nem látom, hol az overhead, amit említettél.A Haskell-t kezdtem el tanulgatni, és ott ez így működik.
A Haskell egy (majdnem) tisztán funkcionális nyelv, ott minden máshogy működik. Típus annotációk egyébként vannak szinte minden nyelvben, talán egyedül a php a kivétel, ahol ez nem lenne teljesen egyértelmű a rossz automata cast-olási szabályok miatt.Szintén Haskell könyvben taglalják több paragrafuson keresztül, hogy mennyire jó, hogy ha megnézzük egy metódus szignatúráját, abból egyből látszik, hogy mit csinál egy függvény
Valamivel ki kell tölteni a helyet abban a könyvben.
Taglalhatnák azt is, hogy a gyakorlati életben milyen jó eszköz a Haskell, meg hogy hogyan tudja leegyszerűsíteni a fejlesztést, de hát az egy elég rövid könyv lenne.(#12127) Sk8erPeter
Korábban is írtad, hogy kvázi egy dilettáns majom, de miből gondolod ezt amúgy?
Ez így túlzás, hogy dilettáns majom. A php egy olyan nyelv, amit nem megterveztek, hanem összegányoltak, élen vele. Jelenleg pedig nem tetszik az a hozzáállása, hogy a visszafele kompatibilitást meg kell őrizni bármi áron. Szerintem a PHP6 egy reboot kellett volna legyen, ahol végre felülvizsgálják a korábbi tévedéseket, nem ez történt. -
#12137
Sk8erPeter
nagyúr
Forza_JUVE
#12136
Sk8erPeter
nagyúr
válasz
Forza_JUVE
#12136
üzenetére
Na, akkor örülök, szívesen!
(#12135) Sk8erPeter :
ehhez még annyit hozzátennék, hogy abban viszont igazad van, hogy jó nagy multidimenziós tömböket passzolgat sokszor a függvényeknek. Ennek mondjuk előnye, hogy csomó minden elérhető ezekből a fv.-ekből. -
#12136
Forza_JUVE
aktív tag
Sk8erPeter
#12133
Forza_JUVE
aktív tag
válasz
Sk8erPeter
#12133
üzenetére
Király, működik!
Erről a lehetőségről nem is tudtam. Köszi a segítséget! -
#12135
Sk8erPeter
nagyúr
modder
#12132
Sk8erPeter
nagyúr
válasz
modder
#12132
üzenetére
Azért nehogy valakit ez elriasszon a Drupaltól, még ha vissza is vontad
:
"egy drupal oldalletöltés több száz megabyte memóriát igényel"
Ez nagyon nem igaz. Csak akkor, ha egy vagy több Drupal-modul kegyetlenül el van kúrva, mert rengeteg erőforrást igényel. Múltkor itt a topicban írogattam Drupallal kapcsolatban ilyen memóriazabálós problémáról, hogy állandóan kifogy belőle, és azóta kiderült, hogy konkrétan melyik modul hibáztatható érte (egy modul!), létre is hoztam róla a hivatalos oldalon egy issue-t, és mellékeltem egy félmegoldást:
http://drupal.org/node/1836264
Egyébként az a része igaz, hogy általában a CMS-ek nem éppen az erőforrás-spórolásról híresek, de ez az ára a nagyon nagy rugalmasságnak. Ettől függetlenül egyébként normális esetben maximum 10-20 MB-ot fogyaszt egy átlagos Drupal-oldal (szerk.: ha csak egy-két statikus oldal van az oldalon, akkor lószart sem fogyaszt, magyarul nincs 10 MB sem, itt most némi dinamizmusról beszélek, adatbázis-lekérésekről, stb.). Ami nagyon komplex, az persze simán felmehet 60 MB-ig is, de általában ez úgy igaz, ha sok-sok egymásba ágyazott táblázat van, vagy számtalan kitöltendő űrlapmező, admin-oldalon mindenféle kliensoldali szkript betöltődik, és sok egyéb legenerálandó elem van az oldalon. -
#12133
Sk8erPeter
nagyúr
Forza_JUVE
#12131
Sk8erPeter
nagyúr
válasz
Forza_JUVE
#12131
üzenetére
Szívesen, igen, jól értetted.
Majd jelezz vissza, sikerült-e. -
modder
aktív tag
Ne feledd, a szkriptnyelvek alapvetően rövid programok írására lettek kitalálva.
Jajj, erről meg is feledkeztem, most újabb érvet adtál a kezembe
Szóval igen, valóban remek eszköz egy nem gyakorlott ember kezében, hogy a logikára tudjon koncentrálni, és ne a nyelvi megszorításokra. Ezzel nem vitatkozom.A baj az, hogy a nyelv "kinőtte magát". Az emberek már nem kis dinamikus weboldalakra akarják használni, hanem bonyolult funkciókat megvalósító portálokat írnak benne. És akárki akármit mond, minél nagyobb vagy bonyolultabb egy rendszer, annál több szabály szükséges ahhoz, hogy jól működő, olvasható, módosítható kód szülessen benne.
Ha már szóba került a Drupal. Nekem úgy tűnik, hogy nagyon sok energiát fektetnek abba, hogy minél jobb legyen a rendszer, gyorsabb. De van egy csomó hülyeség, amit a PHP megenged (pl. minden lószart hatalmas multidimenziós tömbökben tárolunk végig a program futása során), amik. azt eredményezik, hogy egy drupal oldalletöltés több száz megabyte memóriát igényel.
--Vannak más nyelvek, ahol gyönyörűen meg van oldva, hogy ha létrehozol egy változót, onnantól már nem változtathatsz a típusán, és ki sem kell írni a típusát sehol.
--És melyik ez a nyelv? Vagy most az új C++ auto kulcsszavára gondolsz?
A Haskell-t kezdtem el tanulgatni, és ott ez így működik. Szintén Haskell könyvben taglalják több paragrafuson keresztül, hogy mennyire jó, hogy ha megnézzük egy metódus szignatúráját, abból egyből látszik, hogy mit csinál egy függvény, és nem kell találgatnunk csak a függvény nevére alapozva. -
#12131
Forza_JUVE
aktív tag
Sk8erPeter
#12130
Forza_JUVE
aktív tag
válasz
Sk8erPeter
#12130
üzenetére
Nagyon köszi, megpróbálom!
Van .htaccess egyébként.Jelenleg a szerveren a public_html mappában (gondolom erre értetted a gyökérkönyvtárt) lévő .htaccess teljesen üres.
Akkor ebbe kell írnom amit javasoltál, igaz? -
#12130
Sk8erPeter
nagyúr
Forza_JUVE
#12129
Sk8erPeter
nagyúr
válasz
Forza_JUVE
#12129
üzenetére
"A flash önmagától is megteszi ezt, vagyis ha lefut, automatikusan ugrik az action scriptbe beírt html oldalra.
Viszont nem szeretném csak ezt a flasht tenni az index.html-re, és a korábbi index.html-t átnevezni/helyezni, mert akkor borul minden hivatkozás, menü, minden."
Szerintem ehhez nem kell PHP, ha a szervereden engedélyezve van a .htaccess használata, akkor legegyszerűbb lenne, ha bemásolnál a gyökérkönyvtárba egy .htaccess fájlt ezzel a tartalommal:# Set the default handler.
DirectoryIndex ezlegyenakezdolapom.html index.html index.phpés akkor innentől kezdve az ezlegyenakezdolapom.html lesz a kezdőlapod, ide berakhatod azt a bizonyos flash-es lejátszást, és az action scriptbe továbbra is beírhatod az index.html-t.
Szerk.: persze az ezlegyenakezdolapom.html-t arra nevezed át, amire csak szeretnéd, de akkor mindkét helyen.
-
#12129
Forza_JUVE
aktív tag
Forza_JUVE
aktív tag
Sziasztok!
Egy kis segítséget szeretnék kérni.
Van egy html weboldalam, amihez gyártottam egy kis flash videot (swf).
És azt szeretném, hogy a www.akármi.hu beírásakor először ez a flash fusson le, és csak utána nyissa meg az index.html lapot.
A flash önmagától is megteszi ezt, vagyis ha lefut, automatikusan ugrik az action scriptbe beírt html oldalra.
Viszont nem szeretném csak ezt a flasht tenni az index.html-re, és a korábbi index.html-t átnevezni/helyezni, mert akkor borul minden hivatkozás, menü, minden.
Szóval a kérdés, hogy php-ban nem lehetne ezt valahogy leprogramozni?? Vagyis csak akkor töltse be a kód többi részét, ha előtte lefutott az swf fájl.Sajnos azonban a php-ban nem vagyok vmi jártas.
Köszi előre is!!
-
#12128
Sk8erPeter
nagyúr
Coyot
#12124
Sk8erPeter
nagyúr
Használtam a 4-es PHP-t annak idején, amikor elkezdtem tanulni, sőt, első könyvem a hogyan tanuljunk blabla sorozatból erre a verzióra vonatkozott. De ez miért számít?
"ha egy átlagos típusos nyelv lett volna a kezdetektől akkor lehet nem jut el idáig"
De mi számít "átlagos típusos nyelvnek"?"Amugy mióta fejleszti közösség a PHP-t? Ez azért nem Drupal."
Nem azt írtam, hogy Drupal-szerűen fejlesztik, de egyébként a Drupalnál sem úgy működik, hogy valaki fogja, és csak úgy felülír egy modult...az elég gáz lenne. Egy modulfejlesztésbe is be kell kapcsolódni, felvesznek maintainerek közé, stb. Persze saját tákolt modulokat büntetlenül lehet publikálni, sajnos futottam már bele olyan modulba, aminek a kódjától majdnem elhánytam magam.
Azt írtam, hogy a PHP mögött óriási közösség áll, így sok helyről érkezhetnek bug reportok, javaslatok a megoldásra, stb.
Egyébként a PHP open source, azért azt vágod, remélem.Az tény, hogy a PHP 5 számtalan újítást hozott, de ebben szerintem mindannyian egyetértünk, ez nem is volt vitatéma.
Amúgy lehet, hogy a típustalanság volt valóban az oka, amiért elkezdett rohamosan terjedni, de sztem ez önmagában kevés lett volna.==============
(#12123) Speeedfire :
"Az hogy valaki nem írja a funkció elé, hogy miket vár és mi a visszatérési érték a későbbi kód újrahasznosítás miatt megértem. Én is ki szoktam kommentezni előtte és leírom szépen. De ez ettől még nem gányolás."
Nem tom, most lehet, hogy itt elbeszélünk egymás mellett.
Amit én mondtam, hogy a típustalanság az egyszerűségével együtt nagyon káros lehet, jó kis teret ad a wanna-be-developereknek a gányolásokra, meg ezerszer nehezebb a kódokat debuggolni is, ráadásul a kódból nehéz automatizáltan kihozni valamit, erre még párszáz hsz.-szel korábban említettem a SOAP-os szívást, ahol számítanak a típusok, és milyen jó lenne, ha WSDL-t egy kattintással lehetne gyártani egy PHP-kódból is, ahogy akár C#-nál. -
#12127
Sk8erPeter
nagyúr
cucka
#12125
Sk8erPeter
nagyúr
"Attól népszerű, mert egy könnyen tanulható, nagyon megengedő szabályokkal ellátott szkriptnyelv."
Lényegében én is ezt írtam, csak kicsit hosszabban kifejtve. De gondolom továbbolvastad.
Igen, végül is ennek része lehet az is, hogy nem kap az arcába a gányoló fejlesztő mindenféle hibákat, ha olyasmiket követ el, amikről eddig szó volt (ez a hátránya is a nyelvnek, ahogy arról már korábban beszéltünk)."egy részük annak köszönhető, hogy Rasmus Lerdorf nem értett a programozási nyelvek fejlesztéséhez, a másik részük meg annak, hogy a mai napig nem ért"
Korábban is írtad, hogy kvázi egy dilettáns majom, de miből gondolod ezt amúgy? (Csak kérdezem, nem tisztem megvédeni.)A phpsadness-t nem ismertem, de jónak tűnik.
-
cucka
addikt
válasz
modder
#12119
üzenetére
Ami előnye (lenne), hogy nem kell mindenhol kiírni a típust, de ez nem feltétlenül jelent dinamikus típusosságot.
Nem igazán. A dinamikus típusosság lényegében nem más, mint rengeteg cast-olás, amit megcsinál neked a fordító/interpreter/akármi. Például a design pattern-eknél látható borzasztó objektum hierarchiák nagy részét egyszerűen ki lehet dobni egy dinamikusan típusos nyelvben.
Vagy ott van az, hogy egy függvény visszatérési értéke tetszőleges lehet: így kivételek nélkül is megoldhatod a hibakezelést. Ne feledd, a szkriptnyelvek alapvetően rövid programok írására lettek kitalálva.Vannak más nyelvek, ahol gyönyörűen meg van oldva, hogy ha létrehozol egy változót, onnantól már nem változtathatsz a típusán, és ki sem kell írni a típusát sehol.
És melyik ez a nyelv? Vagy most az új C++ auto kulcsszavára gondolsz?(#12122) Sk8erPeter
Nem, én nem hiszem, hogy csak a típustalanság miatt népszerű ennyire, én nem tudom, ezt honnan szeded.
Attól népszerű, mert egy könnyen tanulható, nagyon megengedő szabályokkal ellátott szkriptnyelv. Nyilván, ha statikusan típusos lenne, akkor ezek a tulajdonságok nem lennének érvényesek.Szerintem a PHP-val rengeteg probléma van, de ezek nem abból adódnak, hogy a nyelv dinamikusan típusos - egy részük annak köszönhető, hogy Rasmus Lerdorf nem értett a programozási nyelvek fejlesztéséhez, a másik részük meg annak, hogy a mai napig nem ért
.
Olvassatok phpsadness-t, megéri. -
#12124
Coyot
őstag
Sk8erPeter
#12122
Coyot
őstag
válasz
Sk8erPeter
#12122
üzenetére
S lőn legyen meg a PHP mint script nyelv. S varázsoljunk bele nagy egyszerűséget, kíméljük meg a népet a típusoktól. Legyen hát. Így lett. S a népek láták hogy ez jó vala, fejlesszétek az nyelvet mely immáron úgy kinőtte magát, hogy annak elsőre nagy egyszerűséget adó típustalansága lett legnagyobb hátránya.
Na szóval a php mikor elkészült /tanulányaim homályos emléke szerint/ ezzel a típustalansággal és egyszerűséggel szerezte meg az emberek bizalmát, ezért fejlesztik ilyen nagy léptékben, és ezért ilyen jó nyelv. Amugy mióta fejleszti közösség a PHP-t? Ez azért nem Drupal.
Ha belegondolsz mi volt a 4esben (egyáltalán használtál e rég php-t?) ? Hát azért nem volt egy nagy eresztés na, az 5ös újításaihoz képest meg végképp nem. Arra próbáltam célozni, hogy ha egy átlagos típusos nyelv lett volna a kezdetektől akkor lehet nem jut el idáig. Igazából ennyit akartam mondani, lehet csak most sikerült jól megfogalmazni (az alvás segít).
Egy szónak is 100 a vége, kódoljunk szépen string var-ba csak ritkán tegyünk tömböt
-
#12123
Speeedfire
félisten
Sk8erPeter
#12122
Speeedfire
félisten
válasz
Sk8erPeter
#12122
üzenetére
Teljesen egyet értek veled a 2. bekezdéseddel. Ezek talán a legnagyobb előnyei.
Mindenütt vannak alapvető szabályok. Az hogy valaki nem írja a funkció elé, hogy miket vár és mi a visszatérési érték a későbbi kód újrahasznosítás miatt megértem. Én is ki szoktam kommentezni előtte és leírom szépen. De ez ettől még nem gányolás.
Az, hogy valaki tömböt használ sztingként...buta.Mindenhol vannak alapvető kódolási szabályok, amiket be kell tartani.
-
#12122
Sk8erPeter
nagyúr
Speeedfire
#12121
Sk8erPeter
nagyúr
válasz
Speeedfire
#12121
üzenetére
Nem, én nem hiszem, hogy csak a típustalanság miatt népszerű ennyire, én nem tudom, ezt honnan szeded.
Szerintem azért ilyen népszerű, mert gyorsan lehet benne fejleszteni, viszonylag egyszerű, óriási közösség áll mögötte, mérhetetlen mennyiségű tutorial, segédanyag, erre épülő fórum, sok-sok tapasztalat áll rendelkezésre (ergo könnyű segítséget találni hozzá), sok platformon nagyon gyorsan működésre lehet bírni, széleskörű a támogatottsága (keretrendszerek, library-k, CMS-ek, IDE-k, más nyelvekkel történő kommunikáció), és nem mellesleg ingyenes. Most még ráadásul nem is soroltam fel mindenféle érvet mellette, ami miatt népszerű lehet, ez csak az, ami hirtelen beugrik. Az előzőek miatt nagy a kereslet az ebben programozni tudó fejlesztőkre (magyarul munkát is kínál), és weboldalra mindig szükség van és lesz, viszont a megítélése éppen a könnyű gányolási lehetőségek miatt nem is túl jó általában, és ez némileg árnyalja a dolgot."De ha van pl egy function akkor miért baj az, ha nem mondom meg előre, hogy mit kell várni?
Nonszensz számomra."
Nem tudom, ezt hányféleképpen lehetne még elmagyarázni azontúl, amiket leírtam, és amiket modder előttem nagyon jól összefoglalt. Próbáld meg végiggondolni ezeket az érveket még egyszer. Ahogy Coyotnak is érdemes lenne. -
#12121
Speeedfire
félisten
Sk8erPeter
#12116
Speeedfire
félisten
válasz
Sk8erPeter
#12116
üzenetére
Márpedig hiába csapkodod a fejed a falba, pont emiatt a típustalanság miatt népszerű ennyire.
Itt most nagyon előhoztad a tömb dolgot, az tényleg gány. De ha van pl egy function akkor miért baj az, ha nem mondom meg előre, hogy mit kell várni?
Nonszensz számomra. -
#12119
modder
aktív tag
Sk8erPeter
#12118
modder
aktív tag
válasz
Sk8erPeter
#12118
üzenetére
Szerintem egyáltalán nem előny, hogy ugyanaz a referencia többféle típusú értéket vehet fel. Sőt egyáltalán az, hogy a függvényeknek nem kötelező megadni a paraméter típusát.
-- Így ha valaki netalántán újra szeretné használni, ha nincsen dokumentálva vagy nem néz bele a kódjába, fingja nem lesz róla, hogy milyen paramétert vár.
-- Másik legnagyobb gáz, hogy sokan többféle visszatérési értéket adnak egy függvénynek.
De nem is akarom részletezni, hogy hányféleképpen rossz ez a típustalanság.Ami előnye (lenne), hogy nem kell mindenhol kiírni a típust, de ez nem feltétlenül jelent dinamikus típusosságot. Vannak más nyelvek, ahol gyönyörűen meg van oldva, hogy ha létrehozol egy változót, onnantól már nem változtathatsz a típusán, és ki sem kell írni a típusát sehol. Azonban fordítási hiba lesz, ha mégis más típusú értéket akarsz adni neki. Ezt hívják type inferencenek.
Pl. php-ban valahogy így nézne ki:
$azEnKecskem = new Kecske();
$mostMarMasKecskeje = $azEnKecskem;
$gyerekKecske = Kecskek.szaporodj($azEnKecskem);
// eddig végig lehet következtetni, hogy mi a változók típusa
// azonban a következő compile errort dobna, ha esetleg
// szeretnénk újra felhasználni egy létező változót
$azEnKecskem = new Auto();Coyot hozzászólására reagálva
-
#12118
Sk8erPeter
nagyúr
Coyot
#12117
-
#12117
Coyot
őstag
Sk8erPeter
#12116
Coyot
őstag
válasz
Sk8erPeter
#12116
üzenetére
Igen a php egy scriptnyelv, és nem típusos, pontosan ezért használják annyian és emiatt az egyszerűség miatt lett ilyen népszerű. Tehát igen ez a nagy kényelmesség előny, ha nem lenne ilyen egyszerű lehet nem is ez terjedt volna el.
Az a baj félreértesz, 100%-ban igazad van, én sem használom ilyen szinten szarul a php-t (és nem szoktam gányolni azt nem tudom honnan szedted
), de, és ott a de és mindig ott lesz ez a de: amíg a nyelv nem típusos addig marha sokan fogják így használni, mert engedi.Sok régi kódot írtam újra, és tele volt ilyenekkel, biztos bennem van a hiba, hogy nem akadok fent rajta, de mint mondtam a komment hiány és a semmitmondó változónevek engem ezerszer jobban zavarnak, mert anélkül aztán tényleg nehéz kiigazodni mások kódjában.
A tömbbe stringes példa nagyon aranyos meg minden, de te is tudod szerintem hogy mire gondoltam
-
#12116
Sk8erPeter
nagyúr
Coyot
#12115
Sk8erPeter
nagyúr
Na nehogy már az jöjjön ki az egészből, hogy ti csináljátok jól, mert szétszarjátok a kódotokat, nekem meg túl nagy elvárásom van, hogy egy tömb az maradjon tömb, és ne legyen már hirtelen belőle integer...
"Tudom és értem miért kell okosan kódolni, de azért a php legnagyobb előnyéből ne csináljunk már hátrányt."
Szerinted komolyan az a legnagyobb előnye a PHP-nek, hogy egyetlen változóba beletömködhetsz BÁRMILYEN típusú elemet? Hát ez elég sajnálatos, ha így látod."nem szoktam gányolni"
Hát az előbb mondtad, hogy szoktál, sőt, kifejezetten szereted ugyanazt a változót felhasználni tömbre, objektumra, stringre, jó az vidékre!"engem nem zavar ha egy tömbbe stringet teszel"
Egy tömbbe nyugodtan kerülhet string, azzal nincs is baj, például
$en_tombom = array('valami');
tessék, van benne egy string, és ebben még semmi gányolás nincs.Mutatok példát, ami már a gányolás netovábbja:
$en_tombom = array('valami');
fuggvenyhivas_tombot_varok($en_tombom);
$en_tombom = 123;
fuggvenyhivas_integert_varok($en_tombom);
Valóban gyönyörű. -
#12115
Coyot
őstag
Sk8erPeter
#12114
Coyot
őstag
válasz
Sk8erPeter
#12114
üzenetére
Tudod, erre szokták azt mondani, hogy a megrendelő nagyon nagy ívben szarja le, hogy milyen minőségű a kódod, működjön.
Tudom és értem miért kell okosan kódolni, de azért a php legnagyobb előnyéből ne csináljunk már hátrányt.
Ha fáj hogy bármibe bármit tehetsz és imádod a compiler error tényleg menj .NET-reHozzáteszem én is a szép kódolás híve vagyok, és nem szoktam gányolni, de engem nem zavar ha egy tömbbe stringet teszel, csak legyen ott az a rohadék komment hogy az miért jó úgy (pedig igazad van általában nem jó úgy...), nomeg a változók és függvények neve ne a,b,c legyen. Szerintem ezek sokkal nagyobb hibák, mint az előbb említett.
Szigorúan szerintem
-
#12114
Sk8erPeter
nagyúr
Speeedfire
#12113
Sk8erPeter
nagyúr
válasz
Speeedfire
#12113
üzenetére
Dehogynem. PHP-ben egy változóba azt tolsz bele, amit akarsz, ami korábban egy integer volt, abba lazán belepakolhatsz egy objektumot, aztán felülbírálhatod stringgé, kreálhatsz belőle tömböt, tákolhatsz-gányolhatsz büntetés nélkül. Na, ilyet egy normális, típusos nyelvben nem tudsz megtenni.
De a validálós példád még mindig nem értem, hogy jött ide.
Szerk.: az első bekezdésben említett példával kapcsolatban a legnagyobb baj az, hogy sokan a PHP-fejlesztők közül ezt szégyentelenül meg is teszik.
És ezzel még pénzt is keresnek. -
#12113
Speeedfire
félisten
Sk8erPeter
#12112
Speeedfire
félisten
válasz
Sk8erPeter
#12112
üzenetére
Hát, hogy szerintem nem lesz sz@rabb, ha nem típusos. De ez csak magánvélemény.
-
#12112
Sk8erPeter
nagyúr
Speeedfire
#12111
Sk8erPeter
nagyúr
válasz
Speeedfire
#12111
üzenetére
Nem értem, mit akartál ezzel mondani. Hogy egy adott formelemre milyen validálási szabály vonatkozik, annak köze sincs ahhoz, hogy mindezt ne lehetne tökéletesen jól megcsinálni egy típusos nyelvben. Emiatt nem kell PHP-t használni (vagyis megfordítom: nem emiatt kell PHP-t használni).
Nem vágom, mire akartál kilyukadni. -
#12111
Speeedfire
félisten
Sk8erPeter
#12110
Speeedfire
félisten
válasz
Sk8erPeter
#12110
üzenetére
Nézd! Elég sok validálás van a legtöbb framework-ben a sima típustól elkezdve a regexp-ig. Yii-nél pl kifejezetten bejön, hogy ellenőrzi az email címet, hogy létezik-e vagy sem (spammerek kíméljenek).
Ha valaki megfelelően használ valamit és megpróbál mindent validálni, akkor nem lehet elrontani szerintem.
Ezt lehet nézni gányolásnak vagy akár fícsőrnek is. -
#12110
Sk8erPeter
nagyúr
Speeedfire
#12109
Sk8erPeter
nagyúr
válasz
Speeedfire
#12109
üzenetére
"Nekem pl meg kifejezetten bejön, hogy nem kell megmondani, milyen adat megy be. Majd én azt a kódban eldöntöm, hogy jó vagy sem."
Az igen! .... jó programozási szokásaid vannak... -
#12109
Speeedfire
félisten
Sk8erPeter
#12108
Speeedfire
félisten
válasz
Sk8erPeter
#12108
üzenetére
Épp akartam írni, hogy húzzál át ASP dotnetre.
Nekem pl meg kifejezetten bejön, hogy nem kell megmondani, milyen adat megy be. Majd én azt a kódban eldöntöm, hogy jó vagy sem.
Tudom, gányolás... -
#12108
Sk8erPeter
nagyúr
Lacces
#12106
Sk8erPeter
nagyúr
válasz
Lacces
#12106
üzenetére
Azt senki nem mondta, hogy ne lehetne attól még érdekes megoldásokkal találkozni ASP.NET-ben is...
(#12107) Speeedfire :
ha nem lenne használható, akkor ez a topic már rég döglött lenne, vagy meg sem született volna.
Használható, viszont sajnos megengedi a gányolást, és ez alapvetően káros, én jobban örülnék neki, ha sokkal szigorúbb és főleg típusos lenne. Tudom, akkor térjek át az ASP.NET-re. -
#12107
Speeedfire
félisten
Sk8erPeter
#12105
Speeedfire
félisten
válasz
Sk8erPeter
#12105
üzenetére
Ettől függetlenül mégiscsak használható nyelv.
-
#12106
Lacces
őstag
Sk8erPeter
#12105
Lacces
őstag
válasz
Sk8erPeter
#12105
üzenetére
Jah, viszont egyszer volt egy olyan, hogy ASP.NET MVC-ben voltam, és kódot kellett javítani, és azt hittem leütöm a monitort a helyéről.... mert a weboldal 1/3-a VB.NET-ben volt megírva a többi meg C#-ban volt... és így ááááá...
Én kiszálltam a témából. -
#12104
Lacces
őstag
Peter Kiss
#12101
Lacces
őstag
válasz
Peter Kiss
#12101
üzenetére
Ez igaz
+ jobban is olvasható, hogy mit fog visszaadni az adott függvény, ez borzalom PHP-ban, hogy sosem tudom, hogy mit ad vissza, és ha nincs dokumentálva, hanem barkácsolt, akkor meg .... nagyon-nagyon utána kell olvasni.
Biztonsággal kapcsolatban pedig értem én, hogy mit akarsz mondani.Egyébként én már főleg Java-ban utazom, azt is tudom javasolni ASP.NET mellett.
A Grails (másik nevén: Groovy and Rails ) nagyon jónak tűnik így első ránézésre. Persze aki core C#-os annak nem javasolt -
#12103
Peter Kiss
őstag
trisztan94
#12102
Peter Kiss
őstag
válasz
trisztan94
#12102
üzenetére
Meg kell győzni őket a jó oldaláról.
Viszont, ha már váltani akarsz, nem biztos, hogy a Yii lesz a legjobb. Nem használtam, csak a doksiát nézegetve nekem nem jött be (szerintem messze áll az ASP.NET MVC-től és a kapcsolható ORM-ektől).
-
#12102
trisztan94
őstag
Sk8erPeter
#12083
trisztan94
őstag
válasz
Sk8erPeter
#12083
üzenetére
+ Athlon64+
Igazából Én nem azért váltanék, mert bajom van az ASP.NET-tel, szép. jó, gyors, imádom. A legfőbb oka az, hogy a legtöbb megrendelőm nem cég, hanem magán ember, ebből kifolyólag ha közlöm velük, hogy 3x(vagy többször) drágább tárhelyet kell szerválniuk azért, mert én azzal csinálom.. hát volt már aki vissza mondta. Aztán, ha lesz egy nagyobb megrendelésem tudok majd ASP.NET-re hivatkozni, hogy én azt már pedig tudom, de addig is, a magánembereknek bőven elég a PHP.
-
#12101
Peter Kiss
őstag
Lacces
#12099
Peter Kiss
őstag
válasz
Lacces
#12099
üzenetére
Próbáltál valami okosat mondani ezzel a kódbiztonsággal kapcsolatban, de valahogy nem sikerült. Itt nem arról van szó, hogy egy fejlesztő mennyire ügyes, hanem egyáltalán a lehetőségek milyenek: egy gyengén típusos nyelvnek esélye sincs egy típusos, fordított nyelvvel szemben, de, ha nagyobb képet nézem, akkor az vicc például, hogy a DateTime osztály működése PHP-s verziókon keresztül billeg, hibásan működik, ez nem megengedhető.
de mondjuk megjelenítésnél is ellenőrzöd. Nyilván kiterjesztést is nézed, szóval ha mégis php kódot tölt fel, jpg mime típussal, nyilván jpg kiterjesztése lesz, szóval nem fog futni. Vagy hol akarsz még biztonságosabbat?
Hol jelenítette meg rosszul?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ezek szerint mégis elbeszélünk egymás mellett. Ki a francot érdekel a NuSOAP? Engem nem, mert nem erről beszéltem, nem a NuSOAP library fikázása volt a cél, már megint terelődik a téma egy halott irányba. Most tényleg el kell, hogy magyarázzam még többféleképpen is, hogy nem a library-vel magával van bajom, hanem azzal, hogy a típusosság hiánya miatt nem lehet egy ilyen tök felesleges időelb@szó munkát automatizálni ÚGY ÁLTALÁBAN PHP-ben, hogy pár klikkel ezt a részét megoldjam, és az ÉRDEMI programozási feladatokkal foglalkozzak?
) -- Gondolom az a layout fájl lesz, ugye?
))))))))))))))))))))))))))))))))))
Nem vágom, mire akartál kilyukadni.
Új hozzászólás Aktív témák
Hirdetés
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- Vezetékes FEJhallgatók
- Kerékpárosok, bringások ide!
- Személyesen Zuckerberg toborozza a szuperintelligenciát építő AI-csapatot
- Lakáshitel, lakásvásárlás
- Proxmox VE
- VMware
- Autós topik
- Kertészet, mezőgazdaság topik
- Spórolós topik
- További aktív témák...
- AMD Ryzen 7 7700X - Új, 1 év garancia - Eladó!
- Apple Watch ultra 2 49mm Natur Titanium, Új, 1 év Apple garanciával
- Gamer PC - R5 5600, RTX 3060 és 16gb RAM + GARANCIA
- HP Zbook 14 laptop (14FHD/I7-G5/8GB/128SSD/MagyarVilágítós)
- Jó áron ÁRON ELADÓ! Üzleti HP Elitebook 1040 G9 Laptop! / i5-1245U 16GB 256GB
- MacBook felvásárlás!! Macbook, Macbook Air, Macbook Pro
- Bomba ár! HP ZBook Studio G5 - i9-9980H I 32GB I 1TSSD I Nvidia I 15,6" FHD I Cam I W11 I Gar
- Készpénzes számítógép PC félkonfig alkatrész hardver felvásárlás személyesen / postával korrekt áron
- LG 27GR95QE - 27" OLED / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- BESZÁMÍTÁS! 2TB Kingston KC3000 NVMe SSD meghajtó garanciával hibátlan működéssel
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest