Forum PHP Romania - Discutii despre PHP, MySQL, Javascript, AJAX, etc

[aurelian]

medick este inca un framework php (YetAnotherPHPFramework).

Cunoscut sub numele intern de locknet7, medick este publicat sub licenta BSD iar developmentul se va desfasura pe http://berlios.de .
In acest moment statutul proiectului este "Planning", probabil undeva pe la inceputul lunii septembrie va fi publicata prima versiune alfa spre download (in functie de timpul liber pe care il am).
O versiune stable va fi oferita in jurul datei de 15 martie 2006, noi sa fim sanatosi.
Oricum, codul sursa poate fi obtinut de pe svn:
Cod:
svn checkout svn://svn.berlios.de/medick/trunk

sau poate fi citit folosind interfata web: http://svn.berlios.de/wsvn/medick

Inspirat puternic din RoR, medick ofera un mediu pentru dezvoltarea cu usurinta a aplicatiilor web(si nu numai) in php.

medick, este un framework OOP ce va functiona cu php 5 (0.3 si 0.4 tested), server web (de preferinta apache + mod_php + AllowOverwrite All, optional mod_rewrite sau lighttpd + fast cgi + access la server) si RDBMS.
In acest moment se foloseste creole pentru DB Abstraction Layer, insa spre sfarsitul anului (low priority) sper sa ofer si un inlocuitor.

medick este testat cu SimpleTest (testele nu sunt inca pe svn).

Avantaje:
-> separarea codului de continut.
-> dezvoltarea de aplicatii de dimensiuni medii/mici in timp foarte scurt
-> securitate sporita
-> o buna integrare cu tehnologii XML, XMLHTTPRequest sau servicii web (SOAP)
-> no more copy/paste code!
-> ActiveRecord ALA RoR
-> template engine :) + integrare cu PHPTAL (planned) + Smarty (cand va aparea o versiune php 5 only).
-> sistem de caching
-> sistem de logging

In curand planuiesc sa lansez si siteul oficial http://medick.locknet.ro si sper ca acesta sa fie powerd by medick!

Mai multe detalii in curand (features, planned features, etc), orice critica este bine-venita.

Apropos, numele vine de la o planta cu flori galbene din familia fabaceelor.
http://www.stagespondnaturepreserve.info/photos/black%20medick.jpg

[strategy]

suna temptanpt .. mai ales ca am auzit numa de bune despre ruby .. cu al sau rails .. iti urez supces .. sa iasa ceva misto..

[aurelian]

strategy a scris: suna temptanpt .. mai ales ca am auzit numa de bune despre ruby .. cu al sau rails .. iti urez supces .. sa iasa ceva misto..

10x.
Timp sa fie ca o sa iasa ceva profesional :)

[aurelian]

Dupa aproape 10 luni de munca, prima versiune medick
ce include un pachet destul de tentant de facilitati
si cu un API destul de solid a fost lansata.

Anuntul oficial
Download si alte detaill

[carco]

First, felicitari. Cred ca esti rupt pentru ca ai prestat ceva acolo (si nu oricum ci folosind ultimele tehnici in materie de OOP si nu numai).

Prima impresie: Sincer, nu cred ca o sa folosesc vreodata ceva realizat in genul acesta. Se indeparteaza prea mult de principiul KISS.

Acum, sa trecem peste dulcegarii ;) si sa mergem la treburi serioase.

Cateva chestii care m-au deranjat la o prima joaca cu Medick:

- la conf, dependenta de "absolute path". Parerea mea, ai index.php, ai calea absoluta la root-ul sitelui. In index.php, ai inclus boot.php, ai calea absoluta la framework, mai departe foloseste cai relative, nu ma obliga sa mesteresc prin conf-uri de cate ori schimb locatia folderelor. E drept, eu le-am setat in conf relativ, insa medick.php le genereaza cu cai absolute. Eu le-am refacut asa (pt. eltodo):
Cod:
        <properties>
            <path>..</path>
        </properties>
...
        <property name="path" value="../log/eltodo.log" />


- Tot la conf, ref. la <property name="address" value="user@example.com" />. In ideea ca un user grabit ar sari peste ea, sa verifici cumva daca nu a ramas default-ul "user@example.com" si sa afisezi un warning: ba, vezi ca nu ai setat adresa de mail?

- Tot la conf, nu-mi place formatul xml. Parerea mea e ca introduci un load suplimentar si nenecesar (loadxml, parsare, setare environment). Cu un .php s-ar face totul dintr-un pas. Daca iti place metoda XML, atunci routemap de ce l-ai pus .php?

- la ActiveRecord, posibil sa ma insel insa asa pare la prima vedere, ma legi de maini cu table_name. De ce nu pot eu sa am modelul Datorie si pe tabela sa o cheme Datorii? Initial cand am vazut protected $table_name; m-am bucurat, insa in controller suprasctii table_name (acu sa nu zici ca pot sa-mi scriu propriul controller).

- prea multe "final"-uri, lasa-ma si pe mine sa mai adaug una alta la metodele tale. Daca ma obligi sa modific direct in framework o sa fie greu de upgradat ulterior.

- structura directoarelor, eu as fi facut ceva de genul
Cod:
eltodo/
 .framework/{app,conf,db,...}
 files/{images,javascript,...}
 index.php

de ce? pai acum imi pot proteja dir-ul framework cu un simplu 'deny from all', asa va tb. sa le pun in alta locatie (nu-i problema cand lucrezi pe masina ta insa daca esti pe masina altora...)

- include vs required, de ce include?
- _once, ar fi frumos sa nu fie nevoie de acel once, macar pentru fisierele ce stii sigur ca tu nu le incluzi de 2 ori.

[aurelian]

Merci de felicitari, nu sunt rupt, pentru ca daca as face o medie in cele 10 luni cred ca ar iesi cam 10-20 minute / zi :)

Mai mult, merci pentru ca ti-ai dat cu parerea si ca ai avut rabdare sa il incerci.

em@il a scris:
- la conf, dependenta de "absolute path". Parerea mea, ai index.php, ai calea absoluta la root-ul sitelui. In index.php, ai inclus boot.php, ai calea absoluta la framework, mai departe foloseste cai relative, nu ma obliga sa mesteresc prin conf-uri de cate ori schimb locatia folderelor. E drept, eu le-am setat in conf relativ, insa medick.php le genereaza cu cai absolute. Eu le-am refacut asa (pt. eltodo):

- Da ai dreptate, dar ma gandeam si pe viitor (deocamdata nu am o idee concreta legata de pastrarea setarii acolo). Poate o sa scot chestia asta.
Este vorba si de niste modificari facute pe ultima suta de metri.
La fel, ai dreptate si cand e vorba de cai relative. Sigur ca merge si asa.
em@il a scris:
- Tot la conf, ref. la <property name="address" value="user@example.com" />. In ideea ca un user grabit ar sari peste ea, sa verifici cumva daca nu a ramas default-ul "user@example.com" si sa afisezi un warning: ba, vezi ca nu ai setat adresa de mail?

- Nu stiu exact ce se intampla acum, teoretic ar trebui sa trantesc o exceptie or something.
em@il a scris:
- Tot la conf, nu-mi place formatul xml. Parerea mea e ca introduci un load suplimentar si nenecesar (loadxml, parsare, setare environment). Cu un .php s-ar face totul dintr-un pas. Daca iti place metoda XML, atunci routemap de ce l-ai pus .php?

- O sa ma gandesc si la lucrul asta sa vad cum o sa incerc sa il corectez.
em@il a scris:
- la ActiveRecord, posibil sa ma insel insa asa pare la prima vedere, ma legi de maini cu table_name. De ce nu pot eu sa am modelul Datorie si pe tabela sa o cheme Datorii? Initial cand am vazut protected $table_name; m-am bucurat, insa in controller suprasctii table_name (acu sa nu zici ca pot sa-mi scriu propriul controller).

- este vorba despre respectarea unor standarde, in schimb primesti destule facilitati gratis, de ex. validari sau asocieri.
em@il a scris:
- prea multe "final"-uri, lasa-ma si pe mine sa mai adaug una alta la metodele tale. Daca ma obligi sa modific direct in framework o sa fie greu de upgradat ulterior.

- din nou ai dreptate, am bagat chestia aia intr-un moment de panica cand am suprascris din greseala o metoda. Si m-am gandit daca eu am facut asta care sunt cat de cat familiar cu API-ul, cum ar face-o un alt programator?
em@il a scris:
structura directoarelor, eu as fi facut ceva de genul

- Eu vreau sa am mai multe aplicatii care ruleaza pe acelasi base-code, si sa pot face schimbari in framework fara sa afectez toate aceste aplicatii, sau sa trebuiasca sa copiez/suprascriu fisiere.
em@il a scris:
de ce? pai acum imi pot proteja dir-ul framework cu un simplu 'deny from all', asa va tb. sa le pun in alta locatie (nu-i problema cand lucrezi pe masina ta insa daca esti pe masina altora...)

- doar directorul public ar trebui asezat sub document_root in alte cazuri, mda un deny from all trebuie adaugat.
em@il a scris:
- include vs required, de ce include?
- _once, ar fi frumos sa nu fie nevoie de acel once, macar pentru fisierele ce stii sigur ca tu nu le incluzi de 2 ori.

chestie de gusturi :)

[carco]

aurelian a scris: nu sunt rupt, pentru ca daca as face o medie in cele 10 luni cred ca ar iesi cam 10-20 minute / zi Smile
asta-i bine. Eu cand ma prind intr-o chestie nu prea mai pot sa o las pana nu ajung la un rezultat palpabil.

aurelian a scris:
- Eu vreau sa am mai multe aplicatii care ruleaza pe acelasi base-code, si sa pot face schimbari in framework fara sa afectez toate aceste aplicatii, sau sa trebuiasca sa copiez/suprascriu fisiere.

pai in forma data eu nu m-am atins de directorul cu aplicatii, era reorganizarea structurii de directoare _din_ cadrul unei aplicatii, adica pus ce nu trebuie accesat direct (conf-ul, controllerele, views-urile) intr-un singur director pentru a putea fi protejat dintr-o bucata.


aurelian a scris:
em@il a scris:
- la ActiveRecord, posibil sa ma insel insa asa pare la prima vedere, ma legi de maini cu table_name. ...

- este vorba despre respectarea unor standarde, in schimb primesti destule facilitati gratis, de ex. validari sau asocieri.

Stiu ca eu un standard, dar e un standard folosit pt. automatizare (adica daca nu am setat eu nimic, folosesti valoare automata).
Tot nu pricep de ce nu poti folosit table_name mai departe. Poate o sa ma uit prin cod sa vad unde anume ar incurca folosirea 'table_name' in loc de forma standard.


aurelian a scris:
em@il a scris:
- include vs required, de ce include?
- _once, ar fi frumos sa nu fie nevoie de acel once, macar pentru fisierele ce stii sigur ca tu nu le incluzi de 2 ori.

chestie de gusturi :)

La include vs required sa zicem ca-i chestie de gusturi, insa la _once daca nu ma insel eu prea mult, se pune un lock ca sa se asigure acele _once. lock ce mai papa si el putinele resurse. Totusi o aplicatie bazata pe medick va avea ceva de incarcat (e destul de stufoasa ca structura de fisiere) si, fara un sistem de cache (la nivel de server sau de aplicatie), s-ar putea sa conteze fiecare microsecunda risipita.

Citat:
Mai mult, merci pentru ca ti-ai dat cu parerea si ca ai avut rabdare sa il incerci.

Doar l-am facut pe eltodo si am rasfoit codul. Sincer mi-a luat ceva pana m-am dezmeticit si mi-am facut o idee despre cum functioneaza lucrurile (o privire de ansamblu, normal). Sper sa imi fac timp sa incerc sa realizez o mini aplicatie, atunci o sa pot "comenta" mai mult.

[aurelian]

em@il a scris:
pai in forma data eu nu m-am atins de directorul cu aplicatii, era reorganizarea structurii de directoare _din_ cadrul unei aplicatii, adica pus ce nu trebuie accesat direct (conf-ul, controllerele, views-urile) intr-un singur director pentru a putea fi protejat dintr-o bucata.

yup, poate nu inteleg eu prea bine (abia m-am trezit) dar doar directorul public trebuie mutat sub document_root.

em@il a scris:
La include vs required sa zicem ca-i chestie de gusturi, insa la _once daca nu ma insel eu prea mult, se pune un lock ca sa se asigure acele _once. lock ce mai papa si el putinele resurse. Totusi o aplicatie bazata pe medick va avea ceva de incarcat (e destul de stufoasa ca structura de fisiere) si, fara un sistem de cache (la nivel de server sau de aplicatie), s-ar putea sa conteze fiecare microsecunda risipita.


10x pentru hint, o sa incerc sa corectez.

em@il a scris:
Sper sa imi fac timp sa incerc sa realizez o mini aplicatie, atunci o sa pot "comenta" mai mult.
Asta e deja prea mult :)
Daca ai nevoie de ajutor, intreaba-ma :)

O sa raspund si la celelalte chestii putin mai tarziu.

[carco]

aurelian a scris:
yup, poate nu inteleg eu prea bine (abia m-am trezit) dar doar directorul public trebuie mutat sub document_root.

dar eu nu l-am mutat :)
Oricum, am rezolvat-o cu un deny from all si, sub public, allow from all.

[aurelian]

exemplu de structura folosita de mine:

$HOME === $DOCUMENT_ROOT (yeah, super sucks dar asa e hostingul)
si:
framework:
$DOCUMENT_ROOT/medick
$DOCUMENT_ROOT/medick/libs/
[..........]
$DOCUMENT_ROOT/medick/boot.php

aplicatii:

$DOCUMENT_ROOT/applications/eltodo
$DOCUMENT_ROOT/applications/eltodo/conf/
[......................]
$DOCUMENT_ROOT/applications/eltodo/public/
$DOCUMENT_ROOT/applications/eltodo/public.index.php

si am facut linkuri simbolice:

ln -s $DOCUMENT_ROOT/applications/eltodo/public/ $DOCUMENT_ROOT/eltodo

normal, $DOCUMENT_ROOT/medick/ are un .htaccess cu deny from all
la fel si in $DOCUMENT_ROOT/applications/

[carco]

Mi-am prins urechile :)
Deci, m-am apucat sa extind eltodo (sa adaug intr-o prima faza partea de "edit")...
Bun, prima faza banala (cu find si afisat formularul), acum am ajuns la salvare
am zis eu asa ceva
<?php     public function edit() {         if(!isset($this->params['project'])) { //editare             $this->project=Project::find($this->params['id']);         } else { //try to save data             $this->project= new Project($this->params['project']);             $this->project->id=$this->params['id'];             try {                 if ( ( $result=$this->project->save() )===false ) {                     $this->logger->debug('Cannot update.');                     return $this->render('edit');                 }                 if ( $result ) {                     $this->flash('notice', 'Project <i>' . $this->project->name .                              '</i> updated!');                 } else {                     $this->flash('notice', 'Project <i>' . $this->project->name .                               '</i> NOT updated (no changes)!');                 }                 return $this->redirect_to('all');             } catch (Exception $ex) {                 $this->logger->warn($ex->getMessage());             }         }     } ?>
E aproapre de conceptia ta? Am indoieli asupra 'asignarii' id-ului. (pana raspunzi tu ma chinui sa implementez edit si add in aceasi actiune "edit". (fara edit/save add/create)

Ceva incurcatura: mi-a prins urechile in $this->save() because ca atunci cand nu modificam nimic imi returna 0 (pana la urma m-am prins ca e de la update-ul care intoarce nr. de randuri afectate).

Problema: la partea cu unicitatea in aceasta forma nu-mi merge (si crede-ma ca am sapat ceva).
Nu m-am prins eu, sau in caz de modificare, la unicitate nu adaugi conditia id<><id-ul curent>? In forma de mai sus functioneaza fara unicitate pe nume (adica //$this->validates()->uniqueness_of('name');)

[aurelian]

sa le luam pe rand.

In Controller chiar daca exista parametrii din request in array-ul $params, cred ca mai bine ar fi sa folosesti direct obiectul request, pentru ca te salveaza de o verificare (isset):
in loc de $this->params['project'] sa folosesti: $this->request->getParameter('project'); chiar daca e mai urat si o sa iti dea NULL daca nu exista (deci nu eroare php).

teoretic, partea de edit ai putea sa o faci asa:

an style="color: #000000"><?php /** afiseaza formularul */   public function edit() {     try {       $this->project= Project::find($this->request->getParameter('project'));     } catch (RecordNotFoundException $rnfEx) {      // trateaza exceptia     }   }   /** update */   public function update() {        try {       $this->project= Project::find($this->request->getParameter('id'))->attributes($this->request->getParameter('project'));       if ($this->project->save() === FALSE) {         // erori! se afiseaza din view cu ActiveRecordHelper::error_messages_for($project)         return $this->redirect_to('edit');       }       // s-a salvat in BD:       $this->flash('notice', 'Project updated');       $this->redirect_to('index');     } catch (RecordNotFoundException $rnfEx) {       $this->logger->warn($rnfEx->getMessage());       $this->flash('error', $rnfEx->getMessage());       $this->redirect_to('index');     }      } 

Si vreo 2 explicatii:
In metoda edit, afisez formularul populat cu un project (bazat pe id-ul primit in request).

In update linia lunga se citeste asa:
- gaseste un project cu id-ul primit din request (in caz contrar, exceptia RecordNotFound este aruncata).
- populeaza vechile atribute ale acestui obiect, cu noile valori primite.

Apoi :incearca sa salvezi noile date.

Linia respectiva probabil se poate scrie si in alte 3 sau 4 moduri diferite.

save() returneaza nr. de randuri afectate sau 0 din cauza asta folosesc ===

metoda save esueaza (returneaza false) cand before_save returneaza false sau cand obiectul ce urmeaza sa fie salvat are erori.

referitor la validarea unicitatii, pot sa confirm ca este un mic bug.
se face practic inca un select de tipul:
select name from projects
iar in cazul in care sunt rezultate, validarea pica.
problema la update este ca acel select nu tine cont de id-ul obiectului curent (deci o sa imi gaseasca tot timpul un proiect cu acel nume).

ma gandesc la un workaround sau la o metoda de a fixa aceasta problema.

[aurelian]

Deseara o sa public si o scurta erata, am descoperit vreo 3-4 chestii care nu merg asa cum am planificat.

Later edit:
Erata la release 0.2.1

[copot]

Am tot incercat ieri sa fac exemplul ala al tau ELTODO sa functioneze cu MSSQL-u. (Am anumite probleme la niste scripturi si vroiam sa vad daca le pateste si altcineva).
Am creat o baza de date, tabela eltodo cu aceeasi structura.
Dar .... failed.

Ai testat Medicku` cu MSSQL ? - ma interesa in mod special ActiveRecord-ul.
Eu am primit niste erori.
Anyway, eram doar curios daca fac eu ceva gresit.

[aurelian]

copot a scris: Am tot incercat ieri sa fac exemplul ala al tau ELTODO sa functioneze cu MSSQL-u.

Merci pentru rabdare :)
copot a scris:
Am creat o baza de date, tabela eltodo cu aceeasi structura.
Dar .... failed.
Ai testat Medicku` cu MSSQL ? - ma interesa in mod special ActiveRecord-ul.

Din pacate nu am avut posibilitatea sa testez cu MSSQL.
copot a scris:
Eu am primit niste erori.
Anyway, eram doar curios daca fac eu ceva gresit.
Trmite-mi erorile pe care le primesti te rog + versiunea de MSSQL.

Oricum, cred ca problemele sunt mai de departe, probabil de la driverul MSSQL oferit de creole.
In functie de timp, o sa incerc sa fac rost de un server MSSQL pe care sa testez si sa remediez situatia :)

[PHPRomania Bot]