Ez az alap zen sminkel készült képernyőfotó tehát ez alapból ilyen sajnos.
itt egy kép:http://noob.hu/2010/10/09/zen_hiba.JPG
ez ugyan chromban készült de elhihetitek firefox-ban is ott van más böngészőben pedig még nem néztem.
Azt szeretném csinálni hogy a body-nak adok egy hátteret és a tartalom mint egy lapon legyen és az a képernyő aljától a tetejééig érjen, mert így ha nem ér le akkor a body háttere nem csak oldalt látszik hanem alul is azon a részen is ahol nem ér le a az aljára a div.

FÉLRE NE ÉRTSETEK TÖBB ANYI TARTALOM VAN HOGY MÉG SCROLLAZNI IS LEHET AZ OLDALT ÉS HA ADOK A HTML BODY -NAK ÉS A DIV-NEK HEIGHT:100%-OT AKKOR IS OTT A HIBA.

Az érdekes hogy a body SEM ér le a képernyő aljára. Olyan mintha magának a window-nak lenne alul margin-ja vagy padding-ja.
Mi ez?

Jó pár év programozgatás után, úgy gondoltam kipróbálom a Drupal keretrendszert.
Fontos tisztázni a Drupal nem egy programozási nyelv, sokkal inkább egy alkalmazásokat egybegyűjtő rendszer, melyhez széleskörű PHP, Javascript, SQL (pl.MySQL), CSS, HTML (DHTML stb.), némi Ajax és JQuery ismeret szükséges.
Kezdők számára kaotikusnak tűnik, de azért el lehet benne találni;)

Nekiálltam tehát egy site megépítésének. Beléptetéssel, szavazással, kereséssel, kissebb egyedi igényekkel fűszerezve. Elég kaotikusnak tűnt az egész, mi hol van, de ezt pár óra keresgélés után, ki lehetett bogózni. Az igazi nagy problémát az elején, az egyedi smink elkészítése jelentette. Mégis elkészült 12 óra és 28 perc alatt, az első értékelhető példány és már fent is volt adatbázisostul a neten. Tudom mit mondanátok: 'olyan is'. Hát nem! Kompromisszumok nélkül, olyan módon ahogy megrendelő kérte. Igaz később jött egy kívánság, hogy a fejlécbe tegyek egy kis Flasht, lehetőleg úgy hogy ne befolyásolja a botokat. Azért ez még pár órát rátett néhány nappal később szombat délelött, amíg mindenki aludt nálunk;)
Na, ez komolyan elgondolkodtatott. Egy senior fejlesztőnek ez a feladat 3-4 hétig tartott volna 0-ról. Egy juniournak, meg 3 hónap;) Látványos eredmény és mindent tud, amit akartunk. Nem semmi! Le is döbbentem:o
Elkezdtem hát mégjobban tanulmányozni programozói szemmel és azt a következtetést vontam le, hogy tényleg sok mindenre jó. Vannak hibái, de folyamatosan fejlődik és javul! Ami nincs benne vagy nem tetszik azt szépen lekódolja az ember és kész. Így van kitalálva az egész rendszer. Össze lehet rakni, mint egy legót és ha nincs olyan darab ami kellene, átalakíthatom vagy készíthetek egy újat hozzá. Ez ám a programozói kánaán!:)
Általánosságban azt mondhatom, hogy a következő fejlesztési metodika jött be nekem:
Fel kell állítani a specifikációt, méghozzá legalább két rétegben:
- Az első a megrendelő kívánságai, minél széleskörűbben, ami igazodik az 'atyaúristen, mindenható' végfelhasználó igényeihez, a publikumhoz. (Végülis ezért van az egész, nem?)
Ha a megrendelő nem igazodik a végfelhasználó nevü főnökéhez, akkor halálra van ítélve a piacon.
- A második a programozható megvalósítási terv és a részfaladatok elkülönítése. Ebből lehet becsülni a fejlesztési időt, és a szükséges erőforrásokat. A vasat és a programozókat, esetleges licencek díjat, stb. Egy kellően tapasztalt projectmenedzser, de egy programozó is (én pl. mindkettő vagyok/voltam egyszerre) tudja, hogy időbeli hibatűréssel kell számolni, mert menet közben kiderülhetnek olyan dolgok, amiket meg kell oldani. Mindig! Ha elég jó a specifikáció, akkor ez kb. 20%-30%, tehát 1 hónapos tervezett fejlesztési idő mellett ez kb. 1 -1,5 hét plusz idő.
Ha komoly változások vannak ez akár 70%-ra is felmehet, ezzel számolnia kell a projectmenedzsernek. Ezenkívül vannak nagyon kemény dió vállalkozások is. Itt még 100%-200%-os időtúllépés sem ritka. A szaknyelv ezeket már waporware-eknek nevezi. Mert előfordulhat, hogy az elhúzódó fejlesztési idő túllépi a várható elévülési időt, és akkor már értelmetlen tovább folytatni. Az igazán jó ötletnél ez nem fordulhat elő. Ez például az ötlet próbája is egyben;)
Tapasztalataim azt mutatják egy project akkor lesz igazán átütő jellegű, ha a projectmenedzser képes lenne egyébként maga is kifejleszteni a kívánt alkalmazást(okat).
Ez az üzleti felállás. A specifikációs szint.
Ha ez megvan a technikai megvalósítás jöhet:
-Első lépés: körül kell nézni laposan mit tud a Drupal hozzáteni a projecthez. Át kell nézni az összes idevágó modult. Mit tud, mi kell hozzá, stb.
-Második lépés: össze kell állítani a rendelkezésre álló alaprendszerből és modulokból a vázat vagy hívhatjuk keretnek is. Ezért hívják a Drupalt keretrendszernek, nem pedig fejlesztő rendszernek, milyen érdekes:) Ezt nagyon alaposan dokumentálni kell!!!
-Harmadik lépés: átalakítani vagy megírni a speciális igényeket kielégítő részeket. Ezt is dokumentálni kell, sőt érdemes még a kódba alapos kommenteket is tenni. Célszerű már az elején úgy nekiállni, hogy áttanulmányozzuk a Drupal fejlesztési konvencióit, hogy később, akár a rendszerbe is lehessen illeszteni. Ez nem csak közösség érdekeit szolgálja, hanem a magunkét is, mert idővel, ha már megtanultuk/megszoktuk a szintaktikát és a szokásokat, akkor mi magunk is jobban eltalálunk benne, akár évek múlva is. Sőt ha jön még kolléga, ő is hozzá tud fogni a munkához.
-Negyedik lépés: a kialakult egyedi rendszer tesztelése. A tesztelést a részfeladatoknál is célszerű elvégezni. Minél kissebb a részfeladat annál könnyebb! Ha a részfeladatok folymatosan tesztelve vannak, akkor a fejlesztési kockázat a 0-hoz konvergál!

Összeségében azt mondhatom, hogy eddig nem jött olyan igény, amit ne tudtam volna megvalósítani a Drupal keretrendszer segítségével. Hangsúlyozom azonban, hogy ez egy keretrendszer és nem maga a fejlesztő eszköz!

Egy tapasztalt sokat megélt programozó, már eleve elrakja korábbi munkáit, moduljait. Ha esetleg később kellene, felhasználja, esetleg kicsit átalakítja (passzintja). Egy idő múlva ez egy saját keretrendszerré fejlődik. A drupal is egy ilyen keretrendszer, csak itt több senior programozó dobja össze munkáját és együttes szellemi erővel állítja fel a keretrendszert. Ehhez csak egyetlen dolog kell: egy szabályrendszer felállítása, amit be is kell tartani, hogy összehangoltan tudjon működni a project. (Drupal is egy project.)
Nem kell hozzá agysebésznek lenni, hogy rájöjjünk ennek óriási hatástöbbszöröző ereje van! Egy programozó akármilyen ügyes is, nem ér fel más 1000 ugyanilyen ügyes (ha nem ügyesebb) programozóval. Ehhez nem kell mást tennie, mint elfogadni a Drupal rendszer fejlesztési konvencióit és nem sajnálni a munkáját másoktól;)
Ezzel minden résztvevő fejlesztő nyer, nemcsak az én szellemi termékemet használják mások, hanem én is a másokét! Megéri, mert az egyes programozó ezred vagy inkább milliomod részt tesz csak hozzá az egész nagy műhöz és mégis élvezheti előnyeit "ingyen". Azért nem teljesen ingyen, mert a keretrendszer elsajátításohoz energiát és időt kell befekteni.

Na ez lenne a nagy DRUPAL CSAPDA?

"A teknős kidugja a fejét, körülnéz és aztán indul el."