Da li su sva "pravila" bitna?

I juče i danas se na pomalo čudan način povukle pitanje pravila koja aplikacija nameće korisniku.

Konkretno, juče sam veći deo dana proveo radeći na dokumentaciji. Svaki članak se sastoji od naslova i sadržaja. U takvim situacijama aplikacije uglavnom zahtevaju od korisnika da unesu obe vrednosti pre nego što prihvate izmene. To je nametnuto pravilo koje korisnik mora da poštuje kako bi mogao da koristi sistem.

Naša aplikacija nije toliko stroga pa zahteva samo naslov što mi se, kao korisniku, pokazalo jako zgodnim. Umesto da završavam stranicu po stranicu, prvo sam kreirao niz stranica na kojima treba da radim prostim unošenjem naslova pa tek onda počeo da unosim sadržaj. Na taj način sam imao celu strukturu pred sobom i tačno znao šta treba da radim i kako napredujem. Da je aplikacija od mene zahtevala i unos sadržaja, pitanje je da li bih tako radio.

Jutros je osvanuo komentar na jednu temu gde se korisnici pitaju zašto jedan element u activeCollabu zahteva minimalno 3 slova dugačak naslov. Razmišljajući o tome šta i kako da odgovorim čoveku, zapitao sam se li su uošte ta pravila i bitna? Zašto sistem jednostavno ne bi puštao korisnika da ne unese vrednost?

Na primer, ako korisnik ubaci zadatak bez opisa, sistem može da stavi opis na neku podrazumevanu vrednost. Kada korisnik naknadno vidi unos, može da upotpuni podatke ako želi ili ostavi tako kako je ako mu to nije bitno...

Prijavi problema kao na slici ništa ne nedostaje, iako je kratak opis izostavljen. Sve što treba je tu:

Kasnije, kada se detaljno pozabavi problemom, Goran može uzeti i izmeniti "[NO SUMMARY]" u "Nakon instalacije modula, keš se ne osveži što može praviti probleme pri učitavanju stilova" ili šta god da nađe kao stvaran uzrok problema.

Da sumiram, pitanje je da li su sva pravila koja ubacujemo u svoje aplikacije dobra? Da li bismo olakšali ili otežali korisniku time što bismo umesto forsiranog unosa omogućili da ostavi polje praznim? Koja su mesta u aplikaciji gde po inerciji dodajemo pravila koja nužno i ne pomažu i bez kojih se može?

SVN merge

Stvarno ne bih mogao da zamislim kako bismo izlazili na kraj sa poslom da nema SVN-a. Trenutna operacija je sledeća - četiri programera koja svakodnevno rade na dve razvojne verzije aplikacije koja će uskoro prebaciti 200 hiljada redova koda (samo naš kod, bez dodatnih biblioteka kao što je Smarty i SwiftMailer), plus na održavanju sajta koji je u potpunosti custom razvijan. Nije to ništa veliko (probajte da zamislite tim od 30 programera koji rade na legacy sistemu koji ima par miliona redova koda), ali bez sistema kao što je SVN bi nastao pravi haos. Iako je nezamenljiv alat koji stvarno pomaže da bolje završavamo posao, neke stvari su i dalje dosta nezgodne. Kao što rekoh, uvek paralelno radimo na dve grane aplikacije - održavanje stabilne grane (v1.1) i glavnoj grani koja donosi nova veća unapređenja i koja je uglavnom nestabilna (v1.2). Kada su stvari tako postavljene, s vremena na vreme izmene iz v1.1 treba da ubacimo u v1.2 koji je odavno krenuo svojim tokom; tj. treba da mergeujemo stabilni branch u trunk (trunk je glavna razvojna grana).

Proces ubacivanja izmena iz jedne grane u trunk koji se već 6 meseci razvija samostalno definitivno ne deluje kao naivan posao. SVN tu pomaže, ali je to i dalje proces koji zna da uzme i do po par sati i gde dosta toga može da pođe na loše. Evo kako to radimo:

1. Nađemo reviziju kada je zadnji put rađen merge (revizija XXXX u daljim komandama). Ovo je bitno jer merge izmene između te revizije i trenutne revizije u grani ubacivati u trunk. Ako omašimo reviziju i navedemo pogrešnu, možemo primeniti pogrešne izmene.

2. Na disk checkoutujemo svež kod iz trunka. merge radi tako što upoređuje određenu reviziju grane sa najsvežijim kodom u grani i te izmene ubacuje u work copy u kome smo. Dakle, imamo svež trunk, i iz terminala dođemo do njega:

cd /Library/WebServer/Documents/activecollab trunk/activecollab

Nakon toga radimo merge:

svn merge -rXXXX:HEAD "REPOSITORY-URL/activecollab/branches/REL 1.1"

Kada znam da je bilo dosta izmena, obično odradim dry run koji lista izmene koje će napraviti, bez da ih primeni na sam kod. Dosta korisno da vidite koliko će vam glavobolje merge zadati:

svn merge -rXXXX:HEAD --dry-run "REPOSITORY-URL/activecollab/branches/REL 1.1"

3. Pustimo merge komandu da radi posao. Kada merge naleti na konflikt, možete ga razrešiti ili ostaviti razrešenje za kasnije. Iako SVN nudi više opcija ja lično koristim samo tri komande:

p - postpone (razreši kasnije), mf - mine force (razreši koristeći kod iz trunka), tf - their force (razreši koristeći kod iz grane).

4. Commitujemo work copy. Sada kada su sve izmene primenjene i konflikti razrešeni imamo nov, svež i up-to-date trunk.

I za kraj dva saveta. Prvo, često radite merge. Najveća sranja sam imao kada sam puštao da se nakupe meseci izmena. Tada sam morao da odvajam po celo veče samo za merge. Sporo, mučno i traćenje vremena. Drugo, automatizujte proces. Sad ću da sednem i napišem script koji će mi skinuti veći deo merge procesa sa vrata. Razrešavanje konflikata je i dalje nešto što ću morati da nadgledam i ručno rešavam, ali veći deo operacija može da ide automatski.

Vaša iskustva i saveti sa SVN-om i branchevima?

Versions

Nakon višemesečne javne bete, nedavno je objavljen Versions 1.0, novi grafički interfejs za rad sa Subversionom za Mac OS. Par dana posle Versions je postao i zvaničan SVN klijent u firmi zamenivši stari dobri SvnX, pre svega zahvaljujući Godži. Iscimao se čovek da nas sve odreda prebaci :)

Kao što rekoh, pre Versions svi smo koristili SvnX. SvnX je besplatan, lepo radi posao, ali mu je interfejs dosta čudan dok se ne naviknete, ponajviše zato što koristi prozor za svaki bitniji alat. Kada radite prost update na primer, verovatno ćete imati otvorena 3 prozora - Work Copies i Repositories koji su otvoreni po defaultu i prozor sa informacijama o samom Work Copyju kroz koji radite update. Mnogo, posebno ako dosta koristite ekspoze gde svaki nepotreban prozor samo pravi nered.

Za razliku od njega, Versions nudi lep, klasičan single window interfejs na koji smo uglavnom navikli. Mogućnosti su standardne za alate ove vrste - tu je manje više sve što vam treba da biste radili sa work copyjima, repository browser koji omogućava direktan rad sa fajlovima unutar repositoryja, bez potrebe za work copyjem itd. Koliko sam imao prilike da primetim u zadnjih par nedelja korišćenja, Versions ne nudi ništa revolucionarno novo, ali je izvedba vrhunska što je sasvim dovoljno da vas navuče.

Evo par stvari koje se meni izuzetno sviđaju:

1. Kada gledate listu izmenjenih fajlova u work copyju, ne dobijete flat listu već tačno vidite izmene u strukturi projekta.
2. U bookmarks sekciji, Versions prikazuje broj modifikovanih fajlova (žuti mehurić) u samom work copyju i broj izmenjenih fajlova na serveru (plavi mehurić). Ovo jasno i glasno kaže da je neko commitovao izmene i da bi verovatno trebali da odradite update.
3. Inspector olakšava rad sa svojstvima fajlova i foldera. Posebno je jednostavan ignore, nešto za šta sam ranije koristio komandnu liniju.
4. Postoji niz alata koji se mogu koristiti za pregled diffova (FileMerge, TextWrangler itd). Versions vam omogućava da izaberete alata koji vam najviše odgovara.

Većih zamerki stvarno nemam, valjda zato što sam uz SvnX navikao da neke stvari kao što su konflikti i merge brancheva rešavam ručno... Voleo bih kada bi Versions imao alat koji olakšava te operacije, ali mogu da živim bez njega.

Najtoplija preporuka ekipi koja svakodnevno koristi SVN i treba joj dobro grafičko okruženje za rad sa istim. Versions je komercijalan alat i košta 39EUR.

PHP.JS

Ne sećam se kada mi se zadnji put neki PHP resurs učinio dovoljno zanimljivim da bih poželeo da blogujem o njemu. No, posle dugo vremena evo ga jedan. U pitanju niz osnovnih PHP funkcija implementiranih u JavaScriptu. Ako ste radili sa JS-om i padne vam na pamet kako bi bilo super da imate strcmp() ili md5() na raspolaganju, PHP.JS nudi rešenje.

Paket sadrži 190 portovanih funkcija. Nema potrebe sve da ih koristite - ponekad je dovoljno izvući jednu funkciju i prilagoditi je svojim potrebama ili pogledati kako je neko drugi rešio problem.

Za svaku pohvalu. Hvala ekipi na trudu!

Ružno pače

Primetio sam da u razvoju prve verzije aplikacije imaju tri osnovne faze u pogledu toga kako cela stvar izgleda:

1. Postavljanje skela - ovo je početna faza kada se spremi framework, rasporede osnovni moduli, podesi autentifikacija, upload i slične ostale stvari koje će aplikacija koristi. Ukoliko ste uhodani sa platformom na kojoj radite ovo ide jako brzo - maksimalno par dana.
2. Ružno pače - u ovoj fazi polako gradite funkcionalnost aplikacije, ali stvari ne izgledaju i ne rade baš najbolje. Rupe u funkcionalnosti su na sve strane, ono što radi obično zahteva još dosta vremena da dođe na očekivani nivo, interfejs nije još uvek lepo "seo" itd.
3. Peglanje - početak ove faze se preklapa sa krajem prethodne, a zvanično počinje onog trenutka kada kažete da je dosta dodavanja novih stvari i da treba da se fokusirate na pegalanje onog što je tu. Ovo ne bi bio loš trenutak da uvučete neke beta testere u priču. Ljudi koji su sveži sa aplikacijom će sigurno primetiti gomilu stvari koje su vama, kao nekom ko ne skida pogled sa nje već dosta vremena, promakle.

Na kraju ovog puta je jedna sporija faza, gde može malo da se odahne i napune baterije. Već sam je pominjao u ovom tekstu. Posle ide gomila bugova koje će ljudi pronaći kada počnu da koriste softver. Pa nove verzije koje krpe te bugove, dodaju nove funkcije (i nove bugove) i tako u krugu...

Pored finansijske dobiti (ili neke druge ako ne ciljate na zaradu), nagrada je i to da ste stvorili nešto novo iz ničega. Neki uživaju u tome, neki ne, ali tu je u svakom slučaju.

Zašto je JavaScript težak

Najveći problem koji imam pri JavaScript razvoju je konstantno mešanje konstrukcije, stilova i ponašanja u istom kodu.

Što se stilova tiče njih je relativno lako držati odvojene u zasebnom fajlu, ali opet se često dešava da se svojstva moraju menjati direktno iz JavaScripta... Ne mogu se imati klase baš za svaku moguću situaciju koja nam treba.

Kao što rekoh, stilovi nisu problem - problem je konstrukcija i ponašanje koje se kači na nju. Do sada nisam našao dovoljno fleksibilan metod koji omogućava jasnu separaciju između te dve stvari.

Kod PHP-a je lako jer on ne uključuje ponašanje već radi po run through principu (protrčiš i zaboraviš). Na primer, kada u activeCollabu korisnik zatraži projekat posetivši URL tipa:

http://projects.mycompany.com/projects/12

kontroler će od modela tražiti da učita projekat #12 i proslediti ga viewu da ga isti ispiše u pogodnom obliku. Run through - učita, ispiše, zaboravi da se ikad išta desilo.

Kod JavaScripta stvari ne idu baš tako lako jer HTML nije samo view već i konstrukcija. Evo ga primer:

$('<button type="button">Add option</button>').appendTo('body');

To bi u PHP-u bilo dosta - samo ispiši HTML i prosledi ga browseru. Ali, ovo dugme bez ikakvog ponašanja prikačenog na njega ne radi ništa. Zato moramo da dodamo ponašanje NAKON što je konstrukcija složena.

$('<button type="button">Add option</button>').click(function() {
alert('clicked!');
}).appendTo('body');

Ovo je samo jednostavan primer. Složeniji problemi mogu bili jako komplikovani sa jako mnogo nivoa konstruisanja elemenata i kačenja ponašanja na njih, intervalima i timerima, događajima... U celoj toj gužvi jako je teško jasno odvojiti slojeve što dovodi do koda od koga se ljudima često prevrne stomak kada ga prvi put vide.

PS: Primeri se oslanjaju na jQuery JavaScript biblioteku.

Softver po meri i fokus

Ukoliko imate proizvod koji (pro)dajete u bilo kom obliku (setup.exe, skript, servis itd) pre ili kasnije će se pojaviti neko ko će želeti da se vaše rešenje prekroji kako bi odgovaralo njegovim potrebama. Naravno, vi ćete biti prvi kojima će taj projekat biti ponuđen kao neko ko najbolje poznaje samu aplikaciju i kod. U slučajevima kada ne nudite izvorni kod to je i jedino rešenje.

Nema ništa loše ni u prihvatanju ni u odbijanju takvog posla ako vidite zaradu u tome, ali postoji par stvari kojih treba biti svestan:

1. Da li taj projekat podrazumeva i usklađivanje prekrojenog rešenja sa novim verzijama koje izdate? Meni lično, a verujem da nisam sam, nema ništa gore nego terati dve ili više različitih grana u isto vreme. Vremenom će vam dosaditi i možda se budeti lupali u glavu zašto ste dozvolili da se za "sitnu lovu" tako obavežete.
2. Ovakvi projekti su uglavnom samo kratkoročna rešenja za dolazak do novca. Na duže staze se više isplati da ulažete u razvoj proizvoda i marketing.
3. Ne bi smeli da dođete u situaciju da trošite previše vremena na customization projekte i ugrozite svoj posao jer ne radite na samom proizvodu.

Ne može se generalizovati (softverska rešenja pokrivaju raspon od besplatnih do rešenja koja koštaju milione), ali moje je mišljenje da u prvih godinu dana nipošto ne prihvatate ovakve projekte. Umesto toga slušajte šta vaši korisnici traže i fokusirajte se na razvoj samog proizvoda. Teško da postoji išta što će se bolje isplatiti na duže staze od toga.

Što se našeg proizvoda tiče, mi smo se opredelili za kompletno otvorenu platformu sa dva osnovan metoda proširivanja - API i moduli. Ako to nije dosta, tu je sav izvorni kod. Na ovaj način naši klijenti imaju mogućnost da sami prilagode aplikaciju svojim potrebama ili da unajme nekog da to uradi za njih, a da mi nismo jedina opcija. Win-Win-Win ako mene pitanje - dobro i mušterijama i nama, a i drugim programerskim firmama koje mogu da zarade prilagođavajući naše rešenje specifičnim potrebama klijenata.

Kratko o kontakt formama

U zadnjih par dana sam poslao 2 maila vezana za posao firmama kroz kontakt forme na njihovim sajtovima. U oba slučaja sam dobio potvrdu od njihovog sistema da je poruka primljena i prosleđena gde treba.

Juhu! Ovo je stvarno bitan korak. Ako forma na vašem sajtu ne šalje ovakva "Šta se upravo desilo i šta dalje?" obaveštenja trebalo bi da ih dodate. Značajno unapređuju korisnički doživljaj jer korisniku jasno govori da je sve u redu i kako će se razgovor nastaviti.

Međutim, ono što u oba slučaja nisam dobio je tekst MOJE poruke. Nije najvažnija stvar na svetu, ali kada je priča vezana za posao voleo bih da imam celu diskusiju u logovima. Ovo je možda samo moj trip, ali mislim da ne bi bilo loše da na dnu poruke sa obaveštenjem o prispeću stoji i:

You wrote:

-- Tekst moje poruke --

Bio bi to fin detalj.

Zend Studio Profiler na Leopardu

Profiler je ubedljivo najbolji alat ukoliko tražite uska grla u vašim PHP aplikacijama. Da bi isti radio unutar Zend Studija treba vam Zend Debugger serverska ekstenzija. Ako koristite PHP i Apache koji dolaze uz Leopard primetićete da stvari baš i ne funkcionišu kako treba. Problem je u tome što Zend Debugger ne radi sa Apachem koji radi u 64-bitnim režimu kako je isti konfigurisan na Leopardu. Rešenje - ubijte Apache iz Sharing Preferences panela i poterajte ga u 32-bitnom režimu:

sudo arch -i386 /usr/sbin/httpd

Više detalja možete naći u ovoj diskusiji. Postujem sebi kao podsetnik pošto sumanjam da će ovo ikome zatrebati :)

Ako ste početnik koristite gotov framework

S vremena na vreme me ljudi koji tek počinju da uče programiranje cimnu sa pokojim pitanjem: objektno orijentisano odmah od start ili proceduralno pa se tek kasnije prebaciti OOP, PHP4 ili PHP5, mysql ili mysqli, svoj DB wrapper ili neki već gotov itd.

Mislim da imam jednostavno rešenje na ova pitanja: koristite neki gotov framework.

Framework je uhodana staza napravljena kako bi se smanjilo lutanje i što efikasnije i lakše stiglo do cilja. Grupa ljudi koja stoji iza razvoja frameworka je uložila ogromnu količinu vremena, iskustva i sivih ćelija u njegovo kreiranje i testiranje. Pitanja koja obično muče početnike su već odgovorena, a uz to dobijate jako mnogo alata i tehnika koje će vam pomoći da brže rešite problem na kome radite.

U trenutku kada za pojasom budete imali par komercialnih projekata i određenu količinu iskustva verovatno ćete početi da dovodite u pitanje odluke koje su autori frameworka doneli prilikom njegovog dizajniranja i to je skroz OK. Ne postoji savršen framework i uvek ima mesta za unapređenja, ali u tom trenutku ćete biti znatno kompetentniji i moći ćete bolje da procenite situaciji i donesete odluku.

Dok ne dođete u tu fazu koristite sakupljeno iskustvo i trud drugih, znatno iskusijih developera. Od postojećih frameworka preporučio bih Django (Python), Rails (Ruby), CakePHP (PHP) i CodeIgniter (PHP).

PS:

Kada spomenuh Django, Petar mi je jutros javio da je prva verzija otvorene knjige o Djangu gotova i da je možete čitati online potpuno besplatno. Stvarno vredan resurs. Čak i ekipa koja ne koristi Django može da preleti kroz poglavlja čisto da pokupi par zanimljivih ideja.

Isplati li se PHP4 podrška kada se ceo svet prebacuje na PHP5?

Jedna od stvari na kojoj smo radili u novoj verziji 1.0 activeCollaba je smanjenje sistemskih zahteva. Stari activeCollab je zahtevao PHP5, MySQL sa InnoDB podrškom, SimpleXML ekstenziju i štošta još. Prava egzotika za većinu. Većina ljudi ne zna i ne želi da zna ništa o tome - oni samo žele da aplikacija koju su kupili radi. Stoga smo skresali zahteve na minimum: PHP4, bilo koji MySQL i najosnovnije PHP ekstenzije. activeCollab će iskoristiti napredne mogućnosti platforme ako im ima na raspolaganju (autoload, transakcije, razne PHP5 specifične funkcije itd), ali ih ne zahteva. Sve će normalno raditi i bez toga.

Ubijanje PHP5 zahtevnosti je došlo prilično skupo - veliki deo aplikacije (~80%) je trebalo prepraviti ili ponovo napisati.

Kada je pre par meseci objavljeno da PHP4 neće više biti razvijan i podržavan i kada je krenula GoPHP5 inicijativa sa ciljem da se u narednih godinu dana PHP4 kompletno potisne i zameni kompletnijom, modernijom i u svakom pogledu boljom "peticom" mi smo bili u sred prebacivanja starog PHP5-only koda na PHP4. Ne možemo da ne kontriramo...

Iako je naš prelazak na PHP4 bio kompletno proračunat korak nismo bili u poptunosti sigurni koliko ćemo time zaraditi. U tom trenutku jedino na šta smo mogli da se oslonimo je bio zdrav razum i osećaj da je to što radimo ispravno.

Na kraju se ispotavilo da bismo napravili katastrofalnu grešku da smo i dalje gurali PHP5. Šteta bi bila ogromna ne samo zbog gubitaka u direktnoj prodaji (morali bismo da okrenemo leđa polovini kupaca) već i zbog smanjenog broja ljudi izloženih activeCollabu.

Nepuna dva meseca nakon početka prodaje activeCollaba sav trud i uloženi novac se višestruko otplatio, a imamo još skoro dva meseca do trenutka kada PHP zajednica zvanično prestane rad na PHP4 i po mojoj slobodnoj proceni još bar 6 - 10 meseci do trenutka kada više od 90% hostinga pređe na novu verziju. Na taj vremenski period novac koji bismo izgubili bi bio baš velik.

Ukoliko razvijate aplikaciju za šire tržište zaletite se na PHP5 samo ako planirate da lansirate od leta 2008. Ako lansirate ranije bacite rečunicu na papir i vidite koliko time gubite. Iz našeg iskustva u ovom trenutku odluka je no-brainer - PHP4 je nezaobilazan, bar još neko vreme.

Apache, PHP i MySQL na Leopardu

Upgrade na Leopard je skroz rasturio moj Apache + PHP + MySQL setup. U ovom tekstu imate sve korake kako da vratite stvari u normalu. Ja sam imao tu nesreću da sam taj tekst našao tek na kraju, kada sam već namestio većinu stvari. No dobro, bar sam naučio neke nove stvari.

Borba protiv spam komentara

Par stvari koje sam koristio kada sam pravio sistem za borbu protiv spam komentara u skripti koja vozi activeCollab sajt:

1. Svi komentari su SPAM dok se ne dokaže da je drugačije.
2. Spamerima pucaju na linkove. Iz tog razloga svaki komentar koji sadrži URL treba da bude označen za moderaciju. Postoje dva mesta u koja spameri navode URL-ove - link do autorove lične stranice i sam tekst komentara. Ako u jednoj od te dve vrednosti naletite na "http://" ili "https://" odmah komentar označite za moderaciju.
3. Ako naletite na više od 3 URL-a u komentaru zamolite autora da ispravi tekst komentara i smanji broj linkova. Čovek će to lako razumeti; bot baš i neće, a ovim ćete sprečiti ogromnu količinu komentara da ikada ulete u sistem što automatski smanjuje cimanje oko moderacije.
4. Stari postovi su uglavnom meta spamera tako da unosi starije od 2 nedelje na kojima ne očekujete dalju diskusiju obavezno treba zaključati.

Ništa fancy, sve je jasno i logično, a najbolje u celoj priči je da rešenje koje koristi ove tehnike i pored svoje jednostavnosti zadržava ogroman broj SPAM komentara van sistema. Oni koji prođu se ručno moderišu, ali njih je stvarno malo tako da ni to nije neki veliki problem.

Jednostavno, a moćno

Jutros, dok sam čitao tekstove o lansiranju web aplikacija, naleteh na ovaj komentar:

[Mimo]: It seems very simple but yet powerful. What part of the development took most of the time/work?

[JF]: The simple yet powerful part ;)

» Izvor

Jednostavnost zahteva mnogo vremena i rada i retko se postiže iz prve. Ponekad se desi da vam pravo rešenje koje je i jednostavno i lepo i elegantno prosto sine u glavi, ali takve situacije su retke. Dolazak do jednog takvog rešenja je i dalje dug proces koji zahteva otvorenost ka promenama, mnogo isprobavanja i vreme.

Brzo serviranje gomile CSS i JS fajlova

Upravo sam naleteo na odličnu tehniku za brzo serviranje statičnog sadržaja, pre svega CSS i JS fajlova. Ako seckate CSS i JS na više fajlova kako biste raspodelili stvari u logične celine onda se vrlo lako možete suočavate sa problemima koje uzrokuje prevelik broj HTTP zahteva. Tehnika opisana u Faster Page Loads—Bundle Your CSS and Javascript članku na SitePointu omogućava da se više fajlova istog tipa iz istog foldera spoje na server strani i budu usluženi kroz jedan HTTP zahtev, samim tim dovodeći do značajno bržeg učitavanja stranice.

Logika web aplikacija

Na DevProTak forumu se (opet) povela interesantna diskusija o template engineima (Smarty i bratija) i srodnim pitanjima, kroz offtopic naravno. Jedna od zanimljivih stvari u diskusiji je tvrdnja jednog učesnika da ne koristi nikakvu logiku unutar templatea i da voli da mu je sva logika na jednom mestu, tj. unutar aplikacije. Ta tvrdnja me je navela da opišem sistem koji smatram dobrim i kako je logika raspoređena u njemu. Sistem koji trenutno koristim se bazira na MVC (skraćeno za Model View Controller) načinu odvajanja osnovnih delova aplikacije:

1. Model - uređuje pravila koja važe između objekata sa kojima aplikacija barata
2. View - prikaz rezultata obrade
3. Kontroler - zadužen za obradu korisnikovog zahteva

U tako uređenom sistemu postoje tri precizno razgraničene logike:

1. Biznis logika (često se još naziva modeom) je skup pravila koja važe među objektima sa kojima aplikacija barata. Na primer, članak pripada kategoriji; kada se kategorija obriše svi članci iz te kategorije se takođe brišu i resetuje se globalni brojač. Ili pak, ako posetilac ostavi komentar na članak diže se popularnost kategorije kojoj članak pripada. Dakle, to su neka interna pravila kojih su objekti svesni i koja poštuju.
2. Kontrolerska logika je logika koja se koristi za obradu korisničkog zahteva. Korisnik od aplikacije zatraži članak broj 12; ako ga aplikacija ne nađe korisnik dobija poruku o grešci. Ako ga nađe, proverava se da li korisnik može da pristupi tom članku. Ako sme isti se štampa na ekran, a ako ne korisnik dobija poruku o grešci gde se kaže da nema potrebne dozvole da bi video zatraženi članak. Primetite razliku između ovoga i model logike - ovde je sve o tome kako uslužiti korisnikov zahtev, ne kako su objekti međusobno povezani i koja pravila važe među njima.
3. Prezentaciona logika se brine samo o prikazu podataka. Primer za ovo je određivanje da li je red tabele paran ili ne i bojanje u skladu sa tim ili pak odlučivanje da li da se prikaže određeni blok ili ne u skladu sa prosleđenim podacima (nema poente prikazati logout opciju ako nemamo ulogovanog korisnika).

Ovakav način odvajanja se možda u početku čini suviše komplikovan, ali je u suštini prilično jednostavan i logičan. U nekom od narednih tekstova ću opisati na konkretnom primeru kako se ovaj sistem primenjuje, zašto ima smisla i koje su mu prednosti.