ugrás a tartalomhoz

Kódkiegészítés

Pepita · 2012. Jún. 21. (Cs), 01.24
Sziasztok!

Olyan gondom van, hogy egy számomra nagyon tetsző framework-ot (CodeIgniter 2.1.0) és - szerintem - nagyon jó szerkesztőt (Komodo Edit 6) használok, de nincs kódkiegészítésem a CI "gyári" osztályaihoz és az általam írtakhoz sem. Ez nekem elég nagy probléma, úgy gyorsaságban, mint szintaktikai hibalehetőségként.

Próbáltam a Komodo-t "ráuszítani" a használt könyvtárakra (még egyenként is, bár elvileg az alkönyvtárakat is felveszi), de a plafon - jelenleg - az, hogy egy-egy helpernél működik. Ezek nem definiálnak osztályt, csak függvényeket.

Gondolom, a CI load->library(...) osztály betöltése/kezelése körül van valami trükk, amit a Komodo "nem ért". Annyira még nem bengéztem át a kódják, hogy rájönnék. Illetve valószínűleg nem is tudok eleget hozzá, legalábbis tartok tőle. (Kicsit még mindig idegen az interpreteres OOP.) A saját doksijában erre nem térnek ki, csak kb. annyi van, hogy "ha betartod ezeket és ezeket a név/fájlnév/könyvtár szabályokat, akkor hú de jó neked, használhatod a loadert és csak egyszer fogja betölteni stb."

Letöltöttem már a Komodo 7-et és a CI-ből is van már 2.1.1, de egyelőre nincs időm azokkal kísérletezni, de ha valaki azt mondaná, hogy akkor megoldódik a probléma, akkor a következő projektre már úgy készülnék.

Megköszönök minden észrevételt, elsősorban azok válaszát várom, akik használják/használták a fent említett szoftvereket.

Üdv. Pepita
‹ Saját HTML ($_POST) feldolgozó PHP-ból nyomtatás blokknyomtatóra ›
 ■
1

Ezt találtam: Here is a link

inf · 2012. Jún. 21. (Cs), 04.51
Ezt találtam:
Here is a link to the autocomplete.php file I use in Komodo Edit. Just drop this into your project root (the same place as the .kpf file) restart Komodo Edit and you should have native CodeIgniter auto completion. If you have custom libraries add them where specified.


autocomplete.php:

<?php
/**
 * @property CI_DB_active_record $db
 * @property CI_DB_forge $dbforge
 * @property CI_Benchmark $benchmark
 * @property CI_Calendar $calendar
 * @property CI_Cart $cart
 * @property CI_Config $config
 * @property CI_Controller $controller
 * @property CI_Email $email
 * @property CI_Encrypt $encrypt
 * @property CI_Exceptions $exceptions
 * @property CI_Form_validation $form_validation
 * @property CI_Ftp $ftp
 * @property CI_Hooks $hooks
 * @property CI_Image_lib $image_lib
 * @property CI_Input $input
 * @property CI_Language $language
 * @property CI_Loader $load
 * @property CI_Log $log
 * @property CI_Model $model
 * @property CI_Output $output
 * @property CI_Pagination $pagination
 * @property CI_Parser $parser
 * @property CI_Profiler $profiler
 * @property CI_Router $router
 * @property CI_Session $session
 * @property CI_Sha1 $sha1
 * @property CI_Table $table
 * @property CI_Trackback $trackback
 * @property CI_Typography $typography
 * @property CI_Unit_test $unit_test
 * @property CI_Upload $upload
 * @property CI_URI $uri
 * @property CI_User_agent $user_agent
 * @property CI_Validation $validation
 * @property CI_Xmlrpc $xmlrpc
 * @property CI_Xmlrpcs $xmlrpcs
 * @property CI_Zip $zip
 * 
 * Add addtional libraries you wish
 * to use in your controllers here
 * 
 */
class Controller {};

/**
 * @property CI_DB_active_record $db
 * @property CI_DB_forge $dbforge
 * @property CI_Config $config
 * @property CI_Loader $load
 * @property CI_Session $session
 *
 * Add addtional libraries you wish
 * to use in your models here.
 * 
 */
class Model {};
?>
Thanks very much, Jim. I'm running a version of CI 2 downloaded from Ellis Lab's bitbucket repository. I found that another clean way to do this is to extend CI_Controller and CI_Model with MY_Controller and MY_Model in application/core and add your comments to those files. Without this approach and using the autocomplete.php file you suggested, I was getting some errors with the HTML extension; it didn't know which "Controller" to use.


Na most ezeket te talán tudod értelmezni, én nem igazán, mert nem használom ezt a fajta editort. Igazából hülyét is kapnék, ha még a kódkiegészítést is külön be kéne konfigolnom... Netbeans-ben úgy megy, hogy amit beszórsz a projekt mappájába, azt automatikusan feldolgozza...
2

Thanks very much, inf3rno

Pepita · 2012. Jún. 21. (Cs), 05.12
Köszönöm szépen, megpróbálom értelmezni...
Netbeans-ben úgy megy, hogy amit beszórsz a projekt mappájába, azt automatikusan feldolgozza...

Egyrészt felkeltetted az érdeklődésem a Netbeans irányába, másrészt ha bejön ez a trükk, nem sokat fogok vele vakerálni, mert amúgy is van egy "alapkészletem" (CI), amibe mindig berakosgatom a máshol is használható fejlesztéseimet, tehát valahogy ezt az alapot kell bevonjam a buliba. Remélem sikerül.

(Jó korán keltél. :))
3

Ha mégis netbeans-nél kötsz

inf · 2012. Jún. 21. (Cs), 05.25
Ha mégis netbeans-nél kötsz ki, akkor érdemes phpdoc-al megismerkedned, leginkább a @var és a @return, amiket használok. Sajnos kellenek, mert php nem típusos nyelv. A legtöbb esetben meg tudom oldani, hogy menjen a kód kiegészítés, a gondok általában ott kezdődnek, ha valamit egy tömbből ránt elő az ember, és tudni akarja a típusát. Ha beteszed class property-be @var-ral, akkor minden oké, sima változóknál viszont még nem tudtam megoldani, hogy működjön rájuk is a típusfelismerés.

Na utánanéztem nb sima változóinak is, és egészen furcsa...

class B {

    /** @var B */
    protected $prop;

    /** @return B */
    public function c() {
        $b;
        /* @var $b B */
    }

}
Érdekes módon csak egy csillagot kell megadni sima változónál, és csak deklarálás után megadva működik, legalábbis csak akkor nem ?-et ír ki. Viszont ha metódust hívunk egy ilyen változón, és annak a visszatérő értékét egy másik változóba tesszük, akkor már megint csak ?-et kapunk. Nem tudom, hogy ilyenkor tényleg nem ismeri fel a típust, vagy csak valami hiba van a kiírásában. Tippelni szokott ilyenkor típusra, viszont a tippelt típusokkal az a baj, hogyha refaktorálásnál változtatsz mondjuk egy metódusnéven egy osztályban, akkor az összes olyan változót felsorolja, aminek betippelte a típusát, és amin azonos nevű metódust hívtál. Szóval korántsem tökéletes. Jobban örülnék, ha egy változónál automatikusan rákérdezne a típusra, ha nem tudja, és nem kéne phpdoc-ot gépelni...

Na szóval netbeans-en is van még mit fejleszteni... (Én 7.01-et használok, lehet, hogy azóta változott valamit ez is, majd írok a fórumjukba, ha mégsem.)
10

PHPStorm

blacksonic · 2012. Jún. 22. (P), 14.00
A PHPStorm ezeket nagyon ugyesen kitalalja
4

Komodo

Poetro · 2012. Jún. 21. (Cs), 06.29
Én már jó pár éve Komodo-t használok, és ha a projektben illetve a nyelvi könyvtárakban (pl. PHP Directories ebben az esetben), akkor működni fog a kódkiegészítés. Mondjuk pont CI-re még nem néztem, de elméletileg működnie kellene arra is.
5

De nem működik

Pepita · 2012. Jún. 22. (P), 00.26
A te oldaladon (vagy itteni cikkedben?) olvastam egyszer szerkesztőkről, és amiket a Komodo-ról írtál, amiatt próbáltam ki - és azóta is használom. (Szerk.: ezúton is köszönöm!)

De nem megy a kódkiegészítés, az autocomplete.php-val sem. Könyvtárként (nyelvi) már többször hozzáadtam, az összes osztály a projekten belül van, mégsem. Azt is próbáltam, hogy van egy "induló projekt" vagy alap-könyvtáram, ahol az alap CI csomag van a saját újrahasznosítható osztályaimmal, és ezt a könyvtárat is megadtam PHP nyelvhez. Valamiért csak nem akarja, pedig már nagyon "összeszoktunk".

Gyanítom, hogy a CI osztálykezelésével lehet valami, mert korábban ha pl. require_once-al behúztam egy osztályt és simánnew-val létrehoztam a példányt, akkor Komodo nem kérdezett semmit, simán a require-ből kitalálta, honnét kell kiegészíteni. (Persze akkor is projektkönyvtáron belül voltak.)

Azért remélem lesz megoldás (Komodo-val) és nem egy olyan kérdést tettem fel, ami megoldatlan marad... :(

Apropó: nagy váltás Komodo-nál a 6-ról 7-re?
8

Apropó: nagy váltás

Poetro · 2012. Jún. 22. (P), 09.01
Apropó: nagy váltás Komodo-nál a 6-ról 7-re?

Én nem emlékszem semmilyen problémára, amit még a kiadás előtt jeleztem nekik, azt simán megoldották, így a megjelenéskor megvettem a 7-est is.
15

Megvetted?!

Pepita · 2012. Jún. 23. (Szo), 00.47
így a megjelenéskor megvettem a 7-est is.

Lehet, valamit nagyon elnéztem, de eddig nem láttam fizetős Komodo-t. Most töltök egy kis időt "náluk"...

Szerk: már látom: az IDE. De a kódkiegészítéshez nincs köze.

Én elsősorban olyasmi "nagy váltásra" gondoltam, hogy pl. nagyon máshol és másképp néznek ki a snippet-ek vagy a projektfa, vagy nagyon másképp kell beállítani vmit, stb.
9

tippek

tiku I tikaszvince · 2012. Jún. 22. (P), 09.10
Csak néhány tippem lenne. Előre bocsájtanám, hogy Komodo-val nincs releváns tapasztalatom. Egyéb szerkesztőknél a "nem megy a kódkiegészítés, pedig kellene neki" problémákkal akkor találkoztam, ha osztálynév ütközés volt és a szerkesztő kódkiegészítő funkciója ezt nem tudta megfelelően kezelni. Ilyen állapot akkor is elő tudott állni, ha ugyanaz a fájl más-más módszerrel is benne volt a projektben. Pl, libként és külső resource-ként is definiálva van.

Az inf3rno által leírt módszert is meg kellene próbálnod. Lehet, hogy Komodoban kísérletezned kell vele, mert - ha jól értem - Netbeans a /* @var $valtozo Tipus */ formát értelmezi, míg PHPStorm-ban a /** @var $valtozo Tipus */ forma a nyerő. Továbbá lehetséges, hogy nem mindegy, hogy a változó deklarálása előtt vagy után kell tenni ezt a tippet.

PHPStormban ezzel a módszerrel *nem csak* egy függvény elején élhetsz, hanem akár egy foreach szerkezeten belül is.

class C {
  function f( array $arrayOfDateTime ) {
    foreach ( $arrayOfDateTime as $dateTime ) {
      /** @var $dateTime DateTime */
      $dateTime->format(DateTime::W3C);
    }
  }
}
6

Az Eclipse is egy igen okos

Karvaly84 · 2012. Jún. 22. (P), 00.26
Az Eclipse is egy igen okos jószág, sok mindenre idomítható, többek közt PHP-re.
7

Köszi, de

Pepita · 2012. Jún. 22. (P), 00.30
szerkesztőprogit csak végszükség esetén váltanék, nekem elég fontos a megszokott vizuális környezet. (És kicsit nehezen szokok bele az újba.)
11

Én is

joed · 2012. Jún. 22. (P), 21.06
Első gondolatra én is azt javasoltam volna, hogy nézz meg egy robusztusabb szerkesztőt és nekem is az Eclipse jutott eszembe, pontosabban a Zend Studio.

De ha nem is akarsz váltani, szerintem egy próbát megér.
12

Szerintem nincs valami

inf · 2012. Jún. 22. (P), 21.12
Szerintem nincs valami hatalmas különbség az IDE-k között. Én eclipse-el próbálkoztam régebben, de akkor még nagyon bugos volt a php-ra, azért tértem át netbeans-re. Gondolom azóta már változott a helyzet...
16

NetBeans + 1

T.G · 2012. Jún. 23. (Szo), 08.48
A téma kapcsán rászántam most magam és feltelepítettem a NetBeans-t. Nagy valószínűséggel én is lecserélem az Eclipse-met. :) (igaz, nálam nem "nagyon bugos" az Eclipse, de mégis jobbnak tűnik a NetBeans.)

Szerintem egy feltelepítést és kipróbálást másnak is megérhet! :)
17

Nem sűrűn van gond vele,

inf · 2012. Jún. 23. (Szo), 09.08
Nem sűrűn van gond vele, intenzív használatnál pár naponta egyszer összeomlik a semmitől, szóval érdemes menteni ;-) Eddig nekem ebből különösebb bajom nem volt, mert kicsi osztályokat használok, és minden szerkesztés után mentek, hogy kipróbáljam, hogy működik e...
18

OK, kipróbálom

Pepita · 2012. Jún. 24. (V), 00.34
Gyorsabb (és Komodo-s) megoldást szerettem volna, de most már biztos, hogy - mihelyst lesz rás időm - kipróbálom a NetBeans-t is.
Már több ötletet is sikerült gugliznom (az első idézet alapján), de egyik sem oldotta meg a problémát. Még ki fogom próbálni a Komodo 7-el is, meglátjuk.
13

Eclipse PHP

eddig bírtam szó nélkül · 2012. Jún. 22. (P), 21.18
Én lebeszélnék (egyelőre) mindenkit az eclipse használatáról.
Pythonhoz, Javahoz jó, de a PHP bővítménye szerintem katasztrofális.
14

Köszönöm mindenkinek,

Pepita · 2012. Jún. 22. (P), 23.55
futok még néhány kört, aztán visszajelzek.
Az az igazság, hogy a jquery-kódkieg. hiányán fenn sem akadtam, de a CI-hez nagyon kéne.
19

eclipse pdt

szabo.b.gabor · 2012. Jún. 25. (H), 12.49
Én is ajánlani tudom az Eclipse-t (PDT kiegészítővel).

itt is úgy működik, hogy osztályváltozók felett /** @var DateTime */ esetleg /** @var DateTime[] */ ilyenkor egy foreach-en belül, már tudja, hogy DateTime

kódon belül /* @var $holnap DateTime */

függvényeknél és metódusoknál
/** @return DateTime */

azért ezeknek a dolgoknak megvan az a veszélye, hogy elbutulsz mellettük. én legalábbis ezt tapasztalom, bár lehet, hogy ez ettől független :D. memóriám már szinte nulla..

Tényleg tapasztalt már valaki olyat, hogy egy kód logikus felbontása bizonyos szinten túl már egyszerűen gátolja a munkában, osztály (legyen származtatott), kontroller, view, css, javascript.. ti ezt hogyan kezelitek?
20

Velem még nem :-) Ami most

inf · 2012. Jún. 25. (H), 14.21
Velem még nem :-)
Ami most nálam egy pici gát, hogy a paramétereket valahogy el kell juttatni az alsóbb osztályokba. Kéne időt fordítanom arra, hogy rendesen kidolgozzam a DIC objektum fát lazy inittel, mert most csak össze van szórva minden egy tömb fába.
21

Nem egészen értem :(

Pepita · 2012. Júl. 3. (K), 00.04
Ilyesmit olvastam fentebb is (inf3no-tól?) a Komodo-ra, de nem a fájlokon belül, hanem külön autocomplete.php-ban. Amit írtál, az azt jelenti, hogy előbb tele kell kommenteznem az osztályokat leíró fájlokat, utána kezdhetek dolgozni? Lehet, nagy igényű vagyok (és kevés php-s tapasztalatom van), de kifejezetten szeretem, ha az én kódomban csak az én (kevéske) kommentjeim vannak. Ezek is legnagyobb részt arra valók, hogy akár évek múlva is első pillantásra tudjam egy fv-ről (...), hogy mit csinál.
...egy kód logikus felbontása bizonyos szinten túl már egyszerűen gátolja a munkában...
Szerintem - de lehet, hogy nincs igazam(!) - nemigazán jók a "minden kicsi szirt-sz**t külön osztályba, hátha újrahasznosítjuk (stb)" elméletek. Igen, bizonyos szinten túl már többe kerül a sok származtatás, stb., mint amennyit ér az egész. Ráadásul ugye annyi db vrinyóelérés, ahány fájl. Fontosabbnak tartom az egyszerű osztályoknál az átlátható kódolást, logikus vezérlési szerkezetet, stb. Ha tényleg jól meg tudok írni egy kicsit komplexebb osztályt az adott feladatra és áttekinthetően, logikusan kódoltam, akkor hosszú időn keresztül bármikor írok hasonlót, a feladat szerint.
Mindenkinek a maga "bizonyos határait" kell szemelőtt tartania.
22

Igen, bizonyos szinten túl

inf · 2012. Júl. 3. (K), 00.17
Igen, bizonyos szinten túl már többe kerül a sok származtatás, stb., mint amennyit ér az egész. Ráadásul ugye annyi db vrinyóelérés, ahány fájl. Fontosabbnak tartom az egyszerű osztályoknál az átlátható kódolást, logikus vezérlési szerkezetet, stb. Ha tényleg jól meg tudok írni egy kicsit komplexebb osztályt az adott feladatra és áttekinthetően, logikusan kódoltam, akkor hosszú időn keresztül bármikor írok hasonlót, a feladat szerint.


Ez inkább kidolgozottság függő dolog. Ha valami bonyolódik, akkor mindenképp darabolni kell, mert ha mondjuk elér egy 200-250 soros hosszt egy osztály, akkor (legalábbis nálam) egyre jobban romlik a kód minősége. Úgy is fogalmazhatnék, hogy összeroskad a szerkezet a kód súlya alatt :D

A fájlok száma egyáltalán nem korlátozó tényező, ha deploy-nál összefűzöd az osztályokat nagyobb csomagokba...
25

Így közelít..

Pepita · 2012. Júl. 3. (K), 05.49
Ha a 200-250 sor az üres sorok nélkül értendő, akkor biztosan elég nekem is.:)
Mondjuk egy-egy model esetében (üres sorokkal együtt) értem el 500 körülit is, de ezeknél két fv. közt három (v. négy) üres sort hagyok.
23

Ha boldogulsz opcode cache

tgr · 2012. Júl. 3. (K), 01.04
Ha boldogulsz opcode cache nélkül, akkor még úgysem akkora a terhelés, hogy foglalkoznod kéne a PHP fájlbetöltések számával, ha opcode cache-t használsz, akkor meg olyan mindegy, hány fájlod van. Nagy rendszerekben egyébként nagyon nehéz megtalálni az osztálydeklarációkat, ha nem valami osztálynév = elérési útvonal sémát követsz, plusz az autoloading is sokkal fájdalmasabbá válik.
24

Nagy rendszerekben egyébként

inf · 2012. Júl. 3. (K), 01.08
Nagy rendszerekben egyébként nagyon nehéz megtalálni az osztálydeklarációkat, ha nem valami osztálynév = elérési útvonal sémát követsz, plusz az autoloading is sokkal fájdalmasabbá válik.


Mostanában nálam elég ritka, hogy deklarációkat keresek, amikor az ide automatikusan átrak oda. Az autoloading tényleg fájós.
26

Azt hiszem,

Pepita · 2012. Júl. 3. (K), 06.00
a nagy rendszerektől még messzi vagyok (vagy "ők" tőlem), és van pár régi windowsos-delphis beidegződésem, ami nyilván nem igaz Apache / PHP környezetben. Így jobban átgondolva: persze, az interpreteres működés ideje alatt/mellett nem nagyon észrevehető különbség, hogy egy oldal kiszolgálásakor 20 vagy 30 require történik, csak én megszoktam, hogy amíg van elegendő RAM-om, addig vrinyót minél kevesebbet (-szer)... A 200-300 már egész más szitu lenne, de azon még - sajnos - nem kell törjem a fejem.
27

ha mondjuk létrehozol egy

szabo.b.gabor · 2012. Júl. 3. (K), 06.39
ha mondjuk létrehozol egy változót, hogy

$db=new DB();

akkor tudni fogja, hogy mi az a db és milyen metódusai vannak, de ha a DB osztályod query paramétere visszaad egy DataReader osztályt, akkor már a query függvény kommentezésénél meg kell adnod, hogy DataReader-t ad vissza és akár változóba teszed be az eredményt, vagy egyből metódusokat hívsz tudni fogja, hogy mik a lehetséges függvények.

szétkommentelés. én nem érzem felesleges kommentnek azt, hogy milyen paramétereket várok és mit adok vissza, ráadásul a paraméterekre eső részt akár automatikusan ki is tölti neked ha mondjuk adsz a változókra típusokat.

Ezek amúgy szabványos kommentek. és ha egy-egy framework nem használná ezeket, akkor igen nehéz volna a használatuk.

az aprózódásra amúgy úgy gondoltam, hogy 'legyen itt egy kis ajax dropdown', akkor a view file-ban adok neki egy osztályt, hogy a diszkrét js-emben jqueryvel meg tudjam találni, itt tolok egy ajax hívást, amit megkap a controller ahol betöltöm a megfelelő model-t akitől lekérem az adatokat, esetleg az adatokat átadom még egy view file-nak, amit aztán visszaköpök, hogy ismét a javascript-en legyen a sor, hogy beállíthassa a dropdown új elemeit.

no én ebben a folyamatban szoktam néha elveszni, valahogy így.
1. csináljunk akkor egy ilyet!
2. hol is kell kezdeni?
3. paparaparaparam.. áh itt!
4. mit akartam csinálni?
5. goto:1 :D
28

Na, itt lesz a hiba

Pepita · 2012. Júl. 3. (K), 06.50
Akkor ezeket a "felesleges" kommenteket tulajdonképp a CI fájljaiba (osztályaiba) kell egyszer megírnom (nem láttam benne ilyet).
Hát ez nem piskóta feladat...
Az (is) a gondom vele, hogy csak egyes részeit túrtam át, de elég komoly örökítési mélységek vannak benne, nem kívántam a rendszer teljes magját áttúrni... Hát, ha egyszer rá tudom venni magam (és időm lesz rá), akkor a végeredmény nagyon hasznos lenne.
29

A kommentekre azért van

inf · 2012. Júl. 3. (K), 07.07
A kommentekre azért van szükség mert php nem típusos nyelv, és mondjuk egy visszatérő értékről, vagy egy gyűjteményből kivett változóról nem fogja tudni az IDE, hogy az milyen típusú. Enélkül nem is nagyon megy az automatikus kiegészítés...
30

ötlet(?)

Pepita · 2012. Júl. 3. (K), 23.46
Ugyan nekem "semmi közöm" a PHP nyelv fejlesztéséhez, de talán lenne erre jobb megoldás is: interface réteg az osztályok elején.
Ez nem az én ötletem, Delphi-ben remekül műxik, tetszőleges öröklődési mélységig használható, plusz még szintaktikai ellenőrzés szintjén is figyel rá, hogy egy osztály forrását ne akard többször "include-olni".
31

Nyilván használok interface-t

inf · 2012. Júl. 4. (Sze), 13.43
Nyilván használok interface-t is, nem erről van szó...
pl egy sima változónál csak így megy a kódkiegészítés, ha olyan helyről szeded elő, amiről nem lehet biztosan tudni, hogy mit ad vissza:

foreach ($map as $content)
/* @var $content MyClass */
    $content-> ...
Ha interface-t használsz, akkor is ugyanúgy meg kell adni a visszatérő értékeknél a típust:

/** @return MyClass */
public function getMyClass();
Ja és igen, / jel után az egy vagy két csillag nagyon nem mindegy... (Legalábbis netbeans 7-es elég hülyén kezeli... Még nem váltottam újabb verzióra, ott talán javították.)
32

Két csillaggal ugye phpdoc

tgr · 2012. Júl. 4. (Sze), 21.28
Két csillaggal ugye phpdoc lenne, annak meg hibás, gondolom ezért írják egy csillaggal.
33

Valszeg, nem tudom. Mondjuk

inf · 2012. Júl. 4. (Sze), 22.32
Valszeg, nem tudom. Mondjuk elég gáz, hogy phpdoc-ban nincs ilyen lehetőség.
34

Ezt értem, nem erre gondoltam

Pepita · 2012. Júl. 4. (Sze), 23.23
Másképp működik a PHP interface, mint a Delphi.
Pont arra akartam kijukadni, hogy Delphiben meg kell hívjam az aktuális objektumom interface-ében uses után azoknak az osztályoknak a forrását, amikből ezen szülőobjektumon belül példányt akarok használni. Ez egyetlen uses lista az én unitom elején - és máris működik a kódkiegészítésem is, sintax-check, stb, fordításkor meg optimalizálja, hogy az egész projektbe "egy osztály csak egyszer legyen befordítva". (Természetesen ez a családfára is értendő.)

Nagy különbség a kettő közt, hogy az ObjectPascal erősen típusos, a Delphi pedig igencsak fizetős... (Bár azt hallottam, van/volt már ingyenes verziója is.) De itt ugye a típusosság az, amin a PHP "elcsúszik", ha jól értem az eddigieket. Pedig valami ilyesmi varázslás - nekem - hietetlenül jól jönne...

ha olyan helyről szeded elő, amiről nem lehet biztosan tudni, hogy mit ad vissza
Ez még nem teljesen tiszta. A $map is kapott előzőleg egy/több értéket valahonnét, nem? Hát akkor az alapján kell tudni a típusát. (Bár ha pl. mysql_fetch_object adta az erdményt, akkor akár stdClass is lehet, annak meg honnét ismerné a tulajdonságait.)

Az egy és két csillag közt a különbség az interface, vagy a változó/függvény? (Mi a szabály?)

Na, ezeken még filóznom kell, elnézést az elmélkedésért és köszönöm mindenkinek az okítást, a napokban rengeteget tanultam itt!
35

A property és a metódus meg

inf · 2012. Júl. 5. (Cs), 02.52
A property és a metódus meg minden más két csillag. A lokális változó egy csillag, mert az nincs bent phpdoc-ban.

A map-ről azért nem tudja, hogy mi van benne, mert az egy általános tároló, amibe mindent betehetsz. Mivel php gyengén típusos, ezért nincs bent olyan, mint pl java-ban a generics (nem tudom mi a magyar neve)... Pont ezért betehetsz akár vegyes típusú értékeket is egy gyűjteménybe. Ez rugalmas, viszont a gond akkor van, amikor ki akarod venni őket, mert ott nem lehet automatikusan megállapítani, hogy minek milyen a típusa, úgy meg pláne nem, hogy menjen is rá a kód kiegészítés... A foreach ciklusnál meg szintén bukó emiatt a kódkiegészítés. Az összes változó deklarációra meg kell adni kommentben a típust, a metódusok visszatérő értékéhez szintén meg kell adni. Egyedül a metódusok paramétere az, ami ímmel-ámmal típusos, de az sem működik egyszerű típusokra (kivétel tömb), csak objektumokra. Szóval a típusellenőrzés a php-ben nagyon el lett gányolva... (Gondolom itt is a visszafele kompatibilitásra hivatkoztak, mint ahogy egyébként szokták ilyen esetekben.)
36

Köszi!

Pepita · 2012. Júl. 5. (Cs), 03.41
Most csak ezt nem értem:
,mert az nincs bent phpdoc-ban
:)
Tehát a property és a metódus meg minden más bent van? Hol, a fájl elején (class előtt)?
A PHP szerintem azért ilyen-amilyen, mert egy egyszerű (nem OOP) szkriptnyelvnek indult azzal a céllal, hogy minél egyszerűbb legyen szerveroldalon csip-csup programocskákat futtatni. Aztán ezt fejlesztik tovább-tovább, ma már komoly OOP-t szeretnénk, de a nem megfelelő alapok miatt ez nyögvenyelős. Viszont fontos a visszafelé kompatibilitás is. A történelmét nem ismerem, csak tippelek. De sok olyan tulajdonsága van a nyelvnek, ami inkább jellemző egy struktúrált nyelvre, mint OOP-re.
37

Úgy értem, hogy a

inf · 2012. Júl. 5. (Cs), 09.41
Úgy értem, hogy a szabványban...

Nekem csak az nem tetszik, hogy gányolnak, és a visszafele kompatibilitásra fogják az egészet. Pl a string függvények között meg sem próbáltak rendet tenni, pedig ha berakják őket több névtérbe, meg normálisan megcsinálják a paraméterezésüket és a karakterkódolás beállítását, akkor még talán használhatóak is lennének. Így kénytelen voltam saját utf-8 String libet csinálni, amiről legalább tudom, hogy melyik függvényt mit csinál configtól függetlenül...

Attól, hogy script nyelvnek indult még nem muszáj elgányolni a típusellenőrzést. A mai napig nem értem, hogyha az array-re (mint egyszerű típusra) tudtak type hint-et csinálni, akkor a string-re, integer-re, boolean-re miért nem. További érdekesség, hogy a 0-ból és a false-ból ''-re konvertálnak, ami szintén elég idegesítő tud lenni. De még sorolhatnám. Az egész nyelv egy átgondolatlan katyvasz. Ezt már sokan elmondták róla egyébként, csak valamiért a php hívők képtelenek elhinni. Ez kb ugyanolyan, mint a js-nél crossbrowser keretrendszert csinálni. Az erőfeszítések nagy része arra megy el, hogy egy jól használható közös felületet hozzál létre, csak azért mert az eredetit más elrontotta, és képtelen beismerni a tévedését, és kijavítani a hibát.
38

Típusos nyelv

Pepita · 2012. Júl. 5. (Cs), 23.56
Ha egy típusos nyelv lenne elterjedt a weben (is), akkor lényegesen egyszerűbbek lennének ezek a dolgok. Hát még ha nem interpreteres lenne... Az mondjuk egy szatyor biztonsági kérdést is áthidalna. Persze senkinek sem kötelező LAMP szerverre fejleszteni, de a többi elérhető szolgáltatás drága, ritka, körülményes.
Kliens oldalon persze már más a helyzet. Általában én optimista vagyok, de nemigazán tudom elképzelni, hogy az én életemben kompatibilisek (netán szabványosak) lesznek a böngészők. A gyártóknak nem érdekük, a W3C meg tutyimutyi és a gyártóktól kapja a pénzét...
39

A mai napig nem értem, hogyha

tgr · 2012. Júl. 6. (P), 22.51
A mai napig nem értem, hogyha az array-re (mint egyszerű típusra) tudtak type hint-et csinálni, akkor a string-re, integer-re, boolean-re miért nem.


Mert gyakrabban gáncsolnád el magad az automatikus bool-int-string típuskonverziók miatt, mint ahányszor ténylegesen hasznodra lenne.

További érdekesség, hogy a 0-ból és a false-ból ''-re konvertálnak


0-ból '0'-ra konvertál (nyilván). Booleannál meg teljesen logikus döntés, mert nem szeretnénk, ha bool->string->bool konverziónál változna az értéke.

Ez kb ugyanolyan, mint a js-nél crossbrowser keretrendszert csinálni. Az erőfeszítések nagy része arra megy el, hogy egy jól használható közös felületet hozzál létre, csak azért mert az eredetit más elrontotta, és képtelen beismerni a tévedését, és kijavítani a hibát.


Azok a nyelvek, amiket használnak, általában csúnyábbak, mint azok a nyelvek, amiket nem használnak, mert nem lehet ötletszerűen változtatni az interfészüket. A Javascriptnél ehhez még hozzájön az is, hogy semmi kontrollod nincs a futtatási környezet felett; PHP-ben (főleg ha saját magad által hostolt programot fejlesztesz) ennél azért lényegesen rózsásabb a helyzet.
40

false = ''

Pepita · 2012. Júl. 7. (Szo), 00.29
Booleannál meg teljesen logikus döntés, mert nem szeretnénk, ha bool->string->bool konverziónál változna az értéke.
Szerintem ebből a szempontból lényegtelen a string értéke. Ha bool->string esetén 'false'-t csinálok, akkor is vissza tudom alakítani. (Vagy nem értem, mit értesz értékváltozás alatt.)
Szerintem inkább könnyítés akar ez lenni a fejlesztőktől nekünk, ha meggondolod, csomószor csinálsz olyan függvényt, ami ha minden ok, stringet ad vissza, ha hiba van, false-t (beépített is sok van).
MVC: view-ban kapsz egy tartalomrészt, így nem kell feltétel (pl. isset), egyszerűen kiírhatod, akkor is, ha false. Meg egy csomó más helyzetben is rövidíteni tudja a kódot (futásidőt); nem egy szép megoldás, de ki lehet használni.
41

Nekem csak annyi gondom volt

inf · 2012. Júl. 7. (Szo), 16.10
Nekem csak annyi gondom volt ezzel a boolean-el, hogy adatbázisba nem lehet egy az egyben betenni, hanem kell írni egy if-else-t, és átalakítani '0','1' -re...
43

Hát éppen tárolhatod

tgr · 2012. Júl. 8. (V), 14.20
Hát éppen tárolhatod adatbázisban is üres stringként a false-t és akkor nem kell átalakítani. De jó esetben bindolod a paramétereidet, és akkor a DB réteg úgyis elintézi ezt helyetted.
42

Mert gyakrabban gáncsolnád el

inf · 2012. Júl. 7. (Szo), 16.11
Mert gyakrabban gáncsolnád el magad az automatikus bool-int-string típuskonverziók miatt, mint ahányszor ténylegesen hasznodra lenne.

Ezt elmagyaráznád? Én sehol nem használom az automatikus típuskonverziót (a number->string kivételével), mert szeretem tudni, hogy mi van 1-1 változóban...
44

Pl. megtalálod-e ebben a

tgr · 2012. Júl. 8. (V), 14.34
Pl. megtalálod-e ebben a hibát ránézésre?


function loadUserData(DbConnection $conn) {
    $result = $conn->query('SELECT username, email, access_level from user');
    $users = array();
    while ($row = $result->fetchAssoc()) {
        $username =    (string) $row['username'];
        $email =       (string) $row['email'];
        $accessLevel = (int)    $row['accessLevel'];
        $users[$username] = array('email' => $email, 'accessLevel' => $accessLevel);
    }
    return $users;
}

function processUser(string $username, string $email, int $accessLevel) {
    echo "$username is " . ($accessLevel ? "" : "not ") . "admin";
}

foreach (loadUserData(getConnection()) as $username => $data) {
    processUser($username, $data['email'], $data['accessLevel']);
}
45

A lekérésben access_level

inf · 2012. Júl. 8. (V), 18.43
A lekérésben access_level van, a row-nál meg accessLevel, így az accessLevel változó először (int) null = 0-t kap, utána meg false lesz a kiírásnál minden esetben.

Jó, hát egyébként erre az egészre mindenképp kell egy automatikus konverter, ami jelez ilyen hibáknál, mert különben sok lesz a duplikált kód, amiben könnyű hibázni...
46

Most mondhatnám, hogy olyan

tgr · 2012. Júl. 9. (H), 01.37
Most mondhatnám, hogy olyan ravasz vagyok, hogy több hibát is elrejtettem benne, de igazából csak az egyik volt szándékos: ha a user olyan nevet ad meg, ami számként is értelmezhető, akkor a PHP automatikusan integerré fogja konvertálni, amikor berakod a tömbbe és visszaolvasod belőle, úgyhogy a type hinting meghalna az ilyen userneveknél. Hasonló szopások vannak int-float vonatkozásban is (pl. (int)floor($x) == floor($x) nem felétlenül teljesül), szóval a primitív típusokra vonatkozó type hint nem feltétlenül lenne kezdőbarát feature (és ehhez képest óriási haszna nincsen), márpedig a PHP fő erénye a kezdőbarátság.

(Ez is érdekes olvasnivaló a témában.)
47

(Apró kérdés)

Pepita · 2012. Júl. 9. (H), 01.47
A lekérdezésben az access_level-ből hogyan lett a $row = $result->fetchAssoc() után $row['accessLevel']? Gyanítom, hogy ez nem hiba, csak nem látom, hogyan műxik.
49

De, az hiba.

tgr · 2012. Júl. 9. (H), 13.51
De, az hiba.
48

Egyébként van olyan, akinek

inf · 2012. Júl. 9. (H), 10.20
Egyébként van olyan, akinek bejön ez az automatikus típus konverzió? Rám csak a frászt hozza...
Ha rajtam múlna, akkor ezt az egészet elfelejteném, és olyan nyelvet csinálnék, aminél bár nem lenne muszáj, de lehetőség lenne típust ellenőrizni. Én ezt általában is megcsinálom, mert rengeteg hibát már az elején megfog, hogy pl neked boolean kell és nem null...
50

Ha meg akarod szeretni az

tgr · 2012. Júl. 9. (H), 13.59
Ha meg akarod szeretni az automatikus típuskonverziót, tanulj meg valamilyen szigorúan típusos nyelvben programozni (pl. Ada). Amúgy meg a típuskonverzió kényelmes: tudsz olyanokat írni, hogy $_GET['a']+$_GET['b'], anélkül, hogy egyáltalán értened kéne, hogy mik azok a típusok. Ha ezen felül még unicode string támogatás is van a nyelvben (amit hosszú távon nyilván a PHP sem fog megúszni), akkor meg egészen nagyon fájdalmas tud lenni, ha nem konvertál automatikusan a sima és unicode string között (vö. Python, pedig az csak néha nem teszi).
51

Megoldás

Pepita · 2012. Szep. 4. (K), 16.32
Hát, többször is neki kellett fussak (hamar felkaptam a vizet), végül inf3rno 1-es válasza és szabo.b.gabor 19-es és 27-es válaszai alapján végre sikerült megoldanom Komodo Edit 6.1 alatt. Szerintem a 7.x verzióval ugyanígy működni fog, de ezt még nem próbáltam.

A fő megoldás: az 1-nél közölt PHPDOC-ot nem autocomplete.php-ban kell megadni, hanem magában a Controller osztályt leíró ./system/core/Controller.php fájlban. Rövidítve így:
/**
 * @property CI_DB_active_record $db
 * @property CI_DB_forge $dbforge
 * @property CI_Benchmark $benchmark
 * ITT rövidítettem
 * @property CI_Zip $zip
 */
class CI_Controller {

	private static $instance;

	/**
	 * Constructor
	 * @access	public
	 * @return	object
	 */
	public function __construct()
	{...
Mindjárt látszik is, hogy odatettem a konstruktor elé is - biztos ami biztos - a hozzáférést és a visszatérési értéket. Ez utóbbiak nem tudom, hogy feltétlenül kellenek-e, de minden más ("gyári") osztályban is pótoltam, ahol nem volt. Ugyanezt tettem a Model.php-val is (és ebbe is az összes gyermekosztályt betettem, szemben az inf3rno-tól kapott megoldással).

Így van kódkiegészítés (és marhára örülök :)) az alaposztályokban, ámde a saját kontrollerekben - modelekben még nincs. Valszeg ahhoz azoknak a változóit is meg kéne adni a Controller.php-ban.

Hibák:

- Elsősorban erre az autocomplete.php-ra hívom fel a figyelmet: ebben class Controller {}; szerepel, de a 2.1.0 verzióban (gondolom 2.0-tól) class CI_Controller van.

- Lehet, hogy inf3rno "hülyét kap", de első próbák között szerepelt a Netbeans IDE 7.1.2 is, ugyanúgy nem volt kódkiegészítés, ezzel a fájllal sem, de akkor még nem javítottam benne a hibás osztálynevet...

- Belefutottam egy csúnyaságba. A próba-könyvtárból, ahol már ment a kódkieg., átmásoltam "külsőleg" a system megfelelő fájlait egy épp fejlesztés alatt lévő projekt system-ébe. És nem lett tőle kódkieg. Kiakadtam. Rá kellett u.is vegyem Komodo-t, hogy scannelje újra a könyvtárat (gondolom igencsak puffereli az eredményt). Erre semmilyen megoldást nem találtam a súgójában, ezért megnyitottam a projekten belül a Controller.php-t és a Model.php-t és itt "kézzel" újra módosítottam a comment részt. Ettől megjavult. De mire erre rájöttem... :(

- Mindenre van kódkiegészítés. Mármint minden gyermekosztályt lehet látni változóként kontrollerben (modelben), azokat is, amik nincsenek betöltve a loaderrel. És nem is jelez syntax errort, tehát vigyázni kell (nekem), hogy a $this->load->library('Osztály'); előbb legyen. De ez már kicsike problem.

Szóval nehéz volt, sok idegbaj, de végül sikerült. Köszönöm nektek.
52

Küldd át nekem az eredetit,

inf · 2012. Szep. 4. (K), 20.52
Küldd át nekem az eredetit, amin nem volt kódkieg netbeans-ben. Megmondom mi a baja... :-)

Egyébként próbáld ki a symfony2-t, most néztem át a kódját, és azóta mindenkinek ajánlgatom... :D
53

Elküldtem

Pepita · 2012. Szep. 7. (P), 15.48
Szerintem az osztályok neve, de nekem igazából mindegy, Komodo jobban bejön.

Symfony2? Egyszer talán, ha lesz rá időm. Nekem a CI nagyon bejön. (Főleg így, kódkiegészítéssel.) A 3.0-át még nem néztem, lehet, ha az már nem annyira tetszetős, akkor váltani fogok.
54

Nézem. Nem biztos, hogy

inf · 2012. Szep. 7. (P), 15.57
Nézem. Nem biztos, hogy segíteni tudok rajta, @property-t sosem használok, mindig @var-t rakok a property deklaráció elé, az működik rendesen. Lehet, hogyha nincs deklaráció, csak így adod meg, akkor azt nem veszi be netbeans. Majd jövő héten kipróbálom, most sok a dolgom.