DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Izbor PHP Framework (http://www.devprotalk.com/showthread.php?t=3434)

Misha 27. 09. 2007. 10:02

He he, pa dootzky definitivno bi bilo pametno da zadjes dublje od frontpage-a u tematiku o kojoj raspravljas :-)))

Pogledaj handbooks al pogledaj i source code ... ja sam se recimo u strartu iznenadio koliko su mali moduli koji rade ne tako male stvari ... i koliko je dobro iskomentarisan source code ...

Vec sam odgovorio koliko je meni trebalo da naucim Drupal i zasto mislim da prilagodjavanje misljenja nije issue za mene al uopste ... vec da li je arhitektura dobra ili ne ... da se ne ponavljam ...

Ako hoces mogu da ti sibnem online i onu Drupal knjigu ... jos bolja od handbooka za upoznavanje istog sa programerske tacke gledista ...

Misha 27. 09. 2007. 10:15

Citat:

Originalno napisao nixa (Napišite 43307)
ne radi se o tome, ne radim ni sa jednim cms "framework" , nego mislim da Drupal nije rešenje koje može da reši sve probleme ( i ako može, bila bi velika budževina ... )

:1092: E pa sad ... Nista ne moze da resi SVE probleme. Ni Typo, ni Drupal, ni CakePHP, ni PHP kad smo vec kod toga ... al ni pisanje code-a od nule nije najbolje resenje za SVE probleme ovoga sveta ... meni je to nekako jasno samo po sebi ...

Al valjda je jasno i da koriscenje frameworka ima svoju svrhu, a razlike medju njima definitivno postoje ... ne poznajem te nixa al nekako mi skaces sa teme na temu bez da zavrsis i jednu nit ragovora ... Kao eto recimo zasto Typo ima bolje performanse od Drupala?!?! :1051: :)

Mislim zaista bi voleo da cujem neke konkretne argumente ako ih imas naravno ... a sad ova nova tema koju si zapoceo ... da li ima svrhu koristiti framework, nekako mi nije zanimljiva i tu se necu upustati u razgovor ... posto je meni ocigledno da ima

teknoledge 27. 09. 2007. 11:06

Citat:

Originalno napisao Misha (Napišite 43322)
"drastichno je sporiji od slichnih resenja" ?!?!

Ljudi odakle vam ovakvi zakljuci? :-) Ovo ne moze da bude dalje od istine ...

Niti broj querija koji se izvrsava moze da bude indikacija brzine site-a ... Recimo sta mislis teknoledge-u da li je isti query koji ima JOIN naspram obicnog SELECT-a? I kolika je razlika ...

Inace Drupal ima plus strava kesiranje plus throttle module koji sluzi fine tuneovanje performansi ... znaci ako imas stranu koja je maltene staticka, mozes da namestis da se i izvrsava brzinom staticke ...

Ne znam sto srchanis toliko kao da si ti napravio Drupal :)... Elem, ako pogledas case studies videces sta developeri prichaju. Drupal je extra za nekog ko trazi CMS + framework ali ima i mana zbog toga kao sto sam pomenuo.

:1064:

Misha 27. 09. 2007. 11:32

Citat:

Originalno napisao teknoledge (Napišite 43330)
Ne znam sto srchanis toliko kao da si ti napravio Drupal :)... Elem, ako pogledas case studies videces sta developeri prichaju. Drupal je extra za nekog ko trazi CMS + framework ali ima i mana zbog toga kao sto sam pomenuo.

:1064:

:-) srchanim? Pre bi bilo da se cepanim od smeha samo ne vidis :-))) Pogledacu case studdy, samo zaboravio si da das link?!?! Ja sam od onih sto vole da se prica argumentima ... sorry :-)

Stvarno ne znam sta si nacuo i zasto si u zabludi da ima "drasticno" losije performanse od drugih CMS-a/Frameworka ... ili da su performanse al ikakav problem ...

Vec sam ti objasnio da postoje caching i throttle, vidim ne zanimaju te detalji oko toga nego aj jos jednom da ponovis tvrdjnu ... jel mislis da ce postati istina ako vise puta ponovis sta li :-)

Rails ima zaista uocljivo losije performanse od konkurencije al to ne sprecava ljude da ga koriste posto je al toliko bolji u mnogo cemu drugom, jer kada dodjes do toga da imas 100000 poseta dnevno imaces para za jos jedan server ... i za programera koji zna kako da podesi caching, throttle, opcode cache ... i tako ... kakve crne performanse ...

Ok, ovaj thread postaje dosadan polako :1056: :)

teknoledge 27. 09. 2007. 12:05

Citat:

Originalno napisao Misha (Napišite 43332)
:-) srchanim? Pre bi bilo da se cepanim od smeha samo ne vidis :-))) Pogledacu case studdy, samo zaboravio si da das link?!?! Ja sam od onih sto vole da se prica argumentima ... sorry :-)

Stvarno ne znam sta si nacuo i zasto si u zabludi da ima "drasticno" losije performanse od drugih CMS-a/Frameworka ... ili da su performanse al ikakav problem ...

Vec sam ti objasnio da postoje caching i throttle, vidim ne zanimaju te detalji oko toga nego aj jos jednom da ponovis tvrdjnu ... jel mislis da ce postati istina ako vise puta ponovis sta li :-)

Rails ima zaista uocljivo losije performanse od konkurencije al to ne sprecava ljude da ga koriste posto je al toliko bolji u mnogo cemu drugom, jer kada dodjes do toga da imas 100000 poseta dnevno imaces para za jos jedan server ... i za programera koji zna kako da podesi caching, throttle, opcode cache ... i tako ... kakve crne performanse ...

Ok, ovaj thread postaje dosadan polako :1056: :)

Cepanis, srchanis, sta god... Vidim da si od onih geek-ova koji "brane" odredjene applikacije po svaku cenu ko da su im deca...

Case study: http://drupal.org/node/116578
Web site: http://teamsugar.com/
Quote:

Citat:

1) Drupal has a hard time scaling with the number of modules and a lot of modules that a social network would want, e.g., the og module, are really bad performers. We get a lot of hits on the "my unread" page and it's absolutely brutal. Views also generate atrocious SQL which will pound your database into oblivion if you don't actively monitor the situation. We do not, for example, have a view for each block on the team homepage — the SQL is hand-written.

When you're creating web applications you're typically going for one of three things: speed/scalability, flexibility, or maintainability. Drupal is high on flexibility, average on maintainability, and poor on speed, in my opinion. If your priority is maintainability then I'd go for one of the RAD environments like Rails or CakePHP. If speed is your priority then I'd write your own lightweight framework, or whatever, and do it yourself.
Sad ces verovatno da kazes kako nisu optimizovali query-je, lose su napisali custom module, spori su im serveri, itd...

Ovo stvarno postaje dosadan thread jer si ga ti smorio.... :1039:

Misha 27. 09. 2007. 12:41

E ovo vec ima "neku" tezinu, za razliku od onoga sto si do sada rekao. Al vidis kako znas i sam sta sve moze da bude razlog losim performansama ... i da to nije SAMO pitanje frameworka ... kao sto rekoh to je u startu promasena poenta za ovaj thread

Secas se, covek je pitao koji frameworci se koriste u praksi i zasto ... ja sam mu dao malo konkretniji odgovor zasto ja koristim Drupal, zar nije trebalo i ti da uradis slicno, kao ono znas!?!? Vidis ja bi rado procitao tvoje argumente zasto ti koristis ono sto koristis, makar to bio i code od nule ... a ovi kvazi argumenti protiv, i jedan komentarcic ... jesu smor al zesci ...

Dakle ako koristis Drupal kao framework (bez mnogo tudjih modula), na tebi je koliko ce ti code brz biti, kao uostalom kao i kad pises aplikaciju od nule. Stim sto ovde imas nekoliko ugradjenih modula koji ti pomazu da boostujes performanse i ogroman koristan dobro istestiran API koj mozes da koristis.

A decu i karakterizacije sta je ko probaj da zaobidjes ... To mi je malo trulije nego biti geek na devprotalk forumu ...

Bojan Zivanovic 27. 09. 2007. 12:47

Istina je da je Drupal bio dosta spor, sto su Drupal developeri osetili na svojoj kozi (drupal.org se raspadao usred prevelikog broja korisnika).
Medjutim, aktivno se radi na smanjivanju broja kverija i boljem kesiranju, tako da je iz verzije u verziju situacija sve bolja.. Sestica donosi velika pobojsanja sto se performansi tice, tako da definitivno vredi pogledati.
Inace, slazem se da Drupal ima odlican framework, sam kod je prva liga.

McChoban 27. 09. 2007. 16:59

Ok, evo naterali ste me da pogledam drupal... A te knjige, jesu li validne za 6-cu?

Misha 27. 09. 2007. 17:44

Citat:

Originalno napisao Bojan Zivanovic (Napišite 43336)
Medjutim, aktivno se radi na smanjivanju broja kverija i boljem kesiranju, tako da je iz verzije u verziju situacija sve bolja..

To si u pravu Drupal se razvija stvarno impresivnom brzinom. Recimo CodeIgniter maltene razvija jedan (vrlo pametan) covek, CakePHP njih nekoliko, dok se oko Drupala vrti jedan poprilicno veliki community ocigledno kompetentnih ljudi ... i to se vidi, i u ispoliranosti source-a i dokumentaciji i sl. Cak i to mi je mnogo bitnije od nekih mutnih prica oko performansi ...

A o performansama Drupala cini mi se ima raznih misljenja zato sto ljudi koriste module preterano, da ne bi slucajno nesto rucno napisali, pa se posle pitaju zasto je to sporo. Iz mog iskustva ako ga koristis kao framework tih problema zaista nemas.

Citat:

Originalno napisao McChoban (Napišite 43347)
Ok, evo naterali ste me da pogledam drupal... A te knjige, jesu li validne za 6-cu?

Knjige su pisane za 5-icu, 6-ca nece izaci jos nekoliko meseci. Drupal community ti jos podrzava i 4.7 inace ... Tako mislim da slobodno mozes da citas ovo sto ima, nista pogresno neces procitati ... a stvarno je detaljno opisana arhitektura i principi dobrog dizajna web aplikacija ...

andrejpav 14. 11. 2007. 22:18

Ma kakav Drupal kao framework, vBulletin je prava stvar za to! ;)

Salim se, ali samo da spomenem od cega se sastoji moj framework: PEAR + Smarty. PEAR moze da se poredi sa Zend-om, samo sto duze postoji. Zend je kao kopija PEAR-a posto ima skoro iste klase (sa mozda nekim dodatcima).

Sad sam uzeo malo Symfony da ucim posto sef hoce da malo preradimo i iskoristimo askeet aplikaciju. (Askeet je slicna aplikaciji Yahoo Answers.) Koliko vidim, pisanje tog askeet-a nije nista lakse/brze/sigurnije/preglednije nego kad bi koristio PEAR. Samo je drugaciji nacin organizovanje koda... Mislim da to moze da se kaze i za ostale MVC frameworks koje sam video i koji su spomenuti na ovoj temi.

Misha 14. 11. 2007. 22:52

:)

Organizovanje code-a, ORM/Active record, convention over configuration, generatori, raznorazni pazljivo integrisani helperi (form, ajax) ... sve to cini te nove Rails-olike frameworke ... al onda naravno svaki od njih stavi naglasak na nesto drugo pa je kao jedinstven ... Symfony je prvenstveno mocan, koristi mnoge druge nezavisne PHP projekte ... al reko bih i najkomplikovaniji u PHP svetu frameworka ... Meni se nije svidela kolicina konfiguracionih file-ova koje moras da pises i na kom nivou ...

peroperje 01. 12. 2009. 01:54

.. Recimo CodeIgniter maltene razvija jedan (vrlo pametan) covek....

...kako si samo dosao do ovog zakljucka...

Misha 01. 12. 2009. 08:38

Da je pametan sam zakljucio gledajuci code/arhitekturu CI ako se to pitas :)

http://www.ohloh.net/p/4692/contributors

Izgleda da danas ima 4 ozbiljnija contributora koji rade na CI... I da intenzitet commita nije preterano velik: http://www.ohloh.net/p/4692/commits

Al s'obzirom na obim frameworka sasma dovoljno...

peroperje 01. 12. 2009. 10:52

iza CI stoji firma EllisLab,Ci je open source i oko sebe okuplja veoma veliku zajednicu(nemam sumnje da tu ima veoma pametnih ljudi)....

Tesko da bi jedan(ili tri ,cetiri) covek mogao postici sve ono sto stoji iza Codeigniter-a

...ali ok...ako ti tako kazes

Misha 01. 12. 2009. 13:42

Ma jok, mnogo impresivnije stvari su postizali pojedinci od Code Igniter-a, al nista cudno... Zapravo nije ni 4 za 2009... ako se pogleda statistika commita u 2009 samo njih dvoje su aktivno commitovali... Odnos ljudi koji koriste open source projekat i onih koji aktivno rade na njemu je uvek vrlo disproporcionalan, nemoj da te zbuni broj krajnjih korisnika...

Ti ne mozes da poverujes da CI radi dvoje ljudi, mene ne cudi posto je projekat poprilicno trivijalan, sto mu ne smanjuje vrednost naravno...

S'druge strane recimo ja ne mogu da se nacudim da je ovo napravio maltene jedan covek: http://cappuccino.org/

Lik je napravio gigantski framework i totalno novi programski jezik koji se kompaljira u JavaScript! Sa njim je napravio web verziju PowerPointa: http://280slides.com/Editor/. I plus je napravio IDE za sve to: http://280atlas.com/what.php

Pogledaj dubinu i obim koji obuhvata API:
http://cappuccino.org/learn/document...annotated.html

Znaci kako bre?!?! Kako su dodjavola njih dvojica uspeli sve ovo da iskuckaju za godinu i nesto dana!?!?

nixa 01. 12. 2009. 13:47

^ Capuccino je čudo, mene je doduše strah da baziram nešto na njemu baz iz tog razloga :)

Misha 01. 12. 2009. 13:58

@nixa Da znas!!! ja sam se zestoko lomio da li da krenemo da ga koristimo... I da nije cinjenice da bi svakom morao da objasnjavam sta je Objective-J i koliko je on u sustini bolji od cistog JS, sto mi 90% njih ne bi poverovalo, definitovno bi ga vec poceli koristiti a ovako smo se odlucili za ExtJS...

Btw, ako si zainteresovan da napisemo nesto u Cappucinu onako sa strane laganica, cisto vezbe radi ja sam za :)

aleck 17. 02. 2010. 20:35

Jedno iskustvo - nije baš Cappucino, ali je sličan koncept. Mi sad u firmi za web osnovu koristimo interni framework baziran na Script#-u, koji kompajlira C# u Javascript.

Moje lično iskustvo je da je to poprilično njesra. Pišeš u jednom jeziku a kad nešto ne radi onda debug u drugom. Ako taj drugi ne znaš, možeš da se slikaš. Pojedine konstrukcije iz C#-a izgledaju prilično drugačije u Javascriptu (sintaksa za for-in petlju mi je dušu pojela, pošto nisam znao C# kada sam kretao u priču).

Script# je dobio podršku za Webkit i Operu pre nešto jače od godinu dana. Da Nikhil to nije tada dodao, pošteno bi se pušili šta da radimo, verovatno bi pisali sami. Imali smo sreće, a to baš nije nešto na šta bi da računam pri bilo kakvom projektu.

Pristalica sam toga da se svaki deo bilo kog sistema piše u jeziku/frameworku namenski pravljenom za to. Javascript za klijent, ObjC/C#/šta već za server.

A da ne pričam što sve što već ima u nekom namenski pravljenom JS libu moraš sam da napraviš ponovo. Svaki put kada nešto vizuelno lepše treba da se uradi u ovom našem projektu, kukam za jQueryjem samo tako.

Jednostavno - kad se odlučiš na nešto ovako, osuđen si na to da sve moraš da pišeš sam. Samo pogledaš šarolikost plugina za jQuery, pa pogledaj da li tako nešto ima za Cappuccino / Script# i odgovor kojim putem ići se sam nameće (barem meni).

Da ne bude zabune - mene fascinira znanje i umeće ljudi koji su radili te stvari. Ali iskreno mislim da je bolje da su to upotrebili za nešto drugo.

jablan 17. 02. 2010. 21:14

Može jedno pitanje: koja je prednost pisanja toga u C#, pa prevođenje u JS? JavaScript je poprilično moćan jezik.

xippi 17. 02. 2010. 21:24

to je valjda fora, da ne izlazis iz jezika. rails ti recimo omogucava da pljujes js pisuci ruby. meni se ovaj koncept generalno ne dopada zato sto najcesce gubis sve prednosti jezika koji generises

jablan 17. 02. 2010. 21:33

Citat:

Originalno napisao xippi (Napišite 79850)
meni se ovaj koncept generalno ne dopada zato sto najcesce gubis sve prednosti jezika koji generises

Pa to.

Al' Rails i nekako (prvo, nisi prinuđen na to da se JS generiše tako, drugo, Rubi je konceptualno mnogo bliži jezik JS-u pa se prevođenjem ne gubi toliko), ali C#...

Doduše, GWT postoji već dugo, jel ima neko iskustva s njim?

Misha 17. 02. 2010. 21:44

@aleck U pravu si, obe zamerke su ti na mestu. Samo zaboravljas da oni tu apstrakciju nisu pisali jel im se moze nego sa razlogom :) Tj pored tih mana koje si naveo, ima i velikih prednosti pa je na tebi da vidis sta ce u tvom slucaju prevagnuti...

Cappuccino je napravljen da olaksa pisanje desktop like web aplikacija... Moj neki feeling je da ako bi ovo (http://280slides.com/Editor/) pokusao da napises u jQuery, da bi imao toliko bugova, konceptualno neadekvatnih problema za jQuery da bi ti nedostatak pravog debugera za Cappuccino posle bio mnogo manji problem.

Recimo mnogo popularniji i zreliji predstavnik toga sto Cappuccino radi je GWT. Ovi sto napravise Google Wave se kunu da bi taj zadatak bio maltene nemoguc da nije bilo GWT-a (java -> javascript)...

Btw kad se dogodi neki picvajz u JQuery komponenti takodje mozes da dobijes kripticne debug poruke koje iziskuju poprilicno truda da bi se rastumacile, posto ne zaboravi da je i JQuery apstrakcija nad JS...

Sto se tice toga da Cappuccino ima mnogo manje komponenti, to je posledica cisto toga sto su se skoro pojavili... A i brate 80% onog sto postoji za JQuery je neupotrebljivo... Meni se nebrojano puta dogodilo da je JQuery komponenta toliko lose napisana da kad je stavis u postojeci projekat sve puca u 10! Tako da ni to nije bas tako velika prednost...

Misha 17. 02. 2010. 21:51

Citat:

Originalno napisao jablan (Napišite 79849)
Može jedno pitanje: koja je prednost pisanja toga u C#, pa prevođenje u JS? JavaScript je poprilično moćan jezik.

Recimo, jel te ne nervira podrska za OO koncepte koju JS ima? Zar nije lepse raditi u jeziku koji ima pravu podrsku za OOP?

jQuery je zaista dobar za web siteove koje hoces da zacinis sa dinamicnoscu... al pisati web aplikaciju je malo drugacija prica, koriste se drugacije paradigme... nema strana nego ima prozora i dijaloga, prava modularizacija code-a postaje izuzetno bitna... itd

xippi 18. 02. 2010. 00:35

Citat:

Originalno napisao Misha (Napišite 79852)
Ovi sto napravise Google Wave se kunu da bi taj zadatak bio maltene nemoguc da nije bilo GWT-a (java -> javascript)...

svaki ciga svoga konja hvali :)

Citat:

Originalno napisao Misha (Napišite 79853)
Recimo, jel te ne nervira podrska za OO koncepte koju JS ima? Zar nije lepse raditi u jeziku koji ima pravu podrsku za OOP?

jQuery je zaista dobar za web siteove koje hoces da zacinis sa dinamicnoscu... al pisati web aplikaciju je malo drugacija prica, koriste se drugacije paradigme... nema strana nego ima prozora i dijaloga, prava modularizacija code-a postaje izuzetno bitna... itd

ja ne znam sta podrazumevas pod OO konceptima, ali u js-u je to odradjeno jako dobro. sama funkcija je prva instanca objekta, znaci ne pisu se klase nego prototip funkcije koji se kasnije nasledjuje. moguce je praviti privatne i public metode (ovo se resava scope-om). jquery kao takav je upravo objekat, koji u sebi ima metode koje vracaju izmenjen prosledjen element... u stvari je samo niz helper funkcija koje omogucavaju da se javascript pise jednostavnije. on je sam zamisljen modularno, koristi sizzle.js koji sluzi kao nezavisan selector engine (omogucava da se koriste css3 selektori i moze se dropovati u bilo koji drugi lib), a sam jquery source je podeljen na nekoliko zasebnih modula ajax.js, manipulation.js... prilikom builda se od svih ovih zasebnih fajlova/modula pravi jedan fajl koji se minificiran servira klijentu (skini sa gita jq source, videces o cemu pricam)

druga stvar... ovo sa paradigmom ne razumem ;) postoji jquery user interface biblioteka koja omogucava da se u browser (stranu/kako god da je zoves) ubace kontrole preko kojih je moguce praviti web app. takodje je svaku od tih kontrola moguce prosirivati po sopstvenim potrebama (kao i bilo koji drugi jquery objekat/metod). ocigledno je da nikada nisi pisao jq aplikaciju tako da zaista ne znas o cemu pricas :)

da se vratim na topic ;)

meni se od php fw-ova jedino svidaju codeigniter i kohana... bas zato sto su zamisljeni kao helper metode za lakse pisanje standardnih php stvari (ci kao port railsa na php, a kohana kao php5 only verzija ci-a). kohana ima jos prednost jer je i sam view objekat, sto ci-u jako fali. po mom misljenju web app treba da se sastoji iz odbro osmisljenog server side dela (u kom god jeziku) kome frontend pristupa preko jasno definisanog apija. u tom slucaju je potpuno nebitno da li je frontend html+js, flash... sve ove combo varijante (generisanje jezika) su mi smor

dejanr 18. 02. 2010. 00:42

Citat:

Originalno napisao xippi (Napišite 79857)
sve ove combo varijante (generisanje jezika) su mi smor

Vidi ovaj combo jambo ninju od jezika lunascript: http://www.asana.com/luna

Salu na stranu, malo oftopic ali jako zanimljiv projekat. Naime lunascriptom opisujes aplikaciju, i on generise server i client stranu.
A ako pogledate i ko je u kompaniji, vidi se da ce biti nesto od toga :)

xippi 18. 02. 2010. 01:07

havarija....ko god da stoji iza ovog frankenstajna od jezika :)

Citat:

return <table>
<tr><td>
messages.map(renderMessage)
</td></tr>
<tr><td>
<img src=(session.user.small_pic_url) />
<div>
<input data=session.user.name /> <b>' (your nickname)'</b>
<form onsubmit=postMessage>
<input data=session.new_comment hasFocus=true />
</form>
</div>
</td></tr>
</table>;

ovo me podseca na onaj spageti php... skrolas 2 sata kroz echo za view dok ne nadjes funkciju koja ti treba :)

degojs 18. 02. 2010. 04:00

Citat:

Originalno napisao xippi
ja ne znam sta podrazumevas pod OO konceptima, ali u js-u je to odradjeno jako dobro.

Npr. kako se radi sa interfejsima (definisanje, korišćenje)?

Misha 18. 02. 2010. 06:55

Citat:

Originalno napisao xippi (Napišite 79857)
svaki ciga svoga konja hvali :)

E znao sam da se neko nece dati prevariti i da ce ovako reagovati :1064: Pa nisu valjda ovi iz Googlea takve cige da hvale i kad razloga nema? :) Ono sto oni hvale je prednost koriscenja Jave nad JS u tako velikim projektima, a to ne da stoji... Kako god da okrenes jel znas ti za neku aplikaciju kompleksnu kao Google Wave koja je napisana u cistom JS? Sta mislis zasto ih nema?

Citat:

Originalno napisao xippi (Napišite 79857)
ja ne znam sta podrazumevas pod OO konceptima, ali u js-u je to odradjeno jako dobro

Legendarna recenica :) Ne znam sta je Kartagina al uostalom smatram da to treba razrusiti :) ma gde dobro odradjeni! Koji jos ljudski jezik koristi prototype based pravljenje klasa? i dao si upravo primer jedne od rogobatnosti, nacin kako se prave public/private/privileged clanovi... cista havarija ;)

Citat:

Originalno napisao xippi (Napišite 79857)
ovo sa paradigmom ne razumem ;) postoji jquery user interface biblioteka...

Pored komponent based paradigme ima tu jos svasta

Pogodio si, nisam koristio jQuery za pisanje aplikacija, vrlo svesna odluka, jesam za ubacivanje zanimljivih kotrola u postojece siteove... Al za full web aplikacije sam odabrao ExtJS... Posto nije dovoljno da nesto postoji, mora i da lici na nesto.

Uporedi broj/ozbiljnost ExtJS komponenti / klasa i JQuery UI komponenti. Pogledaj recimo Tab kontrolu, jQuery UI za nju ima 7 eventa, Ext ima 40-tak... jQuery UI nema mikroskopski delic mogucnosti ExtJS-a u globalu...

Citat:

Originalno napisao xippi (Napišite 79857)
web app treba da se sastoji iz odbro osmisljenog server side dela (u kom god jeziku) kome frontend pristupa preko jasno definisanog apija

U potpunosti se slazem, fenomenalna recenica! Kakva je podrska za data-binding sa serverom u jQuery-ju? Ext ima direct tehnologiju za to, ili mozes svaku komponentu da vezes za REST url, jednom linijom codea... Ne, ne, cisti AJAX nije nacin ako si to hteo da kazes :) Cisti AJAX na velikom projektu posle 10-te data binded komponente postaje cisto mucenje...

A sta cemo za ozbiljnije programerske teme, kao memory management? Kako to resavas u cistom JS/jQuery? Da pogadjam, ne resavas?!?! :1074: Samo nacin kako barata sa komponentama sto se tice memorije bi bio dodovljan razlog da se odlucim za Ext umesto jQuery-ja... Onda management stanja aplikacije, history, pa layout management... Kako sve to radi jQuery UI? Reko bih da ne radi nikako :p

Ako se ne varam u jQuery UI moras da pises HTML kad hoces da ubacis komponentu? Ako je to jedini nacin (nisam siguran), samo to je za mene deal breaker. U Ext-u ako neces ne moras al uopste da se spustas na DOM/HTML/CSS nivo... al zesci productivity booster...

Cuj ti njega nikad nisam pisao JS aplikaciju! Pa sta radim poslednjih 6 meseci nego to sto radim :1042:

ivanhoe 18. 02. 2010. 10:37

Citat:

Originalno napisao Misha (Napišite 79853)
Recimo, jel te ne nervira podrska za OO koncepte koju JS ima? Zar nije lepse raditi u jeziku koji ima pravu podrsku za OOP?

s druge strane, jel te ne nervira kad nemas poptunu kontrolu nad kodom koji pravis, nego nesto tamo automatski generise kod, i onda dobijes 50 linija umesto 3, i za neku prostu stvar moras da izvodis vratolomije, jer se programer nije setio da ce ti mozda to trebati? Uvek se setim onih alata za generisanje SQL-a, koji su bili jako popularni pre 10-tak godina i nemogucih, kilometarskih upita koji su se tako dobijali.

Tako da, svako za ima svoje protiv, stvar je u tome sta radis i sta ti je prioritet

bluesman 18. 02. 2010. 10:37

Mister, jel' ti to hoćeš da kažeš da je jQuery sranje? I da ti je potreban neki super-cool memory management u javascriptu? Šta praviš, gmail? Ili sam ja nešto propustio?

Često vidim ljude koji pričaju bolje je ovo, ono, ima još i ovo-ono a na kraju kada pogledaš kod svodi se na show / hide / toggle div :) Ne kažem da je ovo slučaj, nego čisto kao primer ljudi koji olako pljuju po nečemu što ne nikada nisu ni koristili. To je kao kada bih ja pričao da je Lamborghini sranje u odnosu na Ferarri, jer nema ovo-ono a u stvari meni je dovoljan i Fiat Punto za prevoz od tačke A do tačke B.

Misha 18. 02. 2010. 11:15

Citat:

Originalno napisao ivanhoe (Napišite 79868)
s druge strane, jel te ne nervira kad nemas poptunu kontrolu nad kodom koji pravis, nego nesto tamo automatski generise kod,...

Tako da, svako za ima svoje protiv, stvar je u tome sta radis i sta ti je prioritet

To se slazem sa problemom generisanog code-a... samo kad govorimo o Cappuccinu il GWT tu se misli na full framework-e a ne na generatore code-a, ne mozes bas tako da ih izjednacujes... Al totalno se slazem da zavisi sta radis, to i pricam zapravo... jQuery nije za web aplikacije desktop tipa... Zasta su Cappccino i GWT prvenstveno napravljeni...

@bluesman No Mister, necu da kazem da je jQuery sranje... a propustio si kontekst u kome pricamo o izboru frameworka... jQuery je prelep framework i recimo Drupal ga koristi na totalno pravi nacin... samo mislim da nije za web aplikacije bas si lep primer dao, GMail tipa.

Web aplikaciju (RIA aplikaciju) ne cine samo UI kontrole ko sto rece xippi nit toggle div pobogu :)

jablan 18. 02. 2010. 12:07

Citat:

Originalno napisao degojs (Napišite 79863)
Npr. kako se radi sa interfejsima (definisanje, korišćenje)?

Što bi jedan jezik sa duck-typingom uopšte imao nešto poput interfejsa?

xippi 18. 02. 2010. 12:42

Citat:

Originalno napisao degojs (Napišite 79863)
Npr. kako se radi sa interfejsima (definisanje, korišćenje)?

http://mattprokes.com/2008/11/17/ful...-are-possible/

xippi 18. 02. 2010. 13:32

Citat:

Originalno napisao Misha (Napišite 79866)
Cuj ti njega nikad nisam pisao JS aplikaciju! Pa sta radim poslednjih 6 meseci nego to sto radim :1042:

citaj pazljivo, rekao sam da nikad nisi pisao jq aplikaciju. sta si ti radio poslednjih pola godine nije moj problem :)

Citat:

Originalno napisao Misha (Napišite 79866)
Ono sto oni hvale je prednost koriscenja Jave nad JS u tako velikim projektima, a to ne da stoji... Kako god da okrenes jel znas ti za neku aplikaciju kompleksnu kao Google Wave koja je napisana u cistom JS? Sta mislis zasto ih nema?

grendmadrs and frogs. java je server side jezik, a javascript client side... to sto su oni izabrali javu + js (gwt) je njihova stvar... to je isto moglo da se napise u ruby+flash/flex ili bilo kojoj kombinaciji client i server side tehnologije

Citat:

Originalno napisao Misha (Napišite 79866)
Pogledaj recimo Tab kontrolu, jQuery UI za nju ima 7 eventa, Ext ima 40-tak...

ako ti fali neki event uvek mozes da ga bindujes.

Citat:

Originalno napisao Misha (Napišite 79866)
Ext ima direct tehnologiju za to, ili mozes svaku komponentu da vezes za REST url, jednom linijom codea...

moje misljenje o ovom se podudara sa ovih prvih par komentara

Citat:

As pablo says, yes i understand this as getting tied to Ext. Making server code to work only with one frontend(ExtJS), doesn’t look too fancy for me. If i want to make another frontend, lets say in Delphi for windows to get the same data its used in the server i would have to make other normal ajax functions to get that working in the other frontend.
But if you are going to use only ExtJS for the front end i can see that its good to use this.
generalno nemam nista protiv extjs-a, samo kazem da ne poznajes jq dovoljno da bi pricao o njemu... a bottomline je da je sve ovo i dalje samo javascript ;)

Misha 18. 02. 2010. 14:21

@xippi A jesi ti napisao ikad vecu RIA aplikaciju u jq-u? Tj jel znas za neku jq RIA aplikaciju u rangu/tipa Google Wave-a, 280slides.com etc?

Ako je ovaj iz citata koristio Ext pa zakljucio da te Ext tera da pises server code koji je vezan samo za njega, onda je taj lik zivi dokaz da i ljudi koji koriste nesto ponekad ne znaju sta pricaju :)

Bas nasuprot, aplikacija koju pisemo koristi REST na serveru (Zend Framework ga generise), sto ce reci serverski code nije vezan za Ext, zapravo to mi je bilo vrlo bitno da bude tako i jedan od razloga zasto sam odabrao Ext.

xippi 18. 02. 2010. 14:25

Citat:

Originalno napisao Misha (Napišite 79883)
@xippi A jesi ti napisao ikad vecu RIA aplikaciju u jq-u? Tj jel znas za neku jq RIA aplikaciju u rangu/tipa Google Wave-a, 280slides.com etc?

kad smo kod toga upravo pisem ria u rangu 280slides preko jq/jqui-a koji mi pruza samo osnovu na osnovu koje pisem dalju logiku. dobices beta invite za koji mesec :)

Misha 18. 02. 2010. 14:37

Citat:

Originalno napisao xippi (Napišite 79884)
kad smo kod toga upravo pisem rai aplikaciju u rangu 280slides preko jq/jqui-a koji mi pruza samo osnovu na osnovu koje pisem dalju logiku. dobices beta invite za koji mesec :)

Gimme gimme! :) Extra znaci radimo slicnu stvar sa razlicitim pristupom! Bice zanimljivo ako bi razmenili iskustva za koji mesec...

Break a leg sa projektom!!! Prove me wrong! :)

P.S. Nego jel znas za neki vec postojeci veci RIA projekat u jQuery-ju? :)

degojs 18. 02. 2010. 14:49

Citat:

Originalno napisao jablan (Napišite 79873)
Što bi jedan jezik sa duck-typingom uopšte imao nešto poput interfejsa?

Jednostavno želim da imam mogućnost da definišem ugovor, kao i da jednostavno testiram da li prosleđeni objekt ispunjava potrebne uslove iz istog (vrlo jednostavno ako imaš interfejs).

@xippi:
sve to tako nešto može kao, ali to je u stvari workaround. Kao i mnoge druge stvari u JavaScript-u. To je onda natezanje, šta da se radi, drugo nema, pa onda.. Vidiš na šta to liči tamo, taj linkovani primer, uporedi sa bilo kojim 'normalnim' jezikom.

Npr. kako obezbeđuješ da klasa ne može da se nasleđuje?

Citat:

Originalno napisao Misha
A sta cemo za ozbiljnije programerske teme, kao memory management? Kako to resavas u cistom JS/jQuery? Da pogadjam, ne resavas?!?!

Što bi rešavao upravljanje memorijom na sistemima gde se to dešava automatski?

Pošto si pomenuo Javu u pozitivnom svetlu, poznato ti je da je tamo upravljanje memorijom takođe automatsko?

Misha 18. 02. 2010. 14:58

Citat:

Originalno napisao xippi (Napišite 79884)
kad smo kod toga upravo pisem ria u rangu 280slides preko jq/jqui-a koji mi pruza samo osnovu na osnovu koje pisem dalju logiku. dobices beta invite za koji mesec :)

BTW, sad si me zainteresovao... Nasa neka osnovna organizacija se sastoji od Ext Viewport objekta (kontejner koji zauzima ceo browser prozor) u koji onda programski stavljamo druge kontejnere i komponente... znaci ceo projekat ima samo jedan maltene prazan HTML file, sve ostalo je hijerarhija objekata i event handlera vezanih za njih, nema trunke HTML-a/DOM-a. U tom smislu jel tvoja organizacija slicna sa JQ-om il ne?

Predpostavljam da za layout management i ostalo sto JQ nema koristis third party pluginove... il se trudis da ih ne koristis da sve sam pises?

Il da ovaj razgovor nastavimo uz :beer: :1045: Mene bas EXTRA u poslednje vreme zanima RIA development tako da na tu temu placam :beer::beer::beer::beer::beer:

Misha 18. 02. 2010. 15:03

Citat:

Originalno napisao degojs (Napišite 79887)
Što bi rešavao upravljanje memorijom na sistemima gde se to dešava automatski?

Automatski osim kad se to ne dogodi :) Garbage collector u Javi je nesto na sta mozes da se oslonis... nazalost to ne vazi za JS... Zato su tvorci Ext-a kao jedan od najbitnijih dodataka na jezik ubacili lazy instanciranje komponenti i napredniji garbage collection istih. IE je posebno lenj po pitanju izbacivanja djubreta...

Naglasak je naravno na VELIKIM RIA aplikacijama... taj problem se tek tada manifestuje...


Vreme je GMT +2. Trenutno vreme je 16:22.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.