mapare clasa peste tabela

[vekand]

[nevvermind]

[vekand]

Inseamna ca array-ul cu variabilele de limba ar trebui sa-l fac in alta parte si in clasa doar sa-l folosesc cind e nevoie. Nici mie nu-mi place ca in clasa am functii INCLUDE. Mapperul nu stie de tabele HTML, el face doar un simplu array cu anumite cimpuri din tabela, acel array il folosesc in alta parte in afara clasei. Dar voi studia. Multumesc!

[vekand]

PS: am rezolvat cu variabilele de limba, fac array-ul in alta parte si il preiau ca parametru in constructorul clasei. Am scapat astfel de instructiunile INCLUDE din clasa. Acum mapper-ul stie mult mai putine.

[vekand]

Multumesc nevvermind pentru ajutorul acordat, am optimizat mapper-ele (foarte important!) dar vreau sa merg mai departe: vreau sa fac clasele de interogare (SELECT), eu am pus in mapper (in clasa parinte, linga INSERT, UPDATE, DELETE) o metoda SELECT care face SELECT * FROM tabela, dar nu e suficient, in majoritatea cazurilor am INNER JOIN intre tabele, deci nu pot aplica mapper-ul in aceste cazuri. O idee cum sa rezolv? Trebuie sa face alte clase, dar astea nu vor mai fi specializate. Multumesc.

[nevvermind]

Da, de asta urma sa te lovesti. Acum dai de un alt acronim: DBAL.

- http://framework.zend.com/manual/1.12/e ... elect.html
- http://docs.doctrine-project.org/projec ... ilder.html

Poti lua ruta intermediara, si sa faci niste helper-e (sau doar unul) specializate in interogari SQL, cu metode precum: select, innerJoin, outerJoin, insert, update, delete, createTable, addForeignKey etc. Astea vor primi mai multi parametri, in functie de necesitati. Apoi doar le chemi din mapper-ii tai.

[nevvermind]

As vrea totusi ca in thread-ul asta sa fie mai mult cod decat este acuma. Arata-ti clasa, omu, n-o mai ascunde atata.
Foloseste https://gist.github.com/ sau pastie.org cu un snippet privat ceva, sau direct in forum.

[vekand]

[vekand]

[vekand]

[nevvermind]

[vekand]

Multumesc de raspunsurile critice, chiar imi folosesc, dar cred ca eu nu m-am facut suficient inteles:
1. N-am copiat nimic de niciunde, "vararray" si altele citeva sint variabile intermediare (ajutatoare) pentru construirea de array-uri in clasa, aceste variabile nu "ies" din clasa, deci n-am considerat necesar sa le explicitez.
2. Clasele de interogari nu sint gindite ca mappere, singurele mappere pe care le am sint cele facute la inceput pe fiecare tabela, clasele de interogari sint doar clase care ma ajuta sa fac query-uri ma scutesc sa scriu manual array-ul HTML table si array-ul raport. De asta le-am pus pe fir separat. Dar mapperele mele (cele facute chiar in prima faza) arata exact cum mi-ai desenat in schita, iar ce ai pus in box-ul SELECT sint chiar clasele mele de interogare (care nu sint mappere).
3. "buildOnSecond" este metoda din clasa superioara si indica al doilea criteriu de relationare de dupa INNER JOIN (ex. INNER JOIN useri u ON e,iduser=u.user_id), deci ce este dupa semnul =. De altfel toate metodele sint definite in clasa superioara celei in care construiesc query.
4. Exista parent::__construct(); in clasa de jos, care merge direct la superclasa (nu mai trece prin clasa intermediara, acolo n-am nevoie de constructor).

Voirevedea in amanunt ce mi-ai spus si voi face corectille.

[nevvermind]

[vekand]

Consider ca toate observatiile tale sint corecte. Iti sint recunoscator pentru rabdarea ta.
Cred ca am farimitat prea mult metodele de la construirea query-ului. Trebuie sa le mai regrupez. Pe de alta parte mi-am dat seama ca nici clasa de interogare n-are nevoie de conexiune pentru ca SELECT-ul nu se executa aici, deci este tot un QueryBuilder.

N-am citit nici un PM, unde l-ai trimis?

[vekand]

PS: acum am citit PM-ul, voi studia.