Review CMF
Moderator: Moderatori
-
cezar.lucan
- Average Member
- Mesaje: 83
- Membru din: Joi Mar 11, 2010 2:18 pm
Review CMF
Ultima oară modificat Mie Aug 29, 2012 12:45 am de către cezar.lucan, modificat 1 dată în total.
-
cezar.lucan
- Average Member
- Mesaje: 83
- Membru din: Joi Mar 11, 2010 2:18 pm
Salut Mihai si multumesc pentru raspuns!!!! Incepusem sa imi pierd speranta 
Deoarece sunt pe drum si nu am timp voi raspunde direct la subiect:
A. Pentru inceput nu merge sa download-ez pe firefox (a mers cu chrome)
- Regret, nu e prima oara cand mi se intampla sa fac ceva modificari dar sa uit sa testez pe alte browsere; repar diseara
B. Structura aratata pe site-ul tau nu arata in nici un caz cu ceea ce am scos eu.
In ce sens? Te referi la strucura din overview? Acea structura este intocmai cum functioneaza frameworkul meu si am facut-o intocmai dupa motorul framworkului.
Daca te regeri la imaginea de pe prima pagina, aceea este ce mi-am propus si in proportie de 90% este realizata
C. Framework:
1. Design interesant
Multumesc
2. Nu e MVC
Nu in sensul in care sunt definite structurile MVC dar in functie de performatele fiecarui programator este destul de bine orientat MVC. Nu am vrut sa urmez acest "standard" deoarece prin flexibilitatea frameworkului consider ca l-as complica si nici nu vreau sa intru intr-o astfel de discutie pt ca este lunga ... prea!!
3. Nu se pot rescrie usor url-urile (nu are dispatcher/router)
De fapt acest framework a pornit chiar de la aceasta problema: intr-una din aplicatiile mele aveam nevoie sa schimb diferite atribute ale elementelor din pagina.
Deoarece este bazat pe xml, ai access instantaneu la orice element din pagina, indifirent unde anume esti in logica programului.
Ca solutie se pot folosi filtrele globale (user filters sau parsers) care sunt secvente de cod executate in toate aplicatiile ce ruleaza in framework.
O simpla adaugare a codului de mai jos in parsers.xml, rezolva problema:
<item>
<xpath>
//a
</xpath>
<callback>
selectia dupa calea aplicatiei (merge si cu $GLOBALS["appName"] daca este setat in /app/name)
switch(basename($el->getAttribute("href")))
{
case "app1.xml":
//codul aici
break;
....
}
</callback>
</item>
Acesta este un model de dispatcher pe care il poti folosi la orice, nu doar pt url-uri
4. Din cate am vazut eu pentru site in mai multe limbi folosesti sesiuni (google nu o sa mai inteleaga nimic)
Corect, la baza acestui framework se afla sesiunile.... Dar schimbarea limbii se face doar intr-o variabila din sesiune, si nu prin regenerarea id-ului sesiunii.
5. Etc.
?? Mai astept!!!
Cu respect!
Deoarece sunt pe drum si nu am timp voi raspunde direct la subiect:
A. Pentru inceput nu merge sa download-ez pe firefox (a mers cu chrome)
- Regret, nu e prima oara cand mi se intampla sa fac ceva modificari dar sa uit sa testez pe alte browsere; repar diseara
B. Structura aratata pe site-ul tau nu arata in nici un caz cu ceea ce am scos eu.
In ce sens? Te referi la strucura din overview? Acea structura este intocmai cum functioneaza frameworkul meu si am facut-o intocmai dupa motorul framworkului.
Daca te regeri la imaginea de pe prima pagina, aceea este ce mi-am propus si in proportie de 90% este realizata
C. Framework:
1. Design interesant
Multumesc
2. Nu e MVC
Nu in sensul in care sunt definite structurile MVC dar in functie de performatele fiecarui programator este destul de bine orientat MVC. Nu am vrut sa urmez acest "standard" deoarece prin flexibilitatea frameworkului consider ca l-as complica si nici nu vreau sa intru intr-o astfel de discutie pt ca este lunga ... prea!!
3. Nu se pot rescrie usor url-urile (nu are dispatcher/router)
De fapt acest framework a pornit chiar de la aceasta problema: intr-una din aplicatiile mele aveam nevoie sa schimb diferite atribute ale elementelor din pagina.
Deoarece este bazat pe xml, ai access instantaneu la orice element din pagina, indifirent unde anume esti in logica programului.
Ca solutie se pot folosi filtrele globale (user filters sau parsers) care sunt secvente de cod executate in toate aplicatiile ce ruleaza in framework.
O simpla adaugare a codului de mai jos in parsers.xml, rezolva problema:
<item>
<xpath>
//a
</xpath>
<callback>
selectia dupa calea aplicatiei (merge si cu $GLOBALS["appName"] daca este setat in /app/name)
switch(basename($el->getAttribute("href")))
{
case "app1.xml":
//codul aici
break;
....
}
</callback>
</item>
Acesta este un model de dispatcher pe care il poti folosi la orice, nu doar pt url-uri
4. Din cate am vazut eu pentru site in mai multe limbi folosesti sesiuni (google nu o sa mai inteleaga nimic)
Corect, la baza acestui framework se afla sesiunile.... Dar schimbarea limbii se face doar intr-o variabila din sesiune, si nu prin regenerarea id-ului sesiunii.
5. Etc.
?? Mai astept!!!
Cu respect!
-
vectorialpx
- Senior Member
- Mesaje: 4832
- Membru din: Mar Mar 01, 2005 9:48 am
- Localitate: Bucuresti
- Contact:
-
vectorialpx
- Senior Member
- Mesaje: 4832
- Membru din: Mar Mar 01, 2005 9:48 am
- Localitate: Bucuresti
- Contact:
-
cezar.lucan
- Average Member
- Mesaje: 83
- Membru din: Joi Mar 11, 2010 2:18 pm
@MihaiC
Am gresit in cod... rezolvat cu download-ul in Firefox!!!
@vectorialpx
Ai dreptate cu download-ul sa fie inainte, am modificat!!! Multumesc de idee!!
Cat despre Captcha, am fost obligat sa il pun deoarece cred ca unii se plictiseau si bagau download-uri la greu. Nu m-ar fi deranjat dar am un contor si il dadeau peste cap
Astept comentarii si intrebari!! Daca aveti nevoie de ajutor scrieti aici, poate documentatia nu e prea clara peste tot.
PS: filmele si pozele din documentatie sunt de la varianta 1.x. Diferenta este ca in 1.x tot codul (js, php) era in continutul de tip text al elementelor. In 2.x am schimbat cum era normal si tot ceea ce inseamna php este in processing instruction, toate celelalte (javascript, css si interogarile xpath) au ramas in text!
In plus toate exemplele le puteti descarca la adresa: http://www.aws-dms.com/uup/XMSAllEx.rar
Am facut si o serie de tutoriale, daca va uitati pe site le vedeti.
Multumesc!!
Am gresit in cod... rezolvat cu download-ul in Firefox!!!
@vectorialpx
Ai dreptate cu download-ul sa fie inainte, am modificat!!! Multumesc de idee!!
Cat despre Captcha, am fost obligat sa il pun deoarece cred ca unii se plictiseau si bagau download-uri la greu. Nu m-ar fi deranjat dar am un contor si il dadeau peste cap
Astept comentarii si intrebari!! Daca aveti nevoie de ajutor scrieti aici, poate documentatia nu e prea clara peste tot.
PS: filmele si pozele din documentatie sunt de la varianta 1.x. Diferenta este ca in 1.x tot codul (js, php) era in continutul de tip text al elementelor. In 2.x am schimbat cum era normal si tot ceea ce inseamna php este in processing instruction, toate celelalte (javascript, css si interogarile xpath) au ramas in text!
In plus toate exemplele le puteti descarca la adresa: http://www.aws-dms.com/uup/XMSAllEx.rar
Am facut si o serie de tutoriale, daca va uitati pe site le vedeti.
Multumesc!!
-
cezar.lucan
- Average Member
- Mesaje: 83
- Membru din: Joi Mar 11, 2010 2:18 pm
Salutare!!!!
Ei.... asta este exact tipul de discutie constructiva pe care o caut, multumesc!!!
1. Buna intrebare si destul de greu sa raspund!!
Php-ul cred ca a devenit un limbaj popular mai ales datorita simplitatii, dupa care framework-urile au completat oarecum neajunsurile prin adaugarea de "facilitati" necesare dezvoltatorilor pentru a creste productivitatea, a permite reutilizarea codului,....
In primele mele aplicatii am folosit Zend, deoarece era cel mai popular (si se pare ca este in top inca, alaturi de Yii, CI, s.a.). Nu pot sa spun ca am fost un mare adept al lor deoarece adauga un nivel de complexitate, de multe ori documentatia nu era de ajuns si aveam nevoie sa "sap" pentru a gasi raspunsurile.
Pe scurt, Zend mi-a rezolvat problemele dar mi-a creat altele asa ca am incercat sa imi construiesc pe cat posibil, un framework propriu ... suna cunoscut tuturor Dar nici acest framework nu a fost ok deoarece era foarte specializat pe un anume tip de aplicatii si daca faceam o schimbare atunci aveam dureri de cap in alte aplicatii... asa m-am convins ca nici aceasta varianta nu este buna deci am luat o pauza de gandire, sa vad unde gresesc.
Se pare ca, deoarece am folosit ZF am ramas oarecum ancorat in abordarea lui de la acel moment si cam tot ce am facut in framewrokul meu a fost o "replica" a ceea ce exista deja deci.... eram pe un drum gresit.
Cand am inceput sa lucrez la acest framework, am pus pe hartie cateva idei:
- Ce vreau sa fac cu el: HTML, XML si alte cateva tipuri de aplicatii (probabil 1%)
- Ce au toate aceste aplicatii in comun: XML!!! Pana si HTML este un XML mai ... specializat
- Cum vreau sa lucrez in el: "crude PHP", fara complicatii si dureri de cap, zeci de clase, care mai de care cu tone de logica pe care eu sa o stapanesc indeajuns de bine pentru a rezolva o problema
- Cum anume realizez ceea ce este mai sus: identificand cateva operatii de baza pe care sa le faca frameworkul si lasand logica aplicatiei la indemana dezvoltatorului
-Cum anume as putea sa fac sa pot lucra la aplicatiile mele de oriunde (orice calculator) fara sa am nevoie de fel si fel de programe: rezulta o interfata integrata in framework, pe care sa o accesez de la distanta si sa fac modificarile necesare
- Cum fac sa pot refolosi codul deja scris? ... raspunsul a venit mai tarziu!
... cateva altele!
Din ideile de mai sus, cea cu XML fiind comun la 99% din aplicatii, mi-a ramas in cap si facea diferenta. Toate framework-urile pe care le stiam construiau aplicatiile, ca sa zic asa, in mod text (php = preprocesor hypertext) deoarece despre asta vorbea php la acel moment.
Odata cu php 5, extensia DOM era destul de puternica si stabila pentru a putea sa dezvolt ceea ce aveam in cap, adica un framework pe php.
Avantajul este ca in XML ai access la orice nod din aplicatie fara probleme, deci logica aplicatiei poate fi separata de codul brut de generare si interpretare a datelor spre deosebire de abordarile de tip text unde nu puteai interveni in "rezultat".
In tot ce am spus mai sus se vad avantajele pe care cred ca le ofera acest framework, de fapt abordarea pe care o are.
2. Experienta mea reala este limitata si se rezuma la 99% aplicatii web pentru diferite domenii si doar cateva site-uri!
De ani buni traiesc din meseria mea, care este complet alta decat programator. Ceea ce fac este sa imi dedic parte din timpul liber acestui prim hobby al meu.
Acesta este si motivul pentru care apelez la voi, programatorii cu experienta care traiesc din programare si care pot sa ma indrume, sa imi dea niste feedback-uri pertinente.
Inapoi la intrebare: m-am gandit la aceasta problema cand am conceput "motorul" framework-ului si stiu ca acele cookie pe care le foloseste google pentru page tracking trebuie "mangaiate" frumos deoarece poti pierde page rank-ul. Este vorba, daca bine imi amintesc, de vestitele __utm*, asa este?
Din cate am citit pe net la acel moment, toate acestea sunt regenerate daca nu mai sunt gasite, si parca utma era un id unic,....
Cred ca lucrurile ar fi astfel: daca schimbi limba, googlebot va incepe sa indexeze continutul paginii in diferite limbi.... rezulta varza.... asta ar fi problema? Chiar va rog, l33t si MihaiC sa dezvoltati subiectul!!
Deoarece schimbarea limbii se face in aceeasi sesiune rezolvarea cred ca ar fi regenerarea id-ului cand se face schimbarea variabilei de sesiune care spune ce limba se foloseste. Este regenerarea id-ului sesiunii o rezolvare? Daca da, se poate face cu directiva init, in orice aplicatie la momentul detectarii unei alte limbi...
As aprecia foarte mult contributia voastra cu explicatiile aferente, daca e nevoie fac modificarile necesare!
Cat despre cache, da se poate face la tot ceea ce inseamna import (local, remote / xml sau html) nu insa si la o pagina / aplicatie completa. Motivul este ca frameworkul este foarte rapid si implementarea cache-ului pe pagina / aplicatie nu am considerat-o o prioritate, dar o am si am avut-o in vedere.
Toate filtrele sau directivele care au atribut cache, cachestorage, clearcache folosesc... cache. Un ex: http://aws-dms.com/temp.php?use=templat ... import.xml
In acest moment nu am gandit un mecanism dar daca aveti sugestii, imi spuneti care arfi dezavantajele in alte framework-uri si cum as putea sa imbunatatesc, atunci voi lucra seios la un astfel de mecanism.
Din pacate, nu am placerea si timpul necesar pentru a cauta in toate framewrk-urile care s-au impus pana acum, sa sap si sa vad aceste lucruri de aceea apreciez foarte mult contributia voastra si pentru toti care vin cu idei care se materializeaza in imbunatatiri, ii trec la "Contribuitori" pe site, cu mare placere!!!
Deasemenea, acest proiect este deschis, daca cineva crede in aceasta idee si vrea sa contribuie (cod, idei, to ce poate fiecare) cu mare placere sunt deschis la colaborare!!!
Ei.... asta este exact tipul de discutie constructiva pe care o caut, multumesc!!!
1. Buna intrebare si destul de greu sa raspund!!
Php-ul cred ca a devenit un limbaj popular mai ales datorita simplitatii, dupa care framework-urile au completat oarecum neajunsurile prin adaugarea de "facilitati" necesare dezvoltatorilor pentru a creste productivitatea, a permite reutilizarea codului,....
In primele mele aplicatii am folosit Zend, deoarece era cel mai popular (si se pare ca este in top inca, alaturi de Yii, CI, s.a.). Nu pot sa spun ca am fost un mare adept al lor deoarece adauga un nivel de complexitate, de multe ori documentatia nu era de ajuns si aveam nevoie sa "sap" pentru a gasi raspunsurile.
Pe scurt, Zend mi-a rezolvat problemele dar mi-a creat altele asa ca am incercat sa imi construiesc pe cat posibil, un framework propriu ... suna cunoscut tuturor
Dar nici acest framework nu a fost ok deoarece era foarte specializat pe un anume tip de aplicatii si daca faceam o schimbare atunci aveam dureri de cap in alte aplicatii... asa m-am convins ca nici aceasta varianta nu este buna deci am luat o pauza de gandire, sa vad unde gresesc.
Se pare ca, deoarece am folosit ZF am ramas oarecum ancorat in abordarea lui de la acel moment si cam tot ce am facut in framewrokul meu a fost o "replica" a ceea ce exista deja deci.... eram pe un drum gresit.
Cand am inceput sa lucrez la acest framework, am pus pe hartie cateva idei:
- Ce vreau sa fac cu el: HTML, XML si alte cateva tipuri de aplicatii (probabil 1%)
- Ce au toate aceste aplicatii in comun: XML!!! Pana si HTML este un XML mai ... specializat
- Cum vreau sa lucrez in el: "crude PHP", fara complicatii si dureri de cap, zeci de clase, care mai de care cu tone de logica pe care eu sa o stapanesc indeajuns de bine pentru a rezolva o problema
- Cum anume realizez ceea ce este mai sus: identificand cateva operatii de baza pe care sa le faca frameworkul si lasand logica aplicatiei la indemana dezvoltatorului
-Cum anume as putea sa fac sa pot lucra la aplicatiile mele de oriunde (orice calculator) fara sa am nevoie de fel si fel de programe: rezulta o interfata integrata in framework, pe care sa o accesez de la distanta si sa fac modificarile necesare
- Cum fac sa pot refolosi codul deja scris? ... raspunsul a venit mai tarziu!
... cateva altele!
Din ideile de mai sus, cea cu XML fiind comun la 99% din aplicatii, mi-a ramas in cap si facea diferenta. Toate framework-urile pe care le stiam construiau aplicatiile, ca sa zic asa, in mod text (php = preprocesor hypertext) deoarece despre asta vorbea php la acel moment.
Odata cu php 5, extensia DOM era destul de puternica si stabila pentru a putea sa dezvolt ceea ce aveam in cap, adica un framework pe php.
Avantajul este ca in XML ai access la orice nod din aplicatie fara probleme, deci logica aplicatiei poate fi separata de codul brut de generare si interpretare a datelor spre deosebire de abordarile de tip text unde nu puteai interveni in "rezultat".
In tot ce am spus mai sus se vad avantajele pe care cred ca le ofera acest framework, de fapt abordarea pe care o are.
2. Experienta mea reala este limitata si se rezuma la 99% aplicatii web pentru diferite domenii si doar cateva site-uri!
De ani buni traiesc din meseria mea, care este complet alta decat programator. Ceea ce fac este sa imi dedic parte din timpul liber acestui prim hobby al meu.
Acesta este si motivul pentru care apelez la voi, programatorii cu experienta care traiesc din programare si care pot sa ma indrume, sa imi dea niste feedback-uri pertinente.
Inapoi la intrebare: m-am gandit la aceasta problema cand am conceput "motorul" framework-ului si stiu ca acele cookie pe care le foloseste google pentru page tracking trebuie "mangaiate" frumos deoarece poti pierde page rank-ul. Este vorba, daca bine imi amintesc, de vestitele __utm*, asa este?
Din cate am citit pe net la acel moment, toate acestea sunt regenerate daca nu mai sunt gasite, si parca utma era un id unic,....
Cred ca lucrurile ar fi astfel: daca schimbi limba, googlebot va incepe sa indexeze continutul paginii in diferite limbi.... rezulta varza.... asta ar fi problema? Chiar va rog, l33t si MihaiC sa dezvoltati subiectul!!
Deoarece schimbarea limbii se face in aceeasi sesiune rezolvarea cred ca ar fi regenerarea id-ului cand se face schimbarea variabilei de sesiune care spune ce limba se foloseste. Este regenerarea id-ului sesiunii o rezolvare? Daca da, se poate face cu directiva init, in orice aplicatie la momentul detectarii unei alte limbi...
As aprecia foarte mult contributia voastra cu explicatiile aferente, daca e nevoie fac modificarile necesare!
Cat despre cache, da se poate face la tot ceea ce inseamna import (local, remote / xml sau html) nu insa si la o pagina / aplicatie completa. Motivul este ca frameworkul este foarte rapid si implementarea cache-ului pe pagina / aplicatie nu am considerat-o o prioritate, dar o am si am avut-o in vedere.
Toate filtrele sau directivele care au atribut cache, cachestorage, clearcache folosesc... cache. Un ex: http://aws-dms.com/temp.php?use=templat ... import.xml
In acest moment nu am gandit un mecanism dar daca aveti sugestii, imi spuneti care arfi dezavantajele in alte framework-uri si cum as putea sa imbunatatesc, atunci voi lucra seios la un astfel de mecanism.
Din pacate, nu am placerea si timpul necesar pentru a cauta in toate framewrk-urile care s-au impus pana acum, sa sap si sa vad aceste lucruri de aceea apreciez foarte mult contributia voastra si pentru toti care vin cu idei care se materializeaza in imbunatatiri, ii trec la "Contribuitori" pe site, cu mare placere!!!
Deasemenea, acest proiect este deschis, daca cineva crede in aceasta idee si vrea sa contribuie (cod, idei, to ce poate fiecare) cu mare placere sunt deschis la colaborare!!!
-
cezar.lucan
- Average Member
- Mesaje: 83
- Membru din: Joi Mar 11, 2010 2:18 pm
Am petrecut putin timp la o bere si o partida de documentare pe net vis'a vis de problemele cu sesiunile ridicate de MihaiC si l33t.
Am verificat si site-urile pe care le-am facut pana acum cu XMS si conform a ceea ce am gasit pe net si a ceea ce imi arata google webmaster tools (care imi indica numarul exact de pagini, cu un verde mare si ok la toate, fara erori si duplicate) nu este nici o problema!!!
Se pare ca problema apare cand id-ul sesiunii este introdus in URL, deoarece apar pagini duplicat pe URL-uri diferite.
Sesiunile nu afecteaza nicidecum un crawler, deoarece acesta nu tine niciodata cont de cookie-uri si sesiuni totusi (ma repet aici) singura problema este daca id-ul sesiunii apare in URL!!
Se pare ca folosirea id-ului in URL nu mai e la moda, sincer nu am mai vazut de mult. In cazul in care din nu stiu ce motive trebuie sa folositi id-ul sesiunii in url, atunci in acea pagina trebuie pus "<meta ="robots" content="noindex">"!!
Surse:
http://www.seomoz.org/blog/controlling- ... ession-ids
http://www.searchengineguide.com/stoney ... s-dont.php
Deci, sesiunile de lucru nu sunt o problema, nu in modul in care sunt folosite de XMS!
As aprecia daca veniti cu completari la acest subiect!!
Am verificat si site-urile pe care le-am facut pana acum cu XMS si conform a ceea ce am gasit pe net si a ceea ce imi arata google webmaster tools (care imi indica numarul exact de pagini, cu un verde mare si ok la toate, fara erori si duplicate) nu este nici o problema!!!
Se pare ca problema apare cand id-ul sesiunii este introdus in URL, deoarece apar pagini duplicat pe URL-uri diferite.
Sesiunile nu afecteaza nicidecum un crawler, deoarece acesta nu tine niciodata cont de cookie-uri si sesiuni totusi (ma repet aici) singura problema este daca id-ul sesiunii apare in URL!!
Se pare ca folosirea id-ului in URL nu mai e la moda, sincer nu am mai vazut de mult. In cazul in care din nu stiu ce motive trebuie sa folositi id-ul sesiunii in url, atunci in acea pagina trebuie pus "<meta ="robots" content="noindex">"!!
Surse:
http://www.seomoz.org/blog/controlling- ... ession-ids
http://www.searchengineguide.com/stoney ... s-dont.php
Deci, sesiunile de lucru nu sunt o problema, nu in modul in care sunt folosite de XMS!
As aprecia daca veniti cu completari la acest subiect!!
-
cezar.lucan
- Average Member
- Mesaje: 83
- Membru din: Joi Mar 11, 2010 2:18 pm
Vreau sa insist asupra unei probleme ridicate de MihaiC, in post-ul sau. Mai exact vreau sa clarific acea remarca legata de "nu este MVC".
MVC este o paradigma care s-a impus ca model sau standard de conceptie a tuturor framewrok-urilor moderne si este un "must have" pentru orice framework in mod text (scuze, dar chiar nu stiu cum sa le spun - ma refer la zf, yii, ci, ...).
Necesitatea folosirii standardului MVC intr-un framework in mod text apare deoarece este singura abordare care permite dezvoltatorului sa proiecteze aplicatia de asa maniera incat sa poata fi usor extensibila (??) sau sa o adapteze. Ca sa fac o paralela este oarecum acelasi lucru cu diferenta dintre programarea structurata (Pascal, C, ...) si cea nestructurata (Basic).
In abordarea clasica (frameworks in mod text) este imposibila accesarea unui element din view daca dezvoltatorul nu a prevazut aceasta necesitate.
Aici este marea diferenta, in XMS este posibila accesarea oricarui element din view, de oriunde din aplicatie deoarece folosesc DOM XML care identifica orice element prin xpath.
.
Rezulta o flexibilitate mult superioara altor framework-uri din multe privinte. Spre exemplu filtrul "domiterator" este un membru al ceea ce MVC spune ca face parte din model si permite adaptarea view in functie de context.
Avantajul pe care vreau sa il subliniez este: MVC nu este necesar in XMS deoarece structura framework-ului ofera flexibilitatea necesara pentru a nu pierde timpul cu notiuni, structuri si teorii de acest gen!!!!
MVC este o paradigma care s-a impus ca model sau standard de conceptie a tuturor framewrok-urilor moderne si este un "must have" pentru orice framework in mod text (scuze, dar chiar nu stiu cum sa le spun - ma refer la zf, yii, ci, ...).
Necesitatea folosirii standardului MVC intr-un framework in mod text apare deoarece este singura abordare care permite dezvoltatorului sa proiecteze aplicatia de asa maniera incat sa poata fi usor extensibila (??) sau sa o adapteze. Ca sa fac o paralela este oarecum acelasi lucru cu diferenta dintre programarea structurata (Pascal, C, ...) si cea nestructurata (Basic).
In abordarea clasica (frameworks in mod text) este imposibila accesarea unui element din view daca dezvoltatorul nu a prevazut aceasta necesitate.
Aici este marea diferenta, in XMS este posibila accesarea oricarui element din view, de oriunde din aplicatie deoarece folosesc DOM XML care identifica orice element prin xpath.
.
Rezulta o flexibilitate mult superioara altor framework-uri din multe privinte. Spre exemplu filtrul "domiterator" este un membru al ceea ce MVC spune ca face parte din model si permite adaptarea view in functie de context.
Avantajul pe care vreau sa il subliniez este: MVC nu este necesar in XMS deoarece structura framework-ului ofera flexibilitatea necesara pentru a nu pierde timpul cu notiuni, structuri si teorii de acest gen!!!!
Ultima oară modificat Sâm Oct 06, 2012 8:11 am de către cezar.lucan, modificat 1 dată în total.
Cine este conectat
Utilizatori ce ce navighează pe acest forum: Niciun utilizator înregistrat și 6 vizitatori