Objektum orientált HTML generálás?
Elkövettem egy ilyet:A cél kb. az lenne, hogy egy objektumként kezelem a HTML oldalakat, amelyek a HTML Tag-eknek megfelelő objektumokból épülnek fel. (A HTML1tag a <br/> jellegű tag-ek miatt tűnt szükségesnek)
Két kérdés ezzel kapcsolatban:
1. A kódban látható-e valami, amivel felrúgok/megsértek valamiféle elvet?
2. Az tiszta, hogy ismét a kerék feltalálásának esetével állunk szemközt, de az nem, hogy ilyesmit csak keretrendszerben valósítottak meg vagy az alap PHP is tartalmaz ilyet, csak nem találom?
+1: gyanítom, ez messze nem az optimális módszer HTML oldalak generálásához, de most nem is ez a cél. :-)
ui: valaki szóljon rám, ha már fárasztó vagyok! Ezt - kivételesen - komolyan kérem!
■
<?php
abstract class HTMLtag {
protected $content=array();
protected $options=NULL;
function __construct($content=NULL,$opt=NULL){
$this->initialize();
if(isset($content)){ $this->add($content); }
if(isset($opt)){ $this->options=$opt; }
}
function add($content){
$this->content[]=$content;
}
function initialize(){
$this->content=array();
}
function show(){
echo $this->tagOpen();
foreach($this->content as $v){
if($v instanceof HTMLtag){ $v->show(); }
else { echo $v; }
}
echo $this->tagClose();
}
protected function tagOpen(){
return '<'.get_class($this).' '.$this->options.'>';
}
protected function tagClose(){
return '</'.get_class($this).'>';
}
}
class HTML1tag extends HTMLtag {
protected function tagOpen(){
return '<'.get_class($this).' '.$this->options.' />';
}
protected function tagClose(){
return "";
}
class Div extends HTMLtag {
}
class Body extends HTMLtag {
}
class BR extends HTML1tag{
}
Két kérdés ezzel kapcsolatban:
1. A kódban látható-e valami, amivel felrúgok/megsértek valamiféle elvet?
2. Az tiszta, hogy ismét a kerék feltalálásának esetével állunk szemközt, de az nem, hogy ilyesmit csak keretrendszerben valósítottak meg vagy az alap PHP is tartalmaz ilyet, csak nem találom?
+1: gyanítom, ez messze nem az optimális módszer HTML oldalak generálásához, de most nem is ez a cél. :-)
ui: valaki szóljon rám, ha már fárasztó vagyok! Ezt - kivételesen - komolyan kérem!
2. kérdésre
Eddig eljutottam, de XML-ből
SimpleXML
Köszi! (tudtam én, hogy már
(tudtam én, hogy már megint a kereket találom felfele... :-) )
Az addAttribute működése külön tetszik. Közben kicsit alakítgattam a fenti kódot és nagyjából ugyanezt csináltam meg, csak nem jutott eszembe az attribute szó és optiont írtam helyette.
----
Sok éve, perlből próbáltam használni a SimpleXML-t, csak ellenkező irányban, parse-olásra, ha jól emlékszem. Végül kihagytam, mert valami hiányzott belőle, a teljes XML feldolgozó modult meg képtelen voltam megérteni.
Ennek van értelme, csak nem
pl vannak struktúrális részei az oldalnak: layout-ok, meg vannak olyanok is, amik a szerverrel kommunikálnak: form, link, stb... ilyen logika szerint kellene osztályokat létrehoznod...
Ez történt... Kb. két
Kb. két Div-ből és egy submit gombból áll a megjelenítendő lap. :-)
Egy DIV, amiben felsorolom az adatbázisban elérhető táblákat és egy másik, amiben az előbbi listából kiválasztott tábla oszlopainak attribútumait sorolom fel.
-------------------------
Azt viszont nem biztos, hogy a későbbiekben a nagyobb oldalakat képes leszek felbontani ennek megfelelően...
Azt viszont nem biztos, hogy
Az objektum-orientált HTML generálás olyan előnyökkel kecsegtetett, amelyek miatt mi is belevágtunk pár évvel ezelőtt. SimpleXML helyett mi kiterjesztett DOM osztályokat használtunk erre a célra. Két projektet csináltunk végig így, az egyiket épp most írom újra, hagyományos template engine használatával...
Szóval nem javaslom. Rengeteg olyan apró buktatóval találkoztunk menet közben, meg később a karbantartás során, amik miatt összességében nem érte meg.
Egy jó template engine még mindig a legjobb (legkevésbé rossz) megoldás.
Mik voltak a buktatói?
- A sitebuilder egy
- Rengeteg kódot kellett írni pár sor HTML generálásához, még úgy is, hogy kiterjesztettem a DOM osztályokat, és telepakoltam őket "convenience" metódusokkal, helpereket csináltam, stb.
- Egy HTML template struktúráját első ránézésre átlátod, az OO kódot nem igazán, még akkor sem, ha jól olvasható és dokumentált kódot írsz.
- Egy olyan módosítás ami egy HTML template esetén sima kivágás/beillesztés lenne az nálunk 25 perc kódolás/tesztelés volt.
- Elég sokat kínlódtunk a PHP verzió-specifikus DOM bugokkal és hiányosságokkal.
Az összes konkrét probléma ami adódott, nagyjából a fentiekre vezethető vissza.
Szóval menjek vissza oda,
Már amennyire az template-nek nevezhető, hogy néhány előre megírt HTML-t rántok be request-tel a PHP kód közepén...
Köszi a tippet.
Már amennyire az template-nek
Annak nevezhető. Ugyanis a legkifinomultabb template engine-ek is pontosan ugyanezt csinálják. Csak azok tudnak pár igen hasznos extra funkciót.
Akkor lehet, hogy nekem
(különböző blogmotorok template-jei alapján)
Én valami ilyesmit értek
3 éve
+1
Fárasztó vagy! :)
Nem feltétlenül rossz ezzel szórakozni, ha egy másodpercig sem gondolkodsz az éles használatán. Utóbbi esetben nagyon rossz ötlet.
Ahogy janoszen írta, ő már ellőtte ezt kb. 3 éve, és mivel volt "szerencsém" ezt élesben is látni, bizton állíthatom, hogy nem annyira nyerő. :) Szerintem űrlapokat lehet értelme egy formbuilder osztállyal építeni, ahogy janoszen is írta. Ez is főleg akkor praktikus szerintem, ha ez az osztály az ellenőrzést is megoldja.
Na jó, akkor töröltetem magam. :D
Egyébként is csak arra volt jó, hogy ezekről legalább el tudom képzelni, hogy objektumok, hogy lehetnek szülők, leszármazottak, működik az is, hogy a szülő helyére a gyereket írva azonos működést kapok, ilyesmi... szóval csak játék, mint az élet. :-)
Azért annyira nem súlyos a helyzet. :)
Bíztam benne, hogy smiley-val
Szóval template...
Pl.:
- Hagyjam így, csak arra figyeljek, hogy a template-ben megjelenítendő változó értéke mindig preprocesszált legyen? (tehát pl. egy htmlspecial_chars fv-n átküldve)
- Definiáljak egy konvertáló függvényt abban a .php-ben, amelyik minden egyes oldal letöltéskor elindul és echo helyett azt hívjam meg? (de akkor félre kell tennem, hogy tisztán OOP alapokra építem az oldalt)
- Felejtsem el a HTML-be írt PHP-t és a változók helyére tegyek valami placeholdert(ennek van magyar neve? :-) ), majd készítsek egy miniatűr template engine-t, ami kicseréli a a placeholdereket az odaillő változók biztonságossá konvertált értékére?
- Egyéb?
A harmadik tűnik használhatónak (feltéve, hogy nincs egy negyedik) még akkor is, ha most csak egy pici, egy-két lapból álló oldalt készítek.
Itt már érdemes lehet valami osztály-féleségben gondolkodni? (ha elkezdem alaposan objektumokra bontani a dolgot, akkor megint ott tartok, ahol e téma megnyitásakor: még a HTML tag-ek is egy-egy önálló objektumot képviselnének :-) )
Végeredményben csak végig kellene menni a beolvasott HTML-en és behelyettesíteni a változók értékét a megfelelő helyekre. Hm. Azért annyira ez sem triviális... Ha biztosra akarok menni, akkor valahol, a template-től független helyen kellene tárolni, hogy melyik változót kinek a helyére kell írni. Pl. {valt} a template-ben azt jelenti, hogy a $valt értékét kell beraknom. Ezt ugye megtehetném automatizálva is, a {...}-t $...-ra cserélve, de akkor bármi szemét kerül a template-be, az megjelenhet az oldalon is. (pl. a minta átszerkesztésével akár egy változóban tárolt jelszót is megjeleníthetne, amit ugye nem szeretnék - és ez megint jó példa rá, hogy mennyire el tudok tévedni az eredeti témától... hiszen itt csak én szerkeszthetem a template-et is :-) )
Hát nem egyszerű.
Template vagy sablon lényege
A lényeg, hogy egy űrlapelem önmagában nem csak megjelenítési, hanem nagymértékű működési logikát befolyásoló dolgot is magában hordoz. Nem mindegy az elem neve, id-je, és azt se a sablonban kell tudni, hogy hogyan kell az értéket kiíratni. Lásd select, checkbox stb., ahol egy új tulajdonságot kell hozzáadni az adott elemhez, vagy annak egy részéhez. (selected vagy checked)
Az meg már egy másik történet, hogy az elemet hogyan burkolod be, és hova teszed. Ez már tényleg a sablonba való.
pp
Ez így éhgyomorra kicsit
Azt látom, hogy amit hajnalban, hirtelen felindulásból írtam, az nagyjából hülyeség volt, mert egyik oldalról a lehető legprimitívebb, leggyorsabb megoldást keresem egy három szövegmezőből álló form megjelenítésére, másik oldalról egy a későbbiekben újra felhasználható programkezdeményt próbálok előállítani és a kettő együtt nem működik.
Jól értem? A sablon kb. addig tart, hogy adok egy keretet az oldalnak? Erősen elnagyolt példa: a html header+ néhány div, amelyekben meg akarom jeleníteni az egyes űrlapokat + a jelölések, hogy melyik div-ben milyen űrlapnak kell megjelenni, majd a megjelenítéskor ezeket a jelöléseket cserélem a program által előállított objektum html-lé konvertált kimenetére?
Tehát az eredeti elképzelésben szereplő placeholderek nem egy-egy változó értékét kellene, hogy jelezzék, hanem egy objektumét, ami képes html formában megjeleníteni a benne tárolt adatokat? Csak ezzel szép lassan visszajutok oda, ahonnan ez a téma indult: 1 html tag:1 objektum. Csak nem a teljes oldalon, hanem a template-ben jelölt helyeken.
----
Próbáltam nézegetni a drupal6 forrását, de ahhoz túl bonyolult volt, hogy félóra alatt felfogjam és az alapjait átültessem a saját környezetemre.
Nem fizikai, hanem logikai
Az az általános megoldás ami ugyan ugyanúgy kezeli a form elemeket mint az összes többi html elemet hibás.
Az a személete ami azt mondja, hogy minden ami html az sablon/template, szintén hibás.
A sablon az csak egy eszköz ami segíti a szétválasztást és nem fogja neked szétválasztani a működési és megjelenítési logikát. (Ha ilyet lehetne megszűnne a munkánk, hisz akkor nem kéne gondolkodó ember a programozáshoz.)
pp
Nézd, amikor én programozni
Ehhez képest ezek az elméleti "apróságok" számomra elég idegenek. Az MVC mintát talán kezdem felfogni, de az
már kilóg abból a körből, amit még értelmezni tudok.
Miben különböznek egy form elemei a többi html elemtől?
Amit én látok: ezekbe a user beleírhat valamit, azt elküldheti feldolgozásra. De ez nem a megjelenítést érinti, hanem az "utóéletét" a tagnek, de ott már csak a neve és a felhasználó által beleírt (vagy nem írt) tartalma a lényeges. Hogy ez épp egy HTML formból származik, az érdekel valakit? Amíg megjelenítem, addig miért ne kezelhetném ugyanúgy, mint a formon kívülieket?
Itt nekem valami kimarad(hatot)t.
Esetleg tudnád konkrét példával illusztrálni, hogy miért nem jó, ha egyformán kezelem őket?
Azt javaslom láss neki és
Tehát ha a megjelenítésnél - mint felesleges dolog - a name paraméterre nem figyelnek, hogy jó legyen akkor nem fogod tudni feldolgozni, hisz más néven jön vissza. Tehát ezt a paramétert nem bízhatod a nézetre, hogy az kedve szerint alakítgassa. Nem beszélve olyan elemekről, aminél a beleírt értéket (value) sem a júzer írja bele, hanem csak választja.
Mi van, ha nem üres beviteli elemeket küldesz ki, hanem olyanokat amikbe már van valami (szerkesztés) Mi van akkor, ha a felhasználó illegális adatot adott meg és ezt jelezni szeretnéd egy error class segítségével?
pp
Nekiláttam még tegnap
Ö... nem... ezt nem mondtam. Megjelenítésnél fontos minden paraméter. Feldolgozásnál már nem érdekel, hogy milyen betűtípussal, milyen színnel, milyen méretben jelent meg, de a neve és az értéke (nomeg a kívülről nem látható típusa, ami pl. az elfogadható értékeit korlátozza) igen.
De azt hiszem, tényleg az lesz, hogy most gondolkodás nélkül összecsapok valamit, felrakom valahova és majd annak kapcsán kérek némi segítséget
Dokumentum vs. alkalmazás
Ha alkalmazások esetén akarjuk UI-ként használni a HTML-t, akkor kezd problémás lenni a kérdéskör. Itt viszont azt hiszem nem lehet jó megoldást kitalálni. Meg kell vizsgálni, hogy az adott projectnél mik az elvárások most, mik lehetnek majd később és ez alapján döntést hozni. És vállalni, hogy a későbbiekben akár újra kell gondolni az egészet megközelítést és újraírni dolgokat.
És igen, egy blog, ahol szűrési lehetőség van, különböző megjelenítési módok, vagy ahol a felhasználó bevihet adatokat egy form segítségével az már alkalmazás, annak már semmi köze sincsen a dokumentumokhoz.
Nagyon jól látod a helyzetet.
Nem kötekedésképp, de tudsz
Csak eszembe jutott az a pár nap, amit a java swing-jével való ismerkedéssel töltöttem és úgy emlékszem, ott még zűrösebb egy UI-t összerakni, mint egy HTML+JS párossal kidekorált oldalon.
Próbáld ki a Flash Buildert.
Re
Írtam már párszor: szakítani kell teljes mértékben ezzel a dokumentum jellegű megközelítéssel. Ahogyan Hidvégi Gábor is írja, az alapnak egy júl struktúrált adathalmaznak kellene lennie, amit felhasználnak az egyes rendszerek. Egy RSS olvasó pl. megkapná a nyers adathalmazt és úgy jeleníti meg, ahogyan akarja.
Az internetet, jobban mondva a WEB-et hatalmas adatforrásnak kellene tekinteni, aminek ilyen-olyan megjelenítési formái vannak, de ez nem kötött, nem browser-hez kötött. A WEB, mint olyan a HTML, CSS, HTTP és browser megközelítéssel idejétmúlt; persze szerintem.
Kár erőfeszítéseket tenni arra, hogy jobbítsuk ami van, mert új alapok kellenek. Lehet ezt cáfolni, de nézzünk már szembe azzal a ténnyel, hogy mennyi szopás van napi szinten abból, hogy olyan közegben (technológia) akarunk interaktív dolgokat létrehozni, amit közel sem erre találtak ki. Ez gáz, az pedig még nagyobb gáz, hogy a Google, MS, Apple és hasonló nagy erők nem lépnek. Van ennek pénzügyi vetülete persze, de hol van a társadalmi szerepvállalás, az igazi innováció?!
Elég belegondolni abba, hogy felesleges energia a SEO. Ha puszta adathalmazt érnének el a keresők, akkor nem kellene olyan szintű SEO varázslat, hogy megmondjuk a keresőnek, hogy mi a navigáció és azt ne értelmezze tartalomnak. Neki csak adatok kellenek. Egy RSS olvasónak is, a felhasználónak szánt felületre kell nav megoldás.
Félreértesz, nem akarok én
Nem arra vonatkozott a kérésem, hogy "ne fikázd, ha nem tudsz jobbat", pusztán érdekelne, hogy a jelenlegi eszközök közt van-e olyan, ami szóba jöhetne szerinted/szerintetek utódként.
Re
De azt hiszem első körben fel kellene építeni a WEB alapját, az adatalapú elérést, majd ha ez már elég robosztus, akkor kellene azon elgondolkodni, hogy milyen formában legyenek megoldva a felületek, melyen megjelennek a tartalmak.
Azt hiszem nem egyfajta megjelenítési módban kellene gondolkodni, főleg nem browser megközelítésben (azaz el kell felejteni az oda vissza lapozgatást, mert ez a WEB dokumentum jellegéből fakad). Alkalmazáslogikában kell gondolkodni, interaktív felületekben.
Azt hiszem nem véletlenül írnak egyre többen natív iPhone alkalmazásokat weboldalak helyett. Aki látott már jól kidolgozott iOS app-ot, az tudja, hogy ég és föld a weblap és a natív alkalmazás élvezeti értéke között a különbség.
Tehát én úgy gondolom, hogy nem kell első körben a meglévő technológiákkal foglalkozni. Az alapokat kell lefektetni, megbeszélni, hogy mit is akarunk web alatt érteni és majd ebből következően beszélgetni a vizuális technológiákról. De csak azután, hogy készen van az tiszta adatelérési megoldás, melyet tetszőleges rendszer elérhet és feldolgozhatja a valós adathalmazt, ami az egész web alapját képezi.
Még mindig itt tartok...
A template feladata megmondani, hogy milyen mezőket akarok megjeleníteni rajta és az űrlapot kezelő osztálynak kell ehhez igazodnia? Vagy a template dolga csak annyi, hogy megmondja az űrlap feldolgozójának, hogy ha van x nevű eleme, azt hová tegye?
Nekem, mint a program írójának az lenne a könnyebb megoldás, ha a program döntené el, mit akar megjeleníteni. Kívülről nézve (szem előtt tartva, hogy jobb helyeken a felület kialakítása nem a programozó dolga), a site builderre kellene hagyni a mezők kiválasztását is. Igaz, ez kicsit messzire vezet. És itt elakadtam...
És mi a helyzet az egyes mezőkkel? OK, hogy a minden HTML tag egy objektum, nem nyerő. Ettől még a formok egyes input mezői lehetnek objektumok? Jó az, ha egy adott mező megjelenítéséről, ellenőrzéséről, esetleg feldolgozásáról egyetlen objektum gondoskodik? Ennek előnye, hogy egy mezővel csak egy helyen kell foglalkozni. Hátránya, hogy nem különítem el a megjelenítést és a feldolgozást.
Vagy legyen a mezőnek egy objektuma, ami megjeleníti a tartalmát és egy másik, ami a form elküldése után a feldolgozó programban jön létre, amivel gyakorlatilag felcserélem az előző megoldás előnyeit és hátrányait. (már amit én látok belőlük)
Van ezekre valami "megkötés"/előírás/szabvány/ajánlás/stb. ?
Kombinálni
Magyarán erre nem nagyon van
Én azt néztem, hogy a mezőket
A validáláshoz csak a modelre
Eddig eljutottam, de épp azon problémázok (bár már nem annyira :-)), hogy legyen feleslegesen ott az osztályban a nem használt opció is, vagy inkább szedjem szét két külön osztályra és egyik a model/control, a másik a view csoportba kerüljön.
De épp ma jutottam el arra a pontra, hogy a fene se fog egyelőre szabványokkal és ajánlásokkal foglalkozni, örüljek, ha már lesz valami működő programom, majd utána megnézem ebből a szempontból is.
kódszervezés
Én úgy csináltam (leegyszerűsítve), hogy van egy külön validator osztályom és egy külön formBuilder osztályom, mert nem rossz, ha a formBuilder nélkül is lehet adatokat ellenőrizni. Maga a formBuilder osztály meglehetősen rugalmas, többféle sablont, view-t is tud használni, gyakorlatilag a sablon - ha eltér az alaptól - külön is megadható neki. Valamint lehet +html-t hozzáfűzni az egyes mezőkhöz (pl. súgó tooltip-eket), de akár egyedileg is meg lehet jeleníteni a mezőket, ha a helyzet úgy kívánja.
Ami a sorrendet illeti, jól látod, először működjön, utána ráérsz csiszolni. Nem tudom ezek mennyire hasznosak a számodra, remélem azért valamennyire igen. :)