Poslao: 09 Avg 2013 12:10
|
offline
- Lackeeee
- Građanin
- Pridružio: 23 Okt 2011
- Poruke: 163
|
Na zvanicnom Eliste.com blogu, citam vesti ili ti komentare vezane za CI i ne mogu da verujem da neki spominju da je vreme da se stane za unapredivanjem CI-a, za razvijanjem novih verzija... Jer kako su oni objavili iz EllisLab-a, traze nekog ko ce preuzeti dalje upravljanje nad CI-jem posto oni valjda nemaju dovoljno vremena da posvete CI-ju koliko on to zasluzuje (njihove reci)
ellislab.com/blog/entry/ellislab-seeking-new-owner-for-codeigniter
Ja se iskreno nadam da CI nece postati "dead" jer dosta stvari sam radio u njemu i iz njega naucio, i samim tim mi se svideo, lak je za ucenje i savladavanje...
Da li neko ima neki komentar u vezi CI-a i njegove buducnosti, treba li i dalje radi u njemu i tome slicno?
|
|
|
Registruj se da bi učestvovao u diskusiji. Registrovanim korisnicima se NE prikazuju reklame unutar poruka.
|
|
Poslao: 09 Avg 2013 14:01
|
offline
- Pridružio: 16 Feb 2011
- Poruke: 1630
- Gde živiš: Pancevo
|
Pa to ti je ono, napravili su ime sa CI i sada kada imaju neke bolje prilike i sanse oni prodaju svog prvog konja. Ma sta ima veze ko da ga neko trazi kad konkurises negde. Neka umre ko ga da ne kazem sta. Imas jake Zend ,Symfony framworkove koji su bas placeni i ceni se njuhovo znanje... Mislim steta on je moja prva ljubav.
|
|
|
|
Poslao: 09 Avg 2013 14:13
|
offline
- Lackeeee
- Građanin
- Pridružio: 23 Okt 2011
- Poruke: 163
|
Meni je krivo, jer sam taman poceo da ucim PHP i to OOP kako treba uz pomoc njega. Radim i sad CMS u njemu za master rad, pa sam se nekako malo smorio, jer mi je to prvi fw koji sam ucio. Pa me malo to ubilo u pojam, kao ja ga ucim, a nece se dalje primenjivati i razvijati a pocetnik sam i bas me zanima to.
Mada sam malo gledao PHPixie i Kohanu, sve je to slicno. Zend mi je savetovao asistent da radim, ali da pocnem sa malo manjim fw jer Zend se koristi za bas ogromne projekte...
|
|
|
|
Poslao: 09 Avg 2013 15:05
|
offline
- Pridružio: 16 Feb 2011
- Poruke: 1630
- Gde živiš: Pancevo
|
Citat:
Zend se koristi za bas ogromne projekte..
Nemoj da te neko laze....
Jer ti kada radis mali projekat nikada neznas da li ces imati potrebu da ga prosiris?
A i postoji lite verzija.
Dao bog izmislise i composer pa tako da u svojoj aplikaciji mozes da uzmes samo komponentu koja ti treba bez celog jezgra ako ti je zao i brines se za velicinu aplikacije.
U ostalom prosiri ga sam. Pogledaj novitete na PHP sajtu i doradis samo to sto on nema.
Mada on ce da zivi jos dosta dugo veruj mi, min 2 god. Dok god ne zastari 5.4 verzija php-a
|
|
|
|
Poslao: 09 Avg 2013 19:21
|
offline
- Pridružio: 25 Jan 2004
- Poruke: 2784
- Gde živiš: Niš
|
Moja preporuka ti je da baciš pogled na Laravel, sigurno će ti se sviđati jer je po jednostavnom pristupu sličan Code Igniteru. http://laravel.com/
Sa druge strane, za razliku od npr. Symphony-a, Laravel u potpunosti podržava Dependancy Injection paternu tako da je sve u frameworku testabilno i maksimalno modularno.
|
|
|
|
Poslao: 10 Avg 2013 10:39
|
offline
- Lackeeee
- Građanin
- Pridružio: 23 Okt 2011
- Poruke: 163
|
Malo sam googlao u vezi Laravel-a i vidim da su ga dosta nahvalili, da je slican dost CI i da predstavlja pravo osvezenje u PHP svetu fw-a. Cim odbranim sad maser rad, krenuci njega da radim, Laravel, bootstrap, smarty...
|
|
|
|
Poslao: 10 Avg 2013 13:04
|
offline
- Pridružio: 16 Feb 2011
- Poruke: 1630
- Gde živiš: Pancevo
|
Default ::Moja preporuka ti je da baciš pogled na Laravel, sigurno će ti se sviđati jer je po jednostavnom pristupu sličan Code Igniteru. http://laravel.com/
Sa druge strane, za razliku od npr. Symphony-a, Laravel u potpunosti podržava Dependancy Injection paternu tako da je sve u frameworku testabilno i maksimalno modularno.
Symfony i zend Framework jedini koji imaju do kraja razvijen DI (dependency injection). Nigde nisam video da je neko bolje od njih razvio taj pattern..
Symfrony:
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Reference;
$container = new ContainerBuilder();
$container->setParameter('mailer.transport', 'sendmail');
$container
->register('mailer', 'Mailer')
->addArgument('%mailer.transport%');
$container
->register('newsletter_manager', 'NewsletterManager')
->addArgument(new Reference('mailer'));
Zend:
protected function setupDi(Application $app)
{
$definitionList = new DefinitionList(array(
new Definition\ArrayDefinition(include __DIR__ . '/path/to/data/di/My_MovieApp-definition.php'),
new Definition\ArrayDefinition(include __DIR__ . '/path/to/data/di/My_OtherClasses-definition.php'),
$runtime = new Definition\RuntimeDefinition(),
));
$di = new Di($definitionList, null, new Configuration($this->config->di));
$di->instanceManager()->addTypePreference('Zend\Di\LocatorInterface', $di);
$app->setLocator($di);
}
|
|
|
|
Poslao: 10 Avg 2013 14:24
|
offline
- Pridružio: 25 Jan 2004
- Poruke: 2784
- Gde živiš: Niš
|
@_iKaC
Nisam mislio da nemaju dovoljno dobro razvijen IoC container - to je već podrazumevan deo same DI paterne.
Međutim ono što tvrdim i nije baš na osnovu iskustva, tako da bih možda i pogrešio oko nekih detalja, pa će mi biti lakše da samo citiram ljude sa Symphony foruma. Možda dobijem i drugačije činjenice ovde
Citat:"The truth is most classes in Symphony just can't be tested and untested code is unpredictable. There's almost no or less seperation of responsibilities. For example look at the Page class and its descendant classes. They are more or less a templating system that does all the businesslogic. There's no clear definition of dependencies and what's even worse: it hides a lot of its dependencies which leads back to "untestable".
Furthermore, Symphony embraces a lot of concpets that are akward or considered bad practice, e.g. introducing global state by leveraging the singleton pattern all over the place, the event delegation system is pretty limmited, there's opcode and configuration outsourced to the database (loaded extension, events and callbacks), the extension driver concept really should be a service provider that does only one thing: providing services with all their dependencies, and nothing more."
|
|
|
|
Poslao: 10 Avg 2013 14:56
|
offline
- Pridružio: 16 Feb 2011
- Poruke: 1630
- Gde živiš: Pancevo
|
Ma i oni me nerviraju vise pre 5-6 godina kad su izmislili Dependency Injection pattern zapostavili su ga i smatrali losim pristupom jer su ljudi povodljivi i ostali su na Hollywood Pattern koji je smarao don't call us, we'll call you. Po meni toliko retardirana realizacija i plus ako moras nesto da izmenis moras da menjas celu klasu jer don't call us, we'll call you property drzi objekat kao vrednost u kontruktoru.
Ali ajde pazi razliku: Po meni to je samo sminka zmedju ova 2 patterna
<class>
{
[property] holiwood
[function][constructor] {
[holiwood] new <class> // i to je ono sto oni kazu don't call us, we'll call you
}
}
A Dependency Injection isto. Nije sija nego vrat
class DI {
pbl $obj;
pbl fnc _const(Session $argc) {
$t->obj = $argc;
}
}
Okay i ja malo preterujem ali opet i DI na kraju dobije objekat u nekom properiu.
|
|
|
|
Poslao: 11 Avg 2013 00:18
|
offline
- Lackeeee
- Građanin
- Pridružio: 23 Okt 2011
- Poruke: 163
|
Nego, spremite se na moja pitanja, odnosno na nase zajednicko resavanje problema prilikom mog ucenja fb Laravel-a
|
|
|
|