-
PHP
(
http://www.devprotalk.com/forumdisplay.php?f=9)
| _korso_ |
20. 03. 2013. 13:47 |
^ Generalno uvek su tu sf2 i zf2 koji su se odrzali zadnjih n godina za one koji zele pouzdan fw.
|
| mangia |
20. 03. 2013. 16:14 |
To da samo za neke manje projekte...
|
| Djuki |
20. 03. 2013. 16:37 |
Fuel sprema verziju 2
https://github.com/fuelphp/fuelphp
Nije napusten samo oslabljen sastavom, ali nastavlja dalje, sa composerom i sa modernim primesama.
U verziji 2 nema statickih poziva.
Sto se tice stabilnosti Fuel je dosta stabilan jer se ne ponasa kao Kohana koja sa novim verzijama razbija srari kod. To je uradio i Laravel sa verzijom 4 (Moguc prelayak sa 3 ali uy dosta promena i truda). |
| misk0 |
20. 03. 2013. 22:13 |
Citat:
Originalno napisao webarto
(Napišite 110095)
|
Nisam procitao cijeli clanak, jer sam odustao kod njegovog objasnjavanja zasto je Singleton losh... Naivno je pokusavati rijesiti jedan problem sa Singletonom (ili bilo kojom drugom metodom) i ako ne uspijes - jer taj metod nije za to predvidjen proglasiti taj metod loshim...
Nema potrebe da objasnjavam, ko hoce moze procitati komentare pametnih i ljudima kojima se dalo da objasne guru-u zasto se sta koristi. |
| webarto |
20. 03. 2013. 23:13 |
|
| misk0 |
20. 03. 2013. 23:33 |
Ne kontam kakve veze ima Dependency Injection sa ovim? Odgovorim na sva pitanja i dodjem u tacku 'Procitaj sta je Depency Injection'...
ali najbolji je prvi post na onoj tamo temi 'Every programmer is a programming guru.'...
|
| webarto |
21. 03. 2013. 00:12 |
|
| spezia |
21. 03. 2013. 09:08 |
Citat:
Originalno napisao pkrstic
(Napišite 110099)
da li je obicna funkcija ili staticna metoda u nekoj klasi je isto sa tvoje tacke gledista, razlika je u tome da u CI moras da napises ono skrnavo $this->load(....), a kod fuela i ostalih koji su se potrudili da nameste autoload (CI NEMA AUTOLOAD) koriste se klase sa staticnim metodama (NekaKlasa::metoda()) koje medjusobno nisu povezane. Ono sto si nasao na netu je problem sa staticnim varijablama u nekoj klasi i kako se to odrazava na testiranje koda.
offtopic: CI menja licencu od verzije 3.0 u neku koja samo njima odgovara, FuelPHP je napuseten od onih koji su ga pravili, najnoviji buzz je Laravel ako vec ucis nesto onda kreni sa njime
|
Precizan odgovor. A sto se tice off, mislim da ti ljudi koje si pomenuo nisu bitan faktor. Oni su prvo napustili CI (a CI nastavio da zivi i posle njih), sad im ne odovara Fuel (a on se i dalje razvija), pa nasli nesto trece (pitam se do kada). Ako se njima opterecujemo onda ni jedan fw necu uciti jer ni jedan ne valja.. Nisu ni oni najpametniji na svet pa moram da ih pratim. Ovde je bitno kolika je jaka podrska, community. Dzaba je nesto novo i dobro ako nema ni jedan dodatak (plugin). Onda cu radije da ostanem na CI (koji ima podrsku za mnogo stvari + dodaci)nego da se hvalim da radim full OOP, a ovamo se ubijam od posla. Na kraju krajeva svi rade za novac i to se jedino racuna. |
| Djuki |
21. 03. 2013. 10:46 |
Citat:
Originalno napisao webarto
(Napišite 110108)
Kakve veze ima nečiji komentar? Podforum je PHP i spominješ Singleton. Možeš li navesti i jednu (opravdanu) primjenu tog patterna?
|
Namena Singletona i DI se ne poklapaju i Di ne moze zameniti Sigleton.
Necu da pricam da je Singleton los, i ja ga izbegavam ali nemoj ga porediti sa DI.
Opravdana primena je kada zelim globalni pristup objektu, i zelim da osiguran da ce samo jedna isntanca biti kreirana.
U PHP jeziku nema problema sa Singletonom, kao sto je to slucaj u konkuretnim sistemima sa više niti gde može doći do problema kada više pozivaju u isto vreme Singleton, pa se bespotrebno kreira više objekata. Za ove slučajeve postoje drugi paterni koji se u ovim slučajevima koriste.
Koji je dobar razlog da bi izbegavali Singleton ? - Globalne promenjive su loše
- Ne poštuje SRP princip
Koji je razlog izbegavanja statičkih ?
Jel imate nešto da dodate ali konkretno protiv SIngletona i statičkih ?
Webarto ovo sa DI je bilo potpuno nekonstruktivno, ako možeš navedi neki konstruktivan i valjan razlog osim ovih koje sam ja naveo. Čak se u ovoj prezentaciji koju si linkovao navodi da treba koristii Buldere i Factory za kreiranje objekata umesto SIngletona, ne DI. |
| _korso_ |
21. 03. 2013. 11:16 |
Citat:
Originalno napisao Djuki
(Napišite 110111)
Namena Singletona i DI se ne poklapaju i Di ne moze zameniti Sigleton.
Opravdana primena je kada zelim globalni pristup objektu, i zelim da osiguran da ce samo jedna isntanca biti kreirana.
|
Hteo bih samo da dodam jednu cinjenicu.
Trenutno radim na app koja ima oko 1200 klasa. Svaka klasa se nalazi u posebnom fajlu. Bice ih jos puno posto je projekat u ranoj fazi razvoja. Ni na jednom mestu nemam singleton klase, ali imam oko 50tak "single" instanci klase. Dakle samo jedna sme da se instancira tokom requesta - upravo sto radi i singleton. Sve ovo lepo radi samo zbog DI-a. I nemam potrebe za pristup globalnom objektu nigde, zato sto objekat koji ima potrebe za tako necim, dobija taj "globalni" objekat injectovan kroz DI mehanizam.
//EDIT
I nijednu rec static takodje nemamo u kodu. |
| Vreme je GMT +2. Trenutno vreme je 05:50. |
|
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.
