Ok, CodeIgniter je sjajan, ali...

[codejan]

... nije toliko ubrzan koliko bih ja voleo.

Jedna od mojih zamerki, posle par meseci cackanja, je ta sto nema mogucnost 'template-a' (pri tome znam da on ima template za bufer, nego mislim na mogucnost ucitavanja modula: logo, glavna navigacija, pomocna navigacija, futer, sistem poruka, glavni sadrzaj itd. u jednu celokupnu praznu HTML stranicu, isparcanu glavnim DIV-ovima, gde bi ovi moduli bili rasporedjeni), slicno kao u Wordpress-u. Prednost ovakvog pristupa je dvostruka: Ne mora da se ceka dizajn i ceo projekat se moze reorganizuje na jednom mestu. Druga prednost je manje koda u metodama kontrolera, jer konstruktor moze da postavi podrazumevanu module za dati kontroler.

Sad ja sam ovo resio sa ucitavanjem modula u promenljive (

$this->data[$module_name] = $this->load->view($module, $this->data, TRUE);

) i setovanje pozicija modula za zadate DIVove u mom praznom rasparcanom HTML fajlu ('template-u'). Ovo ucitavanje templejta vrsim sa

$this->load->view($template, $this->data);

Druga stvar koja me nije odusevila je i nepostojanje Database_object modela. Pa sam morao da pisem dodatni model za tu stvar, ali sam misljenja da su to momci iz CodeIgnitera mogli bolje da odrade, kad su vec implementirali Active record.

Moja poenta svega ovoga gore je: Znate li neki Framework koji bi mi izasao u susret sa nabrojanim, bez ovih prepravki?

Ako neko bude hteo da koristi moj Database_object, moze da ga download-uje.

 

[kUdtiHaEX]

Kako ne mozes da radis sa templejtima?

Evo ti prost primer:

<?php
	$this->load->view("header.php");
	$this->load->view("navigation.php");	
?>
<div id="main_content_wrap" class="container_12">
<?php echo $content;?>
</div>

<?php $this->load->view("footer.php");?>

i Controller koji poziva isti:

			$mix = array_merge($lists_list_view, $lang);

			$data['content'] = $this->load->view("lists_list", $mix, true);
			
			$this->load->view("main", $data);

Drugim recima, main u mom slucaju moze da se napravi da bude pravi templejt kojem se prosledjuju parametri i to je to Vrlo prosto.

EDIT: da li bi mogao da mi objasnis poentu tvog DB objekta?

 

[codejan]

Naravno da mogu. Moj DB objekat radi sa tabelama iz baze i implementiran je preko Active Record modela radi apstrakcije SQL koda.

Ima 6 javnih funkcija: all(), find(), count(), before_save(), save() i delete().

all() funkcija pronalazi sve podatke za dati kriterijum. Korisna je sa paginacijom i gde je potrebno jednostavnije naci podskup podataka.

find() funkcija nalazi jedan podatak za dati kriterijum. Kada se poziva sa brojem, trazi ID podatka, kada se poziva sa dva stringa, trazi podatak prema prvom string i dugom stringu (slicno je sa nizom, ali tada moze da se prosledi vise uslova).

count() prebraja podatke u tabeli. Kada se koristi bez parametara, prebraja sve, a kad se koriste parametri, prebraja po parametrima.

before_save() radi predoperacije za snimanje u bazu vezane za datu tabelu (na primer hash-ovanje sifre).

save() snima u bazu. Podaci bez ID-ja ce biti INSERT-ovani u bazu, a podaci sa ID-jem ce biti UPDATE-ovani (pre izmene ce proveriti da li postoji dati podatak u bazi).

delete() brise dati podatak iz baze i takodje ce proveriti da li postoji dati podatak u bazi.

Koristi se ovako:

$this->load->model('user');

foreach($this->user->all() as $user)
{
    echo $user->name;

    if ($user->name == 'Dejan')
    {
       $user->name = 'Marko';
       $user->save(); // Izmeni ime Dejan u Marko
    }
    else
    {
       $user->delete();
    }
}

Ili

$this->load->model('user');

$username = $this->input->post('username', TRUE);

if ($user = $this->user->find('name', $username))
{
    // Uradi nesto sa $user-om
}
else
{
    echo 'Nepostojeci korisnik!';
}

Potrebno je da imena modela budu ista kao imena tabela u bazi. Database_object treba da extend-uje dati model.

@Kutija
I ti koristis TRUE u vjuveru, pa me interesuje da li to degradira perfomanse aplikacije?

 

[kUdtiHaEX]

Pa napravi dobar lib onda i okaci ga na CI forum. Koliko znam, sve sto se pokaze kao korisno develi CI-a uzimaju u obzir za sledecu verziju.
Sto se true parametra tice, naravno da ne, u principu to nema veze sa performansama aplikacije. Zna se sta su kriticne tacke kod svake web aplikacije a ovo ne spada u jednu od njih.

 

[codejan]

Da budem iskren, nemam puno iskustva u benchmarking-u. Koliki odnos ucitavanja osnovnih klasa i kontrolera u CI je optimalan? Koliki odnos bi nazvao prekoracenjem optimuma?

Prakticno, u citanju (bez izmena u bazi podataka), da li je odnos 1:4 OK? Ili moze li da ide i na visi?

 

[AlexxandarYo]

Template library, lako se koristi i ima baš ono što ti treba
http://getsparks.org/packages/template/versions/HEAD/show

Uopšte proveri Sparks možda nađeš još par stvar koje bi mogle da ti koriste.

 

[ays]

Uvek postoji i alternativa Codeigniter-u: http://www.phpframeworks.com/news/p/24081/2011-top-10-php-frameworks-statistics-by-phpframeworks-com

Ja licno preferiram CI u odnosu na Yii ili Symphony jer me previse podsecaju na RoR. Odnosno, nacin na koji se sve radi je identican RoR-u.
cakePHP nije los, mada ima neke svoje mane, uglavnom vezane za active records DB. Tako je barem bilo u ranijim verzijama(nisam testirao isti, sigurno godinu dana). Zend je vec posebna prica...

Eh da, sada sam se setio, baci pogled na: http://kohanaframework.org/, to je framework koji je nastao iz CI.

 

[codejan]

Hvala na odgovorima. Pre Codeignitera sam pravio svoj framework u OOP (koristeci iskustva iz raznih literatura i iskustva iz Wordpress-a), pa sam vec skoro podesio CI da radi kao njegov parnjak u JavaScriptu, jQuery. Imam metode za automatsko generisanje forme iz konfiguracionog fajla validacije forme. Za dati podniz, automatski jednom linijom generisem celu formu sa required, invalid klasama, repopulacijom i validacionim greskama.

U pripadajucim metodama CRUD-a, imam metodu koju sam definisao u MY_Controller kontroleru koja mi automatski, koristeci onaj gornji DB objekat i niz iz konfiguracionog fajla validacije forme, procesira formu.

Vise mi se svidja moj nacin pravljenja 'template-a' iz razloga sto koristim konstruktor kontrolera za podesavanje podrazumevanih modula na strani (pored toga sto u konstruktoru MY_Controller kontrolera imam osnovne module i glavni template ucitan). Takodje, ako neka metoda zahteva specificne module, lako je da ih izmenim pre ucitavanja templejta, jer su moduli niz u $this-modules proprtiju kontrolera i lako mu je (nizu) pristupiti i iz metoda krajnjeg kontrolera.
A po pitanju modula, koristim module: form.php, ul.php, logo.php itd, koji su mi u glavnom folderu opstih modula, tako da nema potrebe da pravim slozenu fajl strukturu za masivan sajt, vec ih ucitavam po vrednosti clana niza setovanih modula.

Stvar, koju sam resio jos da doradim je i jos jedan konfiguracioni fajl, gde cu staviti niz sa konfiguracijm relacionih odnosa u bazi. U ovom nizu bi bila, po mojoj sadasnjoj proceni, samo imena tabela. Sa ovim nizom sam hteo da napisem funkciju (metodu) koja bi automatski radila CRUD u samo jednom kontroleru za ceo sat. Na primer, tabela category i tabela sub_category su vezane preko category_id-ja, pa bih relaciju ostvario tako sto bih trimova poslednja tri karaktera i nasao kljuc za relaciju izmedju tabela.

Koristeci onaj moj DB objekat, automatsko generisanje forme, automatsko procesiranje forme, automatski CRUD, ceo ADMIN bi se sveo na popunjavanje dva konfiguraciona fajla: validaciong i relacionog. Naravno, imalo bi jos malo posla, ali, morate priznati, ostaje samo igranje sa front-endom, kad se dosteluje ADMIN.

Imam jos nekih ideja oko automatizacije, ali sam u globalu, dobar deo svega apstraktovao.

 

[ays]

Ok... koliko sam te skapirao(posto modul ne postoji u CI, osim ako ne koristis HMVC plugin za isti, u suprotnom to su helper i library classes), napisao si, defakto, CMS koristeci CI kao osnovu i vodeci se automatizmom kao primarno?

To je odlicna ideja.

Inace, postoji nekoliko CMS sistema koji su napravljeni na osnovu CI. Baci pogled na ova dva: http://www.pyrocms.com/ i http://www.getfuelcms.com/
Ja sam isprobao Pyro pre par meseci i nije bio los.

Pozdrav

dopuna: http://www.codeigniterdirectory.com/home/Full-applications,-CodeIgniter-CMS/

 

[codejan]

Evo primera jedne metode (bez apstrakcije ADMIN-a). U pitanju je izmena podkategorije, koja ima i dropdown meni sa kategorijama:

public function update_sub_cat($id = 0)
    {
        // Priprema
        $this->main_module = 'admin/categories/sub_category/edit';
        $this->load->model('sub_category');
        $this->load->model('category');
        
        // Lociranje ID-ija
        if ( ! $this->sub_category->find($id)) redirect('admin/categories');
        
        // Promenljive za vjuver
        foreach($this->category->all() as $category)
            $this->data['category_id_SET'][$category->id] = $category->name;
        unset($this->category);
        unset($category);
        $this->data['sub_category'] = $this->sub_category;
        
        // Obrada forme
        if ($this->_proces_form('sub_category')) redirect('admin/categories');
        else $this->_load_template();
    }

Ova metoda ce admin/categories/sub_category/edit.php staviti u templejet sa ostalim podrazumevanim modulima. Potom ce proveriti da li postoji data podkategorija, pripremiti promenljive za vjuver. Ako procesiranje forme prodje uspesno, redirektovace na maticnu stranicu, a u suprotnom ce ucitati templejt sa automatski generisanom formom i svojim validacionim greskama. Procesiranje forme ce takodje samo snimiti sve u bazu ako je validacija uspesna.

_proces_form() i _load_template() su univerzalne metode iz MY_Controller kontrolera.

Ne bih ja ovo nazvao CMS-om, mada i ima opciju da bude. Samo sam uradio da ima cistiji i apstraktovaniji kod.

Mozes li mi reci, koliki je optimalnan odnos ucitavanja osnovnih klasa i kontrolera?

 

[codejan]

Ne koristim HMVC plugin, vec koristim TRUE varijantu za $this->load->view($module, $this->data, TRUE) metode i rezultat smestam u $this->data niz, koji finalno prosledjujem u $this->load->view($template, $this->data) u _load_template() metodi. Imam cist HTML fajl sa promenljivima u templejetu.

 

[ays]

Aha, sada sam skapirao sta si uradio. Ja ne radim tako, trenutno radim na svom projektu(pa samim tim, ja sam taj koji odredjuje tempo napretka, kako html/css, tako i php funkcionalnosti) a i pre, u prethodne 2 firme, gde sam radio, najcesce smo pozivali view, sa default opcijom i prosledjivali niz sa relevantnim podacima za taj view. Dakle, direktno u browser. Kad smo vec na tu temu, ako se ja dobro secam(verujem da Kutija to zna i bolje od mene), kada se prosledjuje sa 'true' kao trecim parametrom, to je bolje, za pre-processing, inace, ako je za data display, onda je taj treci parametar nepotreban.

Ja u poslednje vreme, forsiram ajax pozive sa obilatim koriscenjem json-a, vidim da je to "popularno", a i na osnovu feedback-a, od nekoliko ljudi, koji mi pomazu oko testiranja, takav UI(sa minimalnim page refresh) im je daleko prijatniji za koriscenje... "u sluzbi korisnika" - to mi je novi moto! :d

Moram da priznam da nisam razumeo ovo pitanje u vezi klasa. Pa i Controller je osnovna klasa, koju ti nasledjujes prilikom kreiranja nekog svog. Isto vazi i za Model. Ako ti nije problem, pojasni mi pitanje.


dopuna:
Ja to ovako radim:

function index()
{
    $data['content'] = 'moj_view';
    $data['title'] = 'moj_naslov';
    $data['value_from_db'] = $this->home_model->get_all();
    
    $this->load->view('layout', $data);
}

layout.php

<?php $this->load->view('includes/header');?> 

<?php $this->load->view($content);?> 

<?php $this->load->view('includes/footer');?>

moj_view.php (npr)

<?php print_r($value_from_db); ?>

 

[codejan]

Znas sta nije prakticno sa default prikazom?

• Ako radis sa dizajnerom i cekas dizajn,
• Ako imas razlicit broj CSS fajlova (JS fajlova), za razlicite strane
• Vise koda u metodama (a pisanje koda je vreme, a vreme je money)
• Ne mozes dobiti citljiviji i cistiji kod u metodama
• Ako razlicite strane imaju razlicite strukture HTML-a...

Sve ovo sam resio sa 'template' sematikom. Prazan HTML fajl, isparcan glavnim DIV-ovima, setovan u glavnom kontroleru.
Svaki od tih DIV-ova upunjavam generisanim HTML kodom iz modula ($this->load->view($module, $this->data, TRUE)).

Ne moram da brinem da li cu, ako budem nekad hteo da menjam strukturu HTML-a, slomiti pocetni i zavrsni DIV tag ili nesto drugo.
Jer, na primer, header.php i footer.php su hard-coded delovi generisanog HTML-a za prikaz u brauzeru. Morao bih, na nekom slozenijem sajtu da imam milion headera i footera. A ako bi klijent jednog dana hteo da promeni dizajn, i eventualno, sa njim i HTML, mogao bih da placem. Nadam se da me razumes. Ovako je sve centralizovano, minimalizovano i efikasno.
I najvaznije, portabilno je za druge projekte!

Sto se tice AJAX-a, razmisljao sam o specijalnom kontroleru, koji bi vracao postojeci modul po zahtevu. Jos manje fajlova i jos efikasniji kod.

A pitao sam te za Benchmark u Development modu Codeignitera. Kao ovo:

 BENCHMARKS  
Loading Time: Base Classes  	0.0374
Controller Execution Time ( Categories / Index )  	0.1018
Total Execution Time  	0.1393

 

[kUdtiHaEX]

Da budem iskren, nemam puno iskustva u benchmarking-u. Koliki odnos ucitavanja osnovnih klasa i kontrolera u CI je optimalan? Koliki odnos bi nazvao prekoracenjem optimuma?

Prakticno, u citanju (bez izmena u bazi podataka), da li je odnos 1:4 OK? Ili moze li da ide i na visi?

Obrati vise paznje na kesiranje podataka iz baze, kesiranje objekata i njihovo hendlovanje, serviraj staticki sadrzaj umesto dinamickog, koristi asinhronu komunikaciju sto vise, koristi queue menadzere... manje-vise to su stvari bitne za performanse

Ne koristim HMVC plugin, vec koristim TRUE varijantu za $this->load->view($module, $this->data, TRUE) metode i rezultat smestam u $this->data niz, koji finalno prosledjujem u $this->load->view($template, $this->data) u _load_template() metodi. Imam cist HTML fajl sa promenljivima u templejetu.

HMVC nema mnogo veze sa tim "true" parametrom HMVC, najgrublje receno, ti omogucava da dodatno unapredis dizajn svoje web aplikacija tako sto ces velike celine koje postoje izdvojiti u module koji imaju svoje kontrolere, modele, templejte, JS fajlove nezavisne od drugih. Klasican plugin sistem, recimo.

Sto se AJAX poziva tice, ja uvek imam jedinstven AJAX kontroler za korisnike i takav za bekend koji hendluje sve AJAX pozive od strane klijenta i vraca rezultate kao JSON objekat koji se kasnije parsuje u JS-u. Vrlo je zgodno za prenos gomile informacije razlicitog formata. AJAX kontroler dalje zove odgovarajuce biblioteke/modele/helper klase i hendluje taj deo price u pozadini. U sprezi sa pametno napisanom JS validacijom formi po tipu i dobro utegnutim language stringovima nema nijednog validnog razloga za ne koriscenje AJAX-a na svim formama danas

I na kraju pitanje templejta - svaki templejt moze da se apstrakuje i podeli na vece celine kojih u osnovi ima 3 - heder, content, footer. heder se sastoji kasnije od n razlicitih delovap oput dela za logo, search barova, navigacije itd. Ono sto je malo veci problem je sam deo sa sadrzajem koji moze da bude razlicit u zavisnosti od strane. Medjutim svi ti templehjti mogu da se ogole do kosutra koji se svodi na x div elemenata praviln orasporedjenih koji predstavljaju kontejnere a onda se ostali sitniji elementi izdvoje u posebne templejte i u kontoleru sklapaju u jedinstvenu stranu.
To je primer koji sam ti ja naveo na pocetku ove teme. Sistem je uzasno prost u biti samo ponekad zahteva malo vise rada.

 

[Skot]

Sto se AJAX poziva tice, ja uvek imam jedinstven AJAX kontroler za korisnike i takav za bekend koji hendluje sve AJAX pozive od strane klijenta i vraca rezultate kao JSON objekat koji se kasnije parsuje u JS-u. Vrlo je zgodno za prenos gomile informacije razlicitog formata. AJAX kontroler dalje zove odgovarajuce biblioteke/modele/helper klase i hendluje taj deo price u pozadini. U sprezi sa pametno napisanom JS validacijom formi po tipu i dobro utegnutim language stringovima nema nijednog validnog razloga za ne koriscenje AJAX-a na svim formama danas

Imam pitanje u vezi ovoga - jel validaciju radis server ili client side ili duplo?

 

[ays]

Verujem da i Kutija radi, kao i ja... obostrano. JS validacija sa klijentske strane i onda php validacija. Posto pisemo o CI, onda ja to radim uz pomoc CI validation helper-a.

 

[kUdtiHaEX]

Imam pitanje u vezi ovoga - jel validaciju radis server ili client side ili duplo?

Obostrano. Najbrza validacija je na strani klijenta i tu se najcesce radi provera da li je uneseno ono sto je neophodo i da li vrdnost nekog polja odgovara nekom regularnom izrazu. Naravno kod onih komplikovanijih formi koje zahtevaju instant vezu sa serverom (poput registracije korisnika recimo) radim u sprezi sa serverom ali tek kada je ispunjen osnovni uslov da se otvori jedna konekcija (recimo ako trazim email necu otvoriti konekciju ka serveru dok ono sto pise u polju ne prolazi email validaciju).

U 90% slucajeva, stvari se mogu resiti na klijentskoj strani i nema razloga da trazumiras server zbog toga

 

[kUdtiHaEX]

Verujem da i Kutija radi, kao i ja... obostrano. JS validacija sa klijentske strane i onda php validacija. Posto pisemo o CI, onda ja to radim uz pomoc CI validation helper-a.

Ja ne koristim validation helper, ne vidim preteranu korist u njemu iskren da budem. Nekako mi se cini da je on ipak korisniji ako se i forme koriste nan acin kako su ih CI develi zamislili ali meni je to preterano smaranje. Na kraju krajeva nema potrebe raditi overdesign nekog sistema, to moze vise da steti nego da koristi.

 

[ays]

Nisam ni napisao da koristis, nego da radis obostranu validaciju. Za sebe sam naveo da koristim, u izvesnim slucajevima, CI built-in validation helper.

 

[kUdtiHaEX]

Ma znam vuno komentarisem za sebe

 

[codejan]

Razmisljao se da li da dodatno apstraktujem CRUD Codignitera, ili da idem na prakticniju varijantu konkretnije apstrakcije automatizacije, radi boljih performansi aplikacije? -- Ala sam ga izrimovao, a?

Na kraju sam se odlucio za razuman nivo apstrakcije. I dalje imam CI u svojoj osnovi i moje metode kojima vrsim apstrakciju za neke opste brze stvari. Za sve sto trazi specificno kodiranje pisem kod onako kako su ga CI momci zamislili.

@Kutija:
Ja koristim validacioni niz za brzo i automatsko generisanje formi i njihovu validaciju i repopulaciju. Smatram to veoma korisno u sitacijama kad mi brzo treba aplikacija i gde mogu da se brze posvetim klijenstkoj validaciji.

@ays Kohana izgleda prilicno obecavajuca, jer se uklapa u moj sistem modula!

 

[kUdtiHaEX]

Ne znam sta ces dobiti apstrakcijom CRUD-a i kako mislis da ce to da utice na performanse. Vec sam ti naveo kljucne stvari na koje treba da pazis uvek, bilo da app pises u PHP-u, Pythony ili Rubiju. Neki osnovni set pravila mora das e postuje i ne zavisi mnogo od jezika. Tako da, CRUD je sam po sebi izuzetno prost kao koncept, elementi su vec uveliko poznati, nema nekih iznenadjujucih elemenata, nikakve preterane biznis logike, bar kad je klijentska strana u pitanju.

Ja se u svom razvoju uvek vise oslanjam na klijenta i gledam da veci deo posla obavim na klijentskoj strani. Razlozi su vrlo prosti - bolji UX, daleko brzi app, manje akanje servera i samim tim manji load, bolje performanse. Nesto poput GMaila Kada HTML simple-db koncept zazivi na strani klijenta tj. kada ga svi browseri zaista budu podrzavali i kada socketi prorade kako treba, razvoj web aplikacija ce krucijalno da se izmeni.
Mada, kakve ces tehnike primeniti zaivse i od samog projekta, njegove kompleksnosti, sta opsluzuje, koliko korisnika, da li treba da bude skalabilan i sl.

 

[kUdtiHaEX]

Za one koje zanima validacija na klijentsko jstrani, evog jednog efikasnog primera:

	//
	// Edit User Form
	//
	
	$("#form_users_edit").validate({
		rules: {
			first_name: {
				required: true
			},
			last_name: {
				required: true
			},
			username: {
				required: true,
				minlength: 3
			},
			password: {
				required: false,
				minlength: 6
			}
		},
		messages: {
			first_name: {
				required: users_add_view.first_name_required
			},
			last_name: {
				required: users_add_view.last_name_required
			},
			username: {
				required: users_add_view.username_required,
				minlength: users_add_view.username_length
			},
			password: {
				minlength: users_add_view.password_length
			},			
		}
	});

Ovo je set pravila kro koji se prolazi kada korisnik klikne na submit. U prvom delu su setovana pravila, u ovom slucaju su vrlo prosta (svode se na duzinu i da li je nesto obavezno ili ne) ali cesto su to i neki regularni izrazi i sl. Drugi deo su error poruke koje se izbacuju korisniku i koje predstavljaju vrlo jednostavnu implementaciju kroz JS:

var users_add_view = 
{
	'first_name_required' : 'Ime korisnika ne može biti prazno',
	'last_name_required' : 'Prezime korisnika ne može biti prazno',	
	'username_required' : 'Korisničko ime ne može biti prazno',
	'username_length' : 'Korisničko ime mora sadržati najmanje 3 karaktera',
	'password_required' : 'Šifra ne može biti prazna',
	'password_length' : 'Šifra mora sadržati najmanje 6 karaktera'
}

Samim tim postoji u multilang podrska koju ima i sam CI. Naravno, postoj ii validacija na strani servera, ali su daleko manje sanse da ce korisnik uspeti da upisen eku glupost i time da gnjavi server.

 

[ays]

@Kutija, jquery validate plugin, jedan od najboljih plugin-ova za jQuery, ali bukvalno!

@codejan,
Kohana je odlicna ali nedostatak prave dokumentacije je najveci problem iste i pomalo "elitisticki" stav glavnih i odgovornih ljudi, koji stoje iza tog framework-a.
Baci pogled na fuelPHP, ja testiram isti poslednjih par dana.

 

[ays]

@codejan, imas HMVC plugin za CI -> https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home

i fuelPHP i Kohana imaju hmvc implementirane od starta, sto je mozda i njihova najveca prednost u odnosu na CI. Takodje, kao i Yii, imaju Auth class built-in.
U poslednjih 6 meseci, slusam o tom Yii, skoro pa iskljucivo, hvalospeve. Evo, Kutija moze da potvrdi, nasa diskusija na temu istog, tamo krajem leta... obojica nismo bili odusevljeni, pogotovo nacinom na koji im je napisana dokumentacija...
Sto se mene tice, neka je CI "jednostavniji" i/ili "losiji" od Yii, ali ja cu najverovatnije ga se drzati jos neko vreme(osim ako fuelPHP se ne pokaze kao way to go). Uostalom u svim tim poredjenjima php framework-a, CI je uvek medju prva 3(najcesce na drugom mestu).
Citao sam, u tim poredjenjima, da je cakephp sa ver. 2.0 se dosta poboljsao, pogotovo po pitanju performansi, mada je i dalje spor. Medjutim, neka resanja i nisu preterano dobro napisana(previse su kopirali RoR).
Sto me opet vraca na pocetak price... CI ili Zend, posto su tu vec neko vreme ili Yii ili fuelPHP. Mozda bi mogla i Kohana tu da se ubaci ali manjak prave dokumentacije je zaista ogroman minus.

Kad zavrsim sa testiranjem fuelPHP(a to radim tako sto pisem identicnu aplikaciju sa CI i fuel) pa cu "javiti" utiske.

 

[Srbin do jaja]

Kako da prevazidjem problem sa jquery ui js bibliotekom. Evo sta se desava. Sam jquery ui fajl trazi css file u http://example.com/controller/css/jqueryui.css

umesto u http://example.com/css/jqueryui.css