ugrás a tartalomhoz

Miért pont sablon ?

Vilmos · 2013. Okt. 22. (K), 09.17
tgr, pp
Drupal alap sablonnyelve a PHP ...

Köszönöm a pontosítást a drupállal kapcsolatban (hogyan ragozzák ezt helyesen?). A belinkelt hozzászólás furcsa a maga módján. A fejlesztők nem a karbantartást választották egy bejáratott elemnél, hanem dobták, és visszatértek az alapokhoz.

inf3rno
Nekem a sablonnyelvektől van ilyen érzésem, nem értem minek újra és újra feltalálni a kereket...

Nekem pont ellentétes a véleményem. Még nem találták fel a kereket. Azért van a sokféle próbálkozás. A kerék univerzális eszköz, nekünk nincs ilyen.

Azt hiszem, a sablonok interfésznek tekinthetők a szerver oldali program és böngésző között. Adattal való feltöltésükre készültek a sablonozó megoldások.
A Smarty, a saját nyelvet alkalmazók mintha zsákutcában járnának. Nem a futtatható nyelv a lényeg, ez elég jól látszik. Van ilyen, és akkor hogyan tovább?
Ami kell, az a böngészőnek megfelelő adatok összeállítása. Erre kétféle művelet elegendő. Sztring beillesztése egy kijelölt helyre, illetve "zárójelezett" tartalom duplikálása, iterálása. Például a Mustache és személyes kedvencem az xTemplate képességeiből elég mindössze ennyit használni. Aki ezt kitalálta, szerintem ráhibázott valamire.
‹ PHP verzióinak követése..? procedurálisból OOP ›
 ■
1

Sablonkerék

Hidvégi Gábor · 2013. Okt. 22. (K), 09.22
1999-ben találták fel, és úgy hívják, hogy XSLT. Bármi másnak a használata jelentős hátrányokkal jár ehhez képest.
2

Az egész sablonozás mizéria

inf · 2013. Okt. 22. (K), 10.19
Az egész sablonozás mizéria azért van, mert egyik nyelvből: php akarjuk szerkeszteni egy másik nyelv kódját: html. Erre a problémára kisebb kódrészletnél, mint mondjuk az sql templateknél elég annyi, hogy megadjuk a sablont, a paramétereket, meg az egyes paraméterekre vonatkozó plusz információkat. Nagyobb kódrészletnél már bejönnek a vezérlő szerkezetek, mint foreach, if-else, switch, stb... Ha ezt is sablonosan akarjuk megadni, akkor innentől elkezdünk egy teljesen új nyelvet gyártani, és egy csomó felesleges munkát beleölünk valami olyan dologba, amit már a php 1.0 is tudott...

Amit én szoktam, az az, hogy csinálok osztályokat az ismétlődő komponenseknek, és azokat használom. Ezekben lehet sablon vagy dom fa építés vagy string összefűzés, teljesen mindegy. A lényeg, hogy a nagyobb struktúrák építésénél van rá automatikus kódkiegészítés szemben a sablonnyelvekkel, amikhez nincs, vagy - ha egy sablonnyelv nagyon elterjedt - akkor talán részleges van.

Ha a kliens és a szerver oldalon is ugyanazokat a sablonokat akarjuk használni, akkor H. Gábornak igaza van abban, hogy az XML generálás és az XSLT a legjobb megoldás, mert az már egy kész szabványos sablonnyelv, nem kell újat csinálni. Annyi extra dolog van vele, hogy valamivel lassabb lehet, attól függően, hogy van e opcode cache, vagy nincs. Ennek most nem fogok utánakeresni, úgy rémlik, hogy valami van hozzá. Ha az XSLT nem kielégítő sebességben, akkor lehet elgondolkodni azon, hogy valami olyan sablont használjunk, ami szintén megy szerver és kliens oldalon is. Ez az esetek töredékében áll fenn, ehhez képest mindenki külön sablonozó rendszert használ, vagy akar írni teljesen indokolatlanul...
3

xsl cache

Hidvégi Gábor · 2013. Okt. 22. (K), 10.28
PHP-hoz a PECL XSL cache kiterjesztés a munkamenetben tárolja az adott stíluslapot, így nem kell újra feldolgozni minden kérésnél. Állandóan memóriában csücsülő nyelveknél (Java) pedig, gondolom, nincs ilyen probléma.
5

A php oldala a dolognak nem

inf · 2013. Okt. 22. (K), 10.46
A php oldala a dolognak nem feltétlen releváns, azt statikus cache-el is tehermentesíteni lehet. A kliens oldalon lehetnek sebességgel kapcsolatos gondok első futásra szerintem. Valszeg ott is van xsl opcode cache, passz.
24

Utánanézek

Vilmos · 2013. Okt. 22. (K), 12.52
Utánanézek az XSL témának, ha ez a javaslatod. Az előbbi link valami CVS tárhelyre mutat, 6 évvel ezelőtti utolsó módosítással. Sűrűn jönnek az "internel error" üzenetek. Valami gond lehet ott.
25

Ha az XSL cache-re utalsz,

Hidvégi Gábor · 2013. Okt. 22. (K), 13.07
Ha az XSL cache-re utalsz, nem tudom, nálad mi lehet a gond, nekem működik. De ez nem fontos ahhoz, hogy kipróbáld, ez csak egy nyalánkság.

Azt tudom tanácsolni, hogy próbáld ki az összes, ezen az oldalon a többiek által javasolt megoldásokat is, hogy lásd, melyikkel mit és hogyan (nem) lehet megvalósítani. Ezek után a saját elképzeléseidnek és igényeidnek megfelelőt válaszd ki, mert bár a magam részéről meg vagyok győződve, hogy az XSLT a legjobb, de vannak olyan helyzetek, ahol nincs szükség (ilyen szintű) sablonozásra.
33

Találtam jegyzetet

Vilmos · 2013. Okt. 22. (K), 14.29
Pontosítok. Nem maga a link hibás, hanem ami a "Homepage" után szerepel.

Találtam magyarázó példákat. El tudom képzelni, egyszerűbb esetben mire képes. Magas szinten kétségbeejtő. Változó kezelés, feltétel, ciklus ...
Szóval egy speciális nyelv. Valami programozás szerű utasítás készlettel. Persze, ha redukálom a szintet, akkor még felérem ésszel.

Ezzel kapcsolatban. Ha web lapot terveztetsz, akkor a szokásos menet (azt hiszem) az, hogy a dizájn tervet átalakítják statikus html oldalakra, majd ebből indulnak neki a programozásnak. Eltekintve attól, hogy lehet másképp, meg esetleg elavult, és így tovább, azért még előfordul ilyesmi. A kérdés az, hogy bármelyik ponton akad-e eszköz ami átalakítja a kész kódot vagy tervet xslt sablonra? Mert ha nem, akkor az elég szép kézi munkát jelent.
(Az xml-t mint adatot programmal kell előállítani, ez tiszta.)
4

Ha a kliens és a szerver

Hidvégi Gábor · 2013. Okt. 22. (K), 10.33
Ha a kliens és a szerver oldalon is ugyanazokat a sablonokat akarjuk használni
Miért kéne külön sablonokat használni kliens- és szerveroldalon? Kétszer annyi munka, kétszer annyi hibalehetőség - ugyanannyi pénzért. Őrültség.
7

ja.

inf · 2013. Okt. 22. (K), 10.49
ja.
15

Programoztatok ti már valaha

tgr · 2013. Okt. 22. (K), 11.30
Programoztatok ti már valaha XSLT-ben? Se nem igazán procedurális, se nem igazán deklaratív, olvashatatlanabb, mint a HTML fájlba ágyazott PHP kód, nincs hozzá normális IDE támogatás, a fél kezemet lerágni kevésbé fájdalmas tevékenység.
17

Igen. Funkcionális.

Hidvégi Gábor · 2013. Okt. 22. (K), 11.38
Igen. Funkcionális. Szubjektív. Találtam/írtam magamnak. Inkább dolgozom egyszer, mint kétszer.
29

Az, hogy az XSLT

tgr · 2013. Okt. 22. (K), 13.54
Az, hogy az XSLT funkcionális, azért túlzás.
31

Teljesen mindegy, minek

Hidvégi Gábor · 2013. Okt. 22. (K), 14.22
Teljesen mindegy, minek hívjuk. Eddig minden feladatot meg tudtam vele oldani egyszerűen, bár vannak dolgok, amit másképp kell, mint ahogy azt megszoktuk.
26

Én igen, meg lehet szokni. Az

inf · 2013. Okt. 22. (K), 13.09
Én igen, meg lehet szokni. Az egyedüli gondom a debuggolással volt. Ha jól nézem phpstorm-hoz van alapból xslt language support, úgyhogy a syntax error részt az megoldja. Ha egyszerűek a sablonok, akkor valszeg más típusú hiba nem igazán fordulhat elő benne.
28

IDE támogatást XSLT-hez

tgr · 2013. Okt. 22. (K), 13.53
IDE támogatást XSLT-hez nagyjából addig a szintig kapsz, hogy jelzi a szintaktikai hibákat, meg kódkiegészít, de mondjuk refaktorálás, dokumentáció, debugging/REPL nincs (nem is nagyon lehetséges). Ha egyszerűek a sablonok, akkor pl. Mustache-sal megkapod az XSLT összes előnyét annak az hátránya nélkül, ha bonyolultak, akkor meg vért fogsz izzadni, mire XSLT-ben megcsinálsz valamit, ami egy procedurális jellegű sablonnyelvben egyszerű és rögtön átlátható. (Eleve ha elég bonyolult a kimenet, akkor már az XML generálás sem lesz átlátható valamilyen sablonozás nélkül, szóval weboldal generálásánál az XML transzformáció egy teljesen oda nem illő dolog.)
30

Én szeretnék konkrét példákat

inf · 2013. Okt. 22. (K), 13.57
Én szeretnék konkrét példákat látni, mondjuk te írsz valamit bajuszban, Gábor meg xslt-ben. :D Hogy lehet ilyen nevet adni egy nyelvnek?! :D

Szerinted mi a hátránya az XSLT-nek?
36

Az XSLT-t arra találták ki,

tgr · 2013. Okt. 22. (K), 15.14
Az XSLT-t arra találták ki, hogy XML dokumentumokat más XML dokumentumokká transzformáljon, egy weboldalnál pedig sem a forrás, sem a cél nem XML. Egyszerűen más a problématartomány: az XSLT arra jó, hogy nagy és komplex, de egy jóldefiniált sémát követő, jól strukturált adatszerkezetet átírjon egy másik nagy és komplex, de jóldefiniált adatszerkezetre; ezzel szemben a webfejlesztésben mindkét oldal aluldefiniált és folyamatosan változik, egyiknek sincs semmilyen állandó formális struktúrája, viszont nem is különösebben bonyolultak. Az XSLT mintaillesztéseken alapul, amik jól párhuzamosíthatóak és rosszul modularizálhatóak; egy weboldalnál az előbbi felesleges, az utóbbi viszont fontos lenne.
37

<xsl:output method="html"

Hidvégi Gábor · 2013. Okt. 22. (K), 15.51
<xsl:output method="html" version="1.0" />

az XSLT arra jó, hogy nagy és komplex
Nincs a szabványba vésve, hogy kis és egyszerű adatszerkezetekre nem lehet használni.

a webfejlesztésben mindkét oldal aluldefiniált és folyamatosan változik, egyiknek sincs semmilyen állandó formális struktúrája
Sokmindennek van állandó struktúrája, például objektumokat le lehet írni tulajdonságokkal. Ezt jelenleg nem tesszük meg HTML-ben (bár volna rá lehetőség), de egy XML+XSLT alapú weben ez magától értetődő volna. Emiatt rendkívül sokat veszítünk, a szöveg alapú keresőkön keresztül a HTML korlátai miatt az internetnek csak rendkívül kis szeletét tudjuk elérni.

Az internet fejlődésének legnagyobb akadálya a HTML, valamint kézenfogva a keresők.
38

Egy xml->html

inf · 2013. Okt. 22. (K), 16.12
Egy xml->html transzformációnál elég jól tudom, hogy milyen szerkezetű az xml, amit transzformálok, és milyen html-t várok cserébe. Ha változik a várt html, akkor belenyúlok az xslt-be. Ha változik az xml szerkezete, akkor szintén. De ezek ugyanúgy igazak bármilyen más adat->html transzformációra.

Én nem olvastam soha olyat xslt-ről, hogy csak nagy és komplex adatszerkezetekre lehet használni. Olyat sem olvastam, hogy csak xml->xml transzformációkra lehetne használni. Tudnál ezekről valami referenciát adni?
43

Nyilván lehet a hidraulikus

tgr · 2013. Okt. 22. (K), 20.43
Nyilván lehet a hidraulikus emelővel is szöget beverni, csak nem költséghatékony, és a szög se biztos, hogy úgy lesz a legszebben beverve.

Az XSLT specnek egyébként mindjárt az első mondata az, hogy XSLT ... is a language for transforming XML documents into other XML documents. (Persze akkoriban még a W3C-nél úgy gondolták, hogy a HTML majd egy speciális XML-dialektussá válik idővel, ezzel azóta elég látványos kudarcot vallottak.)
44

Ez van. :-) Én mondjuk az

inf · 2013. Okt. 22. (K), 22.45
Ez van. :-)
Én mondjuk az egész sablonozást nem tartom egy jó dolognak, de ez már tényleg ízlés kérdése... Nálam akkor van helyén a dolog, ha van egy MyGUIComponent osztályom ahelyett, hogy egy my-gui-component.tpl fájlom lenne. Nem tudom, hogy ez kóros e, de így szeretem :D A konfig fájloknak sem látom sok értelmét, minek valamit kitenni adat formátumba, amit utána nem akarok programmal szerkeszteni, hanem kézzel nyúlok bele?!
53

Nahát

Pepita · 2013. Okt. 23. (Sze), 20.19
Fentebb írtad:
egy csomó felesleges munkát beleölünk valami olyan dologba, amit már a php 1.0 is tudott...
Most pedig:
Én mondjuk az egész sablonozást nem tartom egy jó dolognak
Nem egészen értem. A PHP maga a sablonozó nyelved, mint itt is: application/views/templates/desktop.php. Később, a kontroller-osztályunk megfelelő helyén ott a fv., amivel az adatok birtokában, az egyes template-ekkel legyártjuk a résztartalmakat, és ezek egyben mehetnek a view-nak.
Mi ezzel a baj?

A konfig fájloknak sem látom sok értelmét, minek valamit kitenni adat formátumba, amit utána nem akarok programmal szerkeszteni, hanem kézzel nyúlok bele?!
Hát hova teszed máshova azt, amit egyszerűen, gyorsan akarsz elérni (futásidőben), ritkán kell módosítani és sokszor felhasználod?
- Azt, hogy te mindig beégeted a kódba - nevetséges lenne elhinnem. Nyilván nem írod le 100szor u.azt, aminek 200szor is egyformának kell lennie.
- Ezért külön osztályokat deklarálni, vagy mindegyik osztályba tenni a saját configját: magad szívatása, mert egyrészt ha mégis módosítani kell, nehezebben találod meg, másrészt kizártad a lehetőségét, hogy máshonnan is felhasználd ugyanazt az adatot, legalábbis egyszerűen, közvetlenül (pl. view réteg!) biztosan nem.

Itt ebben nem tudok egyet érteni, nekem ált. 3-6 config fájlom van, funkcionalitás szerint. Nyilván view-ból nem fogom betölteni a database configját, de a site-ét (szintén l. cikkem) alapból (sitename, telefon, cím, stb.). Szerintem ez a legkényelmesebb megoldás, nem értem, te miért nem így látod.
56

Több lehetőség is van, az

inf · 2013. Okt. 24. (Cs), 00.11
Több lehetőség is van, az egyik, hogy dependency injection container-ben tárolom ezeket az információkat, a másik, hogy a d.i.c.-be is beinjektálom valahonnan. Tipikusan ezt úgy szokták megoldani, hogy csinálnak egy vagy több config fájlt, azt beparsolják, aztán abból injektálnak be mindent. Én úgy gondolom, hogy megspórolom a parsolást, és inkább php-ben adom meg a beállításokat. Amúgy az elv teljesen ugyanaz. Szóval technikailag mondhatjuk, hogy én is config fájlokat használok, csak azokat php-ben írom, és nem valami adattároló formátumban.
59

Egyet teszünk :)

Pepita · 2013. Okt. 24. (Cs), 00.48
Végülis az én configjaim is php-k, helyből változók (tömbök általában).
Annyi, hogy arra már én figyelek (illetve részben a fw), hogy melyiket hova töltöm be. A kis darabszám miatt nem húzom egybe, illetve a hozzáférés miatt sem. (pl. a database configot egyetlen osztály használja)
60

Hát én szeretem a

inf · 2013. Okt. 24. (Cs), 03.18
Hát én szeretem a bootstrap-ben betölteni az egészet, aztán dependency injection containereknek átadni, amik beteszik a megfelelő helyre azt, ami éppen kell. Így a legrugalmasabb...
80

Több IO

Pepita · 2013. Okt. 25. (P), 03.31
Valószínűleg így több fájlműveletet végzel és több RAM-ot eszel, mint én.
Bár ez csak az én vesszőparipám, már tgr-el és / vagy pp-vel kitárgyaltuk, hogy ezzel csak akkor kell foglalkozni, ha lassú miatta valami (és igaz is).
Nekem viszont "születési hibám" az erőforrás-spórolás. És még erre rá: PHP-ben egy csomószor csak hiszem, hogy spóroltam, nem ismerem hozzá eléggé a fordító lelkét... :)
84

A fájlműveletek opcode

inf · 2013. Okt. 25. (P), 11.14
A fájlműveletek opcode cache-el kivonhatóak a forgalomból. A memória fogyasztás nem hiszem, hogy valami magas lenne egy php kód esetében, a kicsinél kicsit több meg nem sokat számít, bár ehhez én sem értek...
54

Nekem így látatlanban azért

tgr · 2013. Okt. 23. (Sze), 21.53
Nekem így látatlanban azért vannak kétségeim, hogy a procedurális kódból történő fagenerálás mennyire könnyen/gyorsan látható át, ha többen dolgoztok egy projekten, vagy régi kódodat veszed elő; meg hogy mennyire fájdalmas refaktorálni.

Konfigfájban én is PHP-barát vagyok, de azért vannak speciális esetek, amikor valami más előnyösebb, pl. ha tömböket kéne egymásba halmozni, akkor egy YAML sokkal olvashatóbb, vagy ha nagyon szigorú formátuma van, akkor egy DTD-vel ellátott XML-re automatikus ellenőrzést és kódkiegészítést kapsz.
55

Én a nagyját deklaratívan,

Joó Ádám · 2013. Okt. 23. (Sze), 22.00
Én a nagyját deklaratívan, egymásba ágyazott konstruktorhívásokkal generálom, aztán ezt bővítem mondjuk ciklusban. Még a Java szószátyár szintakszisával is elég jól átlátható a kód, egy tömörebb nyelvben főleg.
57

Erre tudnál egy rövid példát

inf · 2013. Okt. 24. (Cs), 00.13
Erre tudnál egy rövid példát mutatni? Érdekelne.
58

new Element("html", new

Joó Ádám · 2013. Okt. 24. (Cs), 00.29
new Element("html", new Attribute("xmlns", "http://www.w3.org/1999/xhtml"), new Node[] {
    new Element("head", new Node[] {
        new Element("title", "Nem található"),
        
        new Element("link", new Attribute[] {
            new Attribute("rel", "icon"),
            new Attribute("href", "/favicon.ico"),
        }),
        
        new Element("link", new Attribute[] {
            new Attribute("rel", "stylesheet"),
            new Attribute("href", "/style.css"),
        }),
    }),
    
    new Element("body", new Node[] {
        new Element("h1", "Nem található"),
        
        new Element("p", new Node[] {
            new Text("A kért címen nem található tartalom. Ha hibára gyanakszol, "),
            new Element("a", new Attribute("href", "/kapcsolat"), "vedd fel velünk a kapcsolatot"),
            new Text("."),
        }),
    }),
})
61

Valahogy én is így csináltam

inf · 2013. Okt. 24. (Cs), 03.25
Valahogy én is így csináltam régebben, de mostanában jobban tetszik a laconic szintaxisa. Ugyanúgy van rá kódkiegészítés, és sokkal tömörebb:

$el->html(array('xmlns' => 'http://www.w3.org/1999/xhtml'),
	$el->head(
		$el->link(array('rel' => 'icon', 'href' => '/favicon.ico')),
		$el->link(array('rel' => 'stylesheet', 'href' => '/style.css'))
	),
	$el->body(
		$el->h1('Nem található'),
		$el->p(
			'A kért címen nem található tartalom. Ha hibára gyanakszol, ',
			$el->a(array('href' => '/kapcsolat'), 'vedd fel velünk a kapcsolatot'),
			'.'
		)
	)
)
Azonnali html generálásra jó. Az objektumos megadásnak annyi előnye van ezzel szemben, hogy annál később bármikor bele lehet nyúlni bármelyik objektumba, és nem muszáj egyből kirajzolni... Én a kettőt szoktam kombinálni, a nagyobb egységeket objektumos formában adom meg, és azokon belül használom a laconic stílusú azonnali html generálást akkor, amikor a kirajzolásra kerül a sor. Ugyanezt meg lehetne csinálni sablonokkal is, csak azokat nem szeretem, mert ki kell őket tenni külön fájlokba, úgy meg nem lesz kódkiegészítés hozzájuk, és elveszti az ember a kontrollt a kód felett...

A nagyobb view-okat a vezérlő szerkezetek mentén szét szoktam vágni külön metódusokra, osztályokra mérettől függően. Itt is ugyanúgy darabolható a kód attól függően, hogy mit csinál, mint business logic-nál... Sablonok esetében gondolom minden külön fájlokba menne, és azokat szúrkálná be a rendszer. Egy méret felett gondolom belefulladnak az emberek ebbe a fájl tengerbe...
64

Pont egy hasonló szintaxisú

MadBence · 2013. Okt. 24. (Cs), 11.31
Pont egy hasonló szintaxisú dologban gondolkodok JavaScript alapokon, amit le is lehet fordítani. Ha olyan stádiumba ér, akkor írok róla, szerintem sokaknak tetszeni fog :)
65

Az amit le is lehet fordítani

inf · 2013. Okt. 24. (Cs), 13.23
Az
amit le is lehet fordítani
rész alatt mit értesz?
66

Az eredménye egy függvény,

MadBence · 2013. Okt. 24. (Cs), 13.54
Az eredménye egy függvény, ami egyszerű string összefűzéseket használ, egyszerű változóbehelyettesítéssel. Tehát renderelésnél (amikor változók értéket kapnak) nem kell végigmenni egy bonyolult fán (természetesen nem kötelező lefordítani).
Így kell elképzelni:
function _compiled(data) {
  return '<html><head><title>' + data.title + '</title>....</html>';
}
67

Ez kétféleképp valósítható

inf · 2013. Okt. 24. (Cs), 14.10
Ez kétféleképp valósítható meg.

Az egyik, hogy
$.el('title', data.title)
helyett
$.el('title', new Param('data.title'))
van a kódban. Viszont ez megbontja a kód tömörségét...

A másik, hogy marad a régi kód, és csinálsz egy js parsert, ami megtalálja a paraméter átadásokat. Végülis csak data.*-ra kell keresni hozzá... Ez gyakorlatilag meg már maga a sablonozás, csak itt javascriptet használsz sablon nyelvnek, és azt fordítod át szintén javascript-re.

Szerintem nincs értelme átfordítani sablonra, egyszerűen az erőfeszítés nincs arányban azzal, amit ténylegesen hoz. Mit vársz ettől az egésztől, miben lesz jobb?
68

Az első változattal is

MadBence · 2013. Okt. 24. (Cs), 14.16
Az első változattal (a rövid formával) is megoldható az említett funkcionalitás :) (mindenféle string parsolás nélkül)
69

Hogyan?

inf · 2013. Okt. 24. (Cs), 14.29
Hogyan?

Szerintem vagy objektumként adod meg, amit ki akarsz rajzolni, vagy sablonban. Ha programkóddal adod meg, azt csak parserrel tudod átalakítani sablonra, máshogy nem megy. De hallgatlak...
70

:-)

MadBence · 2013. Okt. 24. (Cs), 15.13
Amit el kell érni, az az, hogy a data.title (vagy tetszőleges attribútum) a fa felépítésekor ne értékelődjön ki (illetve konkrét érték ne helyettesítődjön be). Erre a legegyszerűbb megoldás ha lusta kiértékelést használunk (azaz a data.title egy függvény). A nehezebb része az, hogy nem ismerjük, mely attribútumokra lesz szükség. A megoldás erre a Proxy, ami már támogatott pl node-ban. A böngészők támogatása most nem releváns, hiszen ők csak egy lefordított kódot kapnak.
71

Ez kb megfelel az első

inf · 2013. Okt. 24. (Cs), 15.46
Ez kb megfelel az első példában írtaknak. Ha van rá speciális nyelvi elem, akkor valószínűleg könnyebb megoldani, de még úgy is nehéz. Az a gond, hogy sokszor van, hogy már létező függvényeknek adod át a paramétert, és ők nem függvényt várnak, ami adatot ad nekik, hanem magát az adatot... Szóval az összes paraméter formázó függvényt meg kell írni ilyenre. Talán az is megoldás lehetne, ha a formázó függvények aszinkron futnának le. Végső soron szerintem mindenképp szükség lesz arra, hogy regisztráljunk minden egyes hívott függvényt ugyanúgy, mint a sablonoknál.

Btw a Proxy-ra mutató linked eltört.
72

http://wiki.ecmascript.org/do

MadBence · 2013. Okt. 24. (Cs), 16.14
http://wiki.ecmascript.org/doku.php?id=harmony:proxies, buta BBCode...

Szóval az összes paraméter formázó függvényt meg kell írni ilyenre.


Elég egyet, ami becsomagolja a formázó függvényeket, de igen, ez valóban egy kényelmetlenség... Mondjuk a sablonban nem nagyon kellene már adatot manipulálni: behelyettesítés+pár alapvető vezérlési szerkezeten kívül másra nincs nagyon szükség.
76

Vicces, félig-meddig

Joó Ádám · 2013. Okt. 24. (Cs), 17.17
Vicces, félig-meddig megvalósítottam ezt úgy egy hónapja a sajátomhoz. De aztán félretettem, mert nem volt minden kérdés egyértelműen tisztázva.
73

Ennek milyen előnye lenne a

Hidvégi Gábor · 2013. Okt. 24. (Cs), 16.27
Ennek milyen előnye lenne a hasonló megoldásokhoz képest?
74

Lásd 66:Tehát renderelésnél

MadBence · 2013. Okt. 24. (Cs), 16.50
Lásd 66:
Tehát renderelésnél (amikor változók értéket kapnak) nem kell végigmenni egy bonyolult fán

Ennek többek között teljesítménykövetkezményei is vannak, de pl tömörebb kódot is eredményez (hiszen a lefordított sablonhoz nem kell mellékelni a sablont lefordító kódot). Sőt, ha bizonyos változókat fordítási időben lekötünk, akkor még optimálisabb kódot kaphat a kliens:
function _compiled(data) {
  return 'foo' + (data.bar ? 'baz' : 'qux');
}
Ha pl fordításkor ismert a bar értéke (mondjuk true), akkor a kliens csak a releváns ágakból generált kódot kapja meg:
function _compiled(data) {
  return 'foobaz';
}
78

Javascriptben with-tel lehet

tgr · 2013. Okt. 25. (P), 00.55
Javascriptben with-tel lehet erre nagyon elegáns (egyben kicsit ijesztő) szintaxist csinálni.
79

Igen, a with is része a

MadBence · 2013. Okt. 25. (P), 01.10
Igen, a with is része a cuccnak :-) (illetve az már csak csinosítás)
81

Nem is olyan ilyesztő

Pepita · 2013. Okt. 25. (P), 03.39
Hasonlít a Delphi-s with-hez, nekem baráti, de mitől kéne ijesztőnek lennie?
83

Nem egyértelmű

Endyl · 2013. Okt. 25. (P), 10.07
Ha nem ismered a teljes rendszert és a with működését száz százalékig, akkor érhetnek meglepetések. Crockford bácsi elmagyarázza miért is.
86

Nem sok

Pepita · 2013. Okt. 26. (Szo), 08.07
Annyi a különbség, hogy Delphiben kizárólag deklarált változón tudod használni. Js-ben meg eldöntöd, és tartod magad hozzá. Nem?
88

Mit döntök el? Mihez tartom

Endyl · 2013. Okt. 26. (Szo), 09.32
Mit döntök el? Mihez tartom magam?
90

Nem ajánlja, de használható:

Pepita · 2013. Okt. 26. (Szo), 10.02
Nem ajánlja, de használható:
with (ooo.eee.oo.ah_ah.ting.tang.walla.walla) {
    bing = true;
    bang = true;
}
Ajánlja:
var o = ooo.eee.oo.ah_ah.ting.tang.walla.walla;
o.bing = true;
o.bang = true;
A kettő nem zárja ki egymást, tehát igazán akkor vagy bajban, ha mindkettőt használod ugyanarra. Delphiben egy-egy objektum-példányra lehet használni a with-et (és asszem Javaban is van megfelelője), tehát a tévedés kizárva.

Azt nem egészen értem, hogy elsőt miért nem ajánlja, ha jó kódkiegészítésed van, akkor létező objektum / tulajdonság lesz benne, és ha nem létezik ezen belül "bing-bang", akkor létrehozza. Lehet, hogy én tudok túl keveset angolul, de úgy tűnik, ennyi a gondja vele, hogy van-e olyan objektum, hogy ooo.eee.oo.ah_ah.ting.tang.walla.walla.

Ezt nem értem tisztán:
Will ooo.eee.oo.ah_ah.ting.tang.walla.walla be modified? Or will the global variables bing and bang get clobbered? It is impossible to know for sure.
Miért ne tudnánk biztosan, hogy módosítva lett?
91

Az a baj a with-del, hogy ha

Endyl · 2013. Okt. 26. (Szo), 11.17
Az a baj a with-del, hogy ha ooo.eee.oo.ah_ah.ting.tang.walla.walla-nak nincs bing vagy bang tulajdonsága, akkor az a with esetében nem is jön létre, hanem a globális névtérben hozza létre vagy módosítja (esetleg olvassa) ezeket a változókat. Így csak a with blokkot nézve nem egyértelmű, hogy mely változók/tulajdonságok lesznek használva. Ezzel szemben a

var o = ooo.eee.oo.ah_ah.ting.tang.walla.walla;  
o.bing = true;  
o.bang = true;
esetében nincs semmi kétség, hogy melyik hozzárendelés mire vonatkozik.

Lentebb a hozzászólások között írja:
The point is not that -with- is useless. The point is that it is, unfortunately, dangerous. And that it is, fortunately, unnecessary. Features that are both dangerous and unnecessary should not* to be used at all.


* a not-ot én javítottam bele, mert csak így értelmes a mondat; minden bizonnyal elírás volt a hiánya.

Tehát nem az a baj, hogy ne lenne haszna a with-nek, hanem hogy nem egyértelmű -így veszélyes a használata- és mivel van ugyanolyan jó alternatívája, így felesleges veszélyforrás.
92

Igen, sajnos alapból el van

bamegakapa · 2013. Okt. 26. (Szo), 11.42
Igen, sajnos alapból el van törve. Olyan hibákat tud okozni a használata, amit aztán napokig keresel :).
93

Ez furcsa

Pepita · 2013. Okt. 26. (Szo), 11.58
Tehát ha nincs bang property, akkor lesz helyette egy var bang = true, az ooo.eee.oo.ah_ah.ting.tang.walla.walla nélkül?! Ez elég botrányos, mondjuk eddig nem is vettem észre, hogy js-ben is van with - hála Istennek. :)
Köszönöm a pontosítást.
94

Ha még var bang = true;

bamegakapa · 2013. Okt. 26. (Szo), 12.13
Ha még var bang = true; lenne... de ráadásul bang = true;, tehát a globális névteret szennyezi.

Valószínűleg ezért nem is találkoztál vele, senki nem reklámozza, hogy létezik, mivel jobb lenne, ha senki nem használná :).
95

A mindenit

Pepita · 2013. Okt. 26. (Szo), 12.28
Hát ennek így rohadtul semmi értelme... Durva, és ez így van x éve. Ezért nem (sem) szeretem a js-t. Mindig érnek rondábbnál rondább meglepetések, nem egy épületes nyelv.
96

Egyértelműen tervezési hiba -

bamegakapa · 2013. Okt. 26. (Szo), 13.46
Egyértelműen tervezési hiba - sajnos az ilyeneken látszik, hogy nem volt sok idejük rendesen megtervezni a nyelv bizonyos részleteit.

A nyelv fő felhasználási területéből eredően pedig gondolom nehéz megváltoztatni egy nyelvi elem működését, a visszafelé kompatibilitás miatt.

Sajnos sok az ilyen hordalék a Javascriptben - Crockford bácsi jól összeszedte őket a Javascript: The Good Parts c. könyve A és B függelékében. Ő egy olyan Javascript subset használatát javasolja mindenkinek, amiből ezek (legalábbis a fejünkben) hiányoznak, így jobb kódot lehet írni.
97

Javascript: The Good Parts

Hidvégi Gábor · 2013. Okt. 26. (Szo), 15.23
101

Hehe, a mobilos topikban

bamegakapa · 2013. Okt. 26. (Szo), 15.48
Hehe, a mobilos topikban linkelt cikkből. Remek kép :).

Én egyébként kedvelem a Javascriptet és a sajátos nézőpontját. Ha nem lenne ilyen összecsapottan bebetonozva, még jobb lenne :).
106

Én is szeretek JS-ben

Hidvégi Gábor · 2013. Okt. 26. (Szo), 18.35
Én is szeretek JS-ben dolgozni; ha a node.js-ben elfelejtenék ezt az event driven, aszinkron dolgot, abban a pillanatban térnék át rá php-ról.
107

Lehet hasonló szinkron

inf · 2013. Okt. 26. (Szo), 19.03
Lehet hasonló szinkron koncepciót írni benne, mint ami php-ben van, semmi akadálya nincsen. Adatbázishoz kell szinkron illesztő, meg meg kell írni egy http szervert is, hogy alatta mehessenek a dolgok szinkronban. Ezzel kapásból minden előnye el is tűnne a nodejs-nek a php-val szemben.
99

Ki tudja?

Pepita · 2013. Okt. 26. (Szo), 15.38
gondolom nehéz megváltoztatni egy nyelvi elem működését, a visszafelé kompatibilitás miatt.
Ha egyszer gyakorlatilag használhatatlan, egy szabványmódosítás és kész. Más kérdés, a W3C "átviteli sebessége" és az ebből eredő gyártók tesznek a szabványra - visszatér a régi nóta...
Asszem ehhez mi kicsik vagyunk, legfeljebb leírjuk a véleményünk, mások meg elolvassák, de érdemi fejlődés nem várható - sajnos.
109

Ugye tudod, hogy a JavaScript

Joó Ádám · 2013. Okt. 27. (V), 03.25
Ugye tudod, hogy a JavaScript nyelv nem a W3C kompetenciája? Használd többet a keresőt!

Ami a „szabványmódosítás és kész” részt illeti, ez így sosem szokott megtörténni. A szabványokat szinte kizárólag bővítik.
111

Bizonyos értelemben már meg

tgr · 2013. Okt. 27. (V), 11.05
Bizonyos értelemben már meg is történt, strict módban nincs with.
112

A strict mód egy hack, teljes

Joó Ádám · 2013. Okt. 27. (V), 13.28
A strict mód egy hack, teljes mértékben visszafele kompatibilis.
114

Akkor kompatibilis

tgr · 2013. Okt. 27. (V), 21.00
Akkor kompatibilis visszafelé, ha nem használod. Ezt azért bármelyik programnyelv új verziójáról el lehet mondani.
115

A régi kódok fognak futni a

Joó Ádám · 2013. Okt. 27. (V), 22.28
A régi kódok fognak futni a strict módot ismerő motorokban is, mert nincs kinn a deklaráció. Ez a nyelv bővítése, nem szűkítése.
116

Pardon

Pepita · 2013. Okt. 28. (H), 08.33
Js-ből eléggé "korrepetálásra szorulok", tudom, nem is szeressem.
Ugye tudod, hogy a JavaScript nyelv nem a W3C kompetenciája?
Nem, nem tudtam. Hanem? Néha Mozzillát szoktam lesni (régebben), de gondolom nem ők a kompetensek hivatalosan. Vagy igen? Tényleg nem tudom, akármilyen szégyen. :)
A szabványokat szinte kizárólag bővítik.
A weben lehet, nem ismerek ilyen statisztikát, de általában (más szakmámban) többször is előfordul(t), én sokszor találkoztam vele. Pl. asszem '87-től 400/230V a kisfesz-hálózat, előtte ugye 380/220V volt. Ez is bővítés? :) Csak inf3rno csobogója kapcsán jutott ez eszembe, de rengeteg ilyen van, miért ne lehetne webes szabványt módosítani. Igen, fájdalmas, mint lecserélni a régi leégett kávédarálót is.
118

ECMAScript

Poetro · 2013. Okt. 28. (H), 09.37
A JavaScript mögött álló szabvány az Ecma International felügyelete alá tartozik ECMAScript néven. A JavaScript nagyrészt a Mozilla felügyelete alá tartozik, és a Sun bejegyzett védjegye, mellesleg az Oracle a védjegy tulajdonosa.
121

De az ECMA bizottságon

Joó Ádám · 2013. Okt. 28. (H), 12.03
De az ECMA bizottságon keresztül a Microsoft sem kerülhető meg a kérdésben. Az ő hozzáállásukat a backward compatibility-hez pedig elég jól ismeri mindenki.
124

A JavaScript nagyrészt a

tgr · 2013. Okt. 28. (H), 22.10
A JavaScript nagyrészt a Mozilla felügyelete alá tartozik


???
125

A Netscape örököse a Mozilla,

Joó Ádám · 2013. Okt. 28. (H), 22.22
A Netscape örököse a Mozilla, Brendan Eich a Mozilla CTO-ja, informálisan valószínűleg övék a legnagyobb befolyás a nyelv fejlődésére.
126

Akit esetleg érdekel, a

MadBence · 2013. Okt. 29. (K), 00.23
Akit esetleg érdekel, a szabványt illető fontosabb döntéseket a TC-39 teadélutánjain szokták megvitatni (egy nem tudom milyen friss lista a tagokról)
120

A szoftveres szabványokra

Joó Ádám · 2013. Okt. 28. (H), 12.01
A szoftveres szabványokra egyértelműen jellemző ez, mert a bizottságokban senki sem akarja kockáztatni a visszafele kompatibilitás elhagyását. Egy szép példa erre az ISO/IEC 10646, vagyis a Unicode, aminél explicit szabály az, hogy karaktert csak hozzáadni lehet a szabványhoz.
123

Köszönöm a válaszokat

Pepita · 2013. Okt. 28. (H), 17.04
Basszus, és ECMA-s pdf-doksim is van, I'm vakvarjú... Bocsi.
103

Nem jó with-et használni, egy

inf · 2013. Okt. 26. (Szo), 17.24
Nem jó with-et használni, egy hatalmas törést csinál olvashatóság szemponjából. Js-nél

var walla = ooo.eee.oo.ah_ah.ting.tang.walla.walla; 
walla.bing = true;  
walla.bang = true;
98

Mivel ebben sablonozós

MadBence · 2013. Okt. 26. (Szo), 15.24
Mivel ebben sablonozós kontextusban csak olvasni kell, így Crockford tanácsait nyugodtan ignorálni lehet.
100

Miért?

Pepita · 2013. Okt. 26. (Szo), 15.40
Nem adsz értéket DOM elemeknek?
104

A with használata a

MadBence · 2013. Okt. 26. (Szo), 17.37
A with használata a sablonozós kontextusban (ahogy azt tgr linkelte):

markupbuilder.div(
  markupbuilder.p('Hi! I am a paragraph!',
    markupbuilder.span('I am a span inside a paragraph')
  )
)

//You could instead write:

with(markupbuilder){
  div(
    p('Hi! I am a paragraph!',
      span('I am a span inside a paragraph')
    )
  )
}
105

hmm, nem rossz...

inf · 2013. Okt. 26. (Szo), 18.11
hmm, nem rossz...
102

Ha pontosan tudod, mit

bamegakapa · 2013. Okt. 26. (Szo), 15.50
Ha pontosan tudod, mit csinálsz, használhatsz bármit természetesen, a tanácsok és best practice-ek addig segítenek, amíg nem vagy tisztában a következményekkel.
110

Ez természetesen így van, de

Joó Ádám · 2013. Okt. 27. (V), 03.30
Ez természetesen így van, de jobb nem hangoztatni, mert túl könnyen hiszik azt az emberek, hogy ők tudják kezelni a következményeket.

All guns are always loaded.
113

Túl sokat csacsogtam...

bamegakapa · 2013. Okt. 27. (V), 15.46
Egyetértünk, a legtöbb esetben én sem szoktam eltérni a "best practice"-ektől.

Bízom a tudásomban, de mindenkinek lehet rossz napja - és így ilyenkor is védve vagyok.
117

Ebbe meg bele lehet

Pepita · 2013. Okt. 28. (H), 08.39
gyepesedni, ha kizárólag "best practice-alapon" kódolsz. És utolsóként újítasz, mire már cikkek tömkelegét írták a ~valamiről. Persze azt sem akarom ezzel mondani, hogy te találd fel a kereket, de valahol egy arany középút a helyes - szerintem.
122

Nem mondtam, hogy kizárólag.

bamegakapa · 2013. Okt. 28. (H), 12.24
Nem mondtam, hogy kizárólag. Az gyepesedik be, aki úgy használja vagy épp ellenzi a best practice-eket, hogy soha nem értette meg igazán az okukat.

Nem bûn biztos alapokra építkezni. Az újítás pedig szerintem maga is best practice.
75

Ahogy nézem a Laconic pont

Joó Ádám · 2013. Okt. 24. (Cs), 17.15
Ahogy nézem a Laconic pont ugyanazt csinálja, mint én, csak nem általános XML-re, hanem kész HTML osztályokkal. Már én is terveztem, hogy specializálom.
63

Eltér a véleményünk róla,

tgr · 2013. Okt. 24. (Cs), 09.58
Eltér a véleményünk róla, honnantól jól átlátható egy kód :-)
77

Én sem vagyok boldog a sok

Joó Ádám · 2013. Okt. 24. (Cs), 17.22
Én sem vagyok boldog a sok biolerplate-től, de ebben a nyelvben ez mindenre igaz. Ha több szintaktikai támogatást adna (type alias, named parameters stb.), akkor sokkal tömörebb volna a kód.
32

Ha egyszerűek a sablonok,

Hidvégi Gábor · 2013. Okt. 22. (K), 14.29
Ha egyszerűek a sablonok, akkor pl. Mustache-sal megkapod az XSLT összes előnyét
Bajusszal csak HTML-t éri meg generálni (lehet mást is, de akkor írhatsz meg hozzá egy értelmezőt), innentől kezdve pedig behozhatatlan lemaradásban van.
39

Szerintem ugyanúgy lehet vele

inf · 2013. Okt. 22. (K), 16.13
Szerintem ugyanúgy lehet vele bármilyen xml-t generálni. Az xml-től eltérő adatformátumokkal viszont lehet baj.
41

Ha buta kliensnek (kereső,

Hidvégi Gábor · 2013. Okt. 22. (K), 16.31
Ha buta kliensnek (kereső, böngésző) küldöd a tartalmat, akkor segíteni kell neki a feldolgozásban, azaz az XML-t tovább kell csócsálni, emiatt írtam, hogy nem éri meg, csak HTML-t generálni vele, mert azzal már jóesetben nem kell csinálni semmit.
49

A Bajusz nem is akar mindenre

bamegakapa · 2013. Okt. 23. (Sze), 10.09
A Bajusz nem is akar mindenre képes lenni és az AIDS ellenszerét kifejleszteni, az egy meglehetősen egyszerű eszköz, ami valamire való.
48

Egyetértek. Ráadásul a

bamegakapa · 2013. Okt. 23. (Sze), 10.06
Egyetértek. Ráadásul a sitebuilderre se tudod rábízni, hanem szenvedhetsz az XSLT-vel magad, mert szerencsétlen kitér a hitéből, ha meglátja azt a katyvaszt.

Szerény véleményem szerint volt egy korszak, amikor mindenki azt hitte, hogy mindent XML-el kell megoldani és az XML mindenre jó, az a Szent Grál. Ahogy Gábor is folyton emlegeti, ma is vannak sokan, akik különböző technológiákat Szent Grálnak hisznek - ez régebben se volt másként.

Szerintem az XML, illetve az XSLT egy borzasztó eszköz HTML template készítésére, de ez persze csak az én véleményem.
51

Nem is igaz, mert a REST a

inf · 2013. Okt. 23. (Sze), 11.33
Nem is igaz, mert a REST a szent grál :D
82

Lehetne inkább

Pepita · 2013. Okt. 25. (P), 03.43
a böngészőknek gépi kódot nyomni? Mondjuk x86 gépi kódot "mindenkinek" érteni kéne, én boldog lennék. Lehetne assemblybe nyomatni a kimenetet, villámgyors lenne...

(Csak vicc, nosztalgiázok, és felkerült máshol is a téma.)
85

Most is nyomhatsz, csak nem

inf · 2013. Okt. 25. (P), 11.17
Most is nyomhatsz, csak nem fogja érteni :D
87

De kiírja!

Pepita · 2013. Okt. 26. (Szo), 08.08
Az is valami. :)
89

NaCl

complex857 · 2013. Okt. 26. (Szo), 10.02
(Csak vicc, nosztalgiázok, és felkerült máshol is a téma.)

Pedig Googleben is felmerült ez a dolog pár évvel ezelött: Native Client
Más kérés, hogy nem lett nagyon népszerű se fejlesztők se böngészőgyártók körében.
6

Ha már úgy is egy tök

MadBence · 2013. Okt. 22. (K), 10.46
Ha már úgy is egy tök értelmetlen vitába kezdünk, akkor én is mondok személyes preferenciát: jade. Bármi másnak a használata jelentős hátrányokkal jár ehhez képest.
8

Ha ez így lenne, mindenki

inf · 2013. Okt. 22. (K), 10.52
Ha ez így lenne, mindenki jade-t használna. :-)
10

Az utolsó mondat nem az én

MadBence · 2013. Okt. 22. (K), 11.00
Az utolsó mondat nem az én fejemből pattant ki, lásd http://weblabor.hu/forumok/temak/119419#comment-104151.
11

Tudom. :-) Én leírtam már a

inf · 2013. Okt. 22. (K), 11.04
Tudom. :-) Én leírtam már a véleményem azzal kapcsolatban is. Csak akkor van értelme külön sablonnyelvet használni, ha noscript fallback miatt kliens és szerver oldalon is ugyanazokat a sablonokat használnánk. Én személy szerint nem csinálok ilyen oldalakat. A szerver oldali ui generálást hányinger keltő dolognak tartom.
13

Én személy szerint nem

Hidvégi Gábor · 2013. Okt. 22. (K), 11.22
Én személy szerint nem csinálok ilyen oldalakat. A szerver oldali ui generálást hányinger keltő dolognak tartom.
Van élet az alkalmazásokon túl is. A hagyományos weboldalak még eléggé népszerűek, és a keresők csak a szerveroldalon generált UI-t eszik meg a legkönnyebben.
27

A keresőnek adat kell, és nem

inf · 2013. Okt. 22. (K), 13.12
A keresőnek adat kell, és nem gui. Ha csinálok egy rest service-t, ami html-ben küldi az adatot, az ugyanolyan jó lesz a keresőnek, mint egy sima html weblap. Ha meg nem kereső nézi, akkor fölérakok egy klienst.
34

És máris HTML-t generálsz

Joó Ádám · 2013. Okt. 22. (K), 15.00
És máris HTML-t generálsz szerveroldalon.
35

Ez ellen nincs semmi

inf · 2013. Okt. 22. (K), 15.10
Ez ellen nincs semmi ellenvetésem. A GUI-t továbbra is kliens oldalon generálom, a HTML-t csak adatküldésre használom, semmi formázással kapcsolatos dolog nincs benne, se css, se javascript. Küldhetem helyette atom-al, hal+json-al vagy hal+xml-el is, ha az neked jobban tetszik... Annyiban jobb a html, xhtml, meg talán az atom, hogy azokat a google indexeli, így ha bot nézi az oldalt, egy az egyben átküldhetem a tiszta adatot, ha meg nem bot nézi, akkor js-el csinálhatok neki egy single page applicationt.
40

Ha már úgyis szerveroldalon

Joó Ádám · 2013. Okt. 22. (K), 16.19
Ha már úgyis szerveroldalon kell összeállítsd a HTML-t, akkor mitől jobb, hogy csak félkész?
42

Most nincs türelmem meg időm

inf · 2013. Okt. 22. (K), 17.35
Most nincs türelmem meg időm megfogalmazni. Nézd meg ezt a videot, ebből érteni fogod: http://vimeo.com/20781278
47

Nagyon egyszerű, a REST

inf · 2013. Okt. 23. (Sze), 02.23
Nagyon egyszerű, a REST service visszadob egy HTML-t, ami tartalmazza az adatot, a linkeket és az űrlapokat, minden css, javascript, stb... kód nélkül, ami a böngészőben való giccses megjelenítéshez kell. Ez kb olyan, mint amilyen a HTML volt a kezdetek kezdetén.
Ezek után a böngészőben ténylegesen megjelenő HTML-t a REST kliens állítja elő a csak adatot és linkeket tartalmazó HTML alapján. A gyakoratban ez azt jelenti, hogy megírod egyszer a REST kliensedet. Utána a következő projektnél átírod rajta a konfigban a domain nevet, hogy egy másik REST servicehez kapcsolódjon, és utána ugyanúgy működni fog, mert nem kell tudnia semmit az adatstruktúráról, azt készen kapja - linkek és űrlapok formájában - a csak adatot tartalmazó HTML-ből.

Hogy egy kicsit világosabb legyen a dolog. Ami az adatbázisban van, az egy objektum gráf. Minden egyes objektumnak vannak metódusai. Ezt az objektum gráfot egy REST service-nél felcímkézzük: minden objektumhoz tartozik egy url, a metódusokat pedig a HTTP method-oknak feleltetjük meg. Egy link vagy egy űrlap tehát egy objektum egy metódusára mutat, ami a linkre kattintáskor, vagy az űrlap küldésekor meghívásra kerül. Ha ez a metódus POST, PUT, DELETE, akkor módosítjuk az objektum gráfot. Ha a metódus GET, akkor reprezentáljuk az objektum gráfot az url-hez tartozó objektumtól kiindulva. A HTTP protokoll és egy hypermedia aware media type, mint mondjuk a HTML, tökéletesen alkalmas arra, hogy programozási nyelvtől függetlenül leírjunk vele egy objektum gráfot a rajta végrehajtható műveletekkel együtt. A böngészős, webalkalmazásos kliensek tehát nem elsődleges alkalmazási területei ennek a módszernek, gyakorlatilag bármilyen adatküldésre használhatóak olyan hálózatban, ahol többféle programnyelven írt service-ek vannak, amik rugalmasan vagy elérhetőek, vagy nem, stb... Ugyanezt a SOA UDDI-vel, WSDL-el, valamilyen protokollal, pl HTTP, illetve SOAP message-ekkel oldja meg. Ha valaki kezdő, akkor ezeket megtanulni rengeteg erőfeszítés szemben a HTTP + HTML kombinácójával, ami mellesleges sokkal emberközelibb logikáját tekintve.

Ami még baromi szép ebben az egészben, hogy a SOA - ROA kapcsolat teljesen ugyanaz, mint a procedurális programozás kapcsolata az objektum orientált programozással. A SOA-val procedurális szemlélettel adjuk meg az API-t, a ROA-val meg objektum orientálttal, ezért az analógia. A SOA egy névteret ír le függvényekkel, a ROA meg egy névteret, amiben egy objektum gráf van, amin minden egyes objektumhoz metódusok tartoznak. Ha bizonyos megkötéseket adunk a procedurális programozáshoz, akkor objektum orientáltat kapunk, ugyanígy, ha bizonyos megkötéseket adunk a SOA-hoz, akkor ROA-t kapunk. Tök érdekes, hogy a "procedurálisból OOP" témához mennyire kapcsolódik mindez.

Ami még érdekesebb, hogy mivel az adatbázisban egy objektum gráf van, ezért az adatbázis alapján generáltatható a REST API, és mivel már a kliensed megvan egy előző projektből, a tényleges munka (kisebb simításoktól eltekintve) leszűkül az adatbázis és az arculat tervezésére...
50

Hm, ez elgondolkodtató,

bamegakapa · 2013. Okt. 23. (Sze), 10.14
Hm, ez elgondolkodtató, köszönöm.
52

Konklúzió: Ha procedurálisan

inf · 2013. Okt. 23. (Sze), 15.09
Konklúzió:

Ha procedurálisan programozol valamit, és ki akarod tenni webre, akkor jobb, ha SOA-val csinálod, ha viszont objektum orientáltan programozol, és azt akarod kitenni, akkor a ROA sokkal kifizetődőbb. Ha az architecture más, mint a programozás stílus, akkor muszáj betenni plusz egy konverziót, ami sok plusz munkával jár.
9

Mely szerveroldali nyelvek

Hidvégi Gábor · 2013. Okt. 22. (K), 10.54
Mely szerveroldali nyelvek támogatják? Van natív kliensoldali feldolgozási lehetőség hozzá?
12

Node, PHP, Python (de biztos

MadBence · 2013. Okt. 22. (K), 11.07
Node, PHP, Python (de biztos van más nyelvre is portja). Kliensoldalon is működik (hisz eredetileg JS). Lefordítható, tehát interpretálni sem feltétlenül kell.
14

Sovány

Hidvégi Gábor · 2013. Okt. 22. (K), 11.27
Ennél az XSLT tízezerszer támogatottabb, ráadásul nem interpretált, hanem natívan. És nem csak arra kell gondolni, hogy te hogyan szeded ki belőle az adatokat, hanem vannak mások is, akiket érdekelhet a dolog.
16

Mely nagy projectek

MadBence · 2013. Okt. 22. (K), 11.35
Mely nagy projectek használják jelenleg ezt a förmedvényt? (erre nem kell válaszolni) És miért nem?
18

Miért nem?

Hidvégi Gábor · 2013. Okt. 22. (K), 11.55
Mert a webfejlesztő közösség jellemzően fiatal, divatvezérelt massza, a többség még a fáradságot sem veszi, hogy alternatívákat keressen, és inkább n-szer újra feltalálja a kereket. (Te is öt éve regisztráltál a weblaborra, de csak most olvastál utána ennek a majdnem tizenöt éves technológiának.)

Hogy mi förmedvény és mi nem, az szubjektív, és szokás kérdése. Ha most eléd rakok egy új nyelvet, például a LISP-et, ránézel, és ugyanezt mondod rá, mégis rengetegen használják, köztük sok, nálunk ezerszer jobb programozó.
19

átgondolatlan

retnek · 2013. Okt. 22. (K), 12.00
Szerintem a "förmedvény" épp olyan átgondolatlan kijelentés mint a "tízezerszer támogatottabb" illetve a "bármi másnak a használata jelentős hátrányokkal jár ehhez képest".

Ezen kár rugózni.
22

Átgondolatlan?

Hidvégi Gábor · 2013. Okt. 22. (K), 12.23
A két állításomat hamarosan egy hosszabb írás keretében alá fogom támasztani. Az XSLT egyébként nem a programozás csúcsa, biztosan lehet nála jobbat alkotni, de jelen pillanatban nincs alternatívája.
21

Használtam már XSLT-t a

MadBence · 2013. Okt. 22. (K), 12.21
Használtam már XSLT-t a gyakorlatban, nem tetszett. LISP-et nem, csak PPDL-t (ami kb ugyanaz a szintaktika, ha a LISP végtelen sok zárójelére utalsz), nem mondom, hogy az szimpatikus volt, de semmiképpen sem volt olyan komplikált, mint az XSLT.
23

Számodra egyébként mi volt

Hidvégi Gábor · 2013. Okt. 22. (K), 12.25
Számodra egyébként mi volt komplikált az XSLT-ben?
20

Az xTemplate ránézésre is

tgr · 2013. Okt. 22. (K), 12.19
Az xTemplate ránézésre is komolytalan dolog, nincs normális weboldala, nincs dokumentációja, de még egy featurelista se, az utolsó update 2008-as, a kódja alapján security last szemléletűnek tűnik, nincs benne normális hibakezelés, nincsenek scope-ok, nem tud autoescape-et, ami az egyik fő ok, amiért sablonnyelvhez nyúl az ember. Ez valakinek a hobbiprojektje lehet, annak szép, de komoly projektben bottal se, akkor már inkább nyers PHP (úgy látszik, a drupalosok is erre jutottak annak idején).

A Mustache egy nagyon ideologikus sablonnyelv, ami nagyon minimalista eszközöket nyújt csak, cserébe elég jól replikálható sokféle nyelven, illetve kliensoldalon is. Ez bizonyos alkalmazásoknál (pl. rengeteg apró AJAX-hívást használó single-page appok) nagyon hasznos lehet, más alkalmazásoknál inkább probléma, egy szerverorientáltabb, HMVC alkalmazáshoz pl. nehezen tudom elképzelni a használatát. (Plusz személy szerint nekem nem tetszik, hogy az autoescape-elt és a nyers változókat nehéz megkülönböztetni vizuálisan.)

A két "nagy" sablonnyelv PHP-hez egyébként a Smarty és a Twig, ezeket valamivel többet kell tanulni, de többet is tudnak. Sok különbség nincs közöttük, a Smarty egyszerűbb elven működik és könnyebben hackelhető, a Twig robosztusabb és komplexebb dolgokat tud, pl. az i18n-integrációja nagyon szép, cserébe kicsit rugalmatlanabb (és az írója szeret kreatív lenni a szintaxissal, ami helyenként inkább a Pythonra emlékeztet, mint a PHP-re, ízlés dolga, hogy ez jó vagy rossz dolog).
45

Hagyományos weboldal készítés

Vilmos · 2013. Okt. 22. (K), 23.44
Weblap tervezésnél a szokásos menet az, hogy a dizájn tervet átalakítják statikus html oldalakra, majd ebből indulnak neki a programozásnak. Kb.
Ez így jó, vagy van mit javítani rajta?
Érdekelne, ez már kihaló műfaj, vagy van rá kereslet? (költői kérdés)

Ha a szerver oldalon vagyok, akkor a statikus html-t kell valami módon illeszteni. A html-t, miután már kész, a legkevesebb sérülés akkor éri, ha sablonná alakítom.
Volt olyan eset amikor szétválogattam a spagetti kódot külön függvényekbe karbantartás címén. A PHP átláthatóbb lett, a megjelenítés meg követhetetlenné vált. Szóval, ilyet csak szükség esetén.

Marad a sablon. Megnéztem párnak a leírását, a "Smarty" természetesen benne van (a csapból is az jön). Valami mást akartam, olyan kis ügyeset. Végiggondoltam hogyan írok programot, megjelenítő kódot, bele a html-be. Elég egyszerűen: Változó egy-egy kijelölt helyre, sor másolás, azon esetleg javítás. És működni fog.
Végül is arra kerestem sablonozót ami a fenti két elvet(?) - iteráció több szinten, csere - jól láthatóan tudja. Ez lett az "xTemplate" minden fogyatékosságával együtt. A nagyokban ez a szemlélet nincs meg. Inkább szépített PHP nyelvek.
(Olyasmit mint az escape-lés könnyű pótolni, nem ezen fogok fennakadni.)

Ui.
Kíváncsiságból megnéztem 3 nagy fórumot, mi a vélemény a template rendszerekről.

1 - Weblabor:
Igazán színpompás közönség. Nem tudok élni nélküle - Néha jól jön - Úgy felesleges ahogy van - Generált tartalom kell, semmi más

2 - HUP:
Szinte osztatlan lelkesedés. Alighanem "igazi programozók" járnak ide, azok akik szeretik a bonyolult dolgokat.

3 - PROG.HU:
Előfordul az állás hirdetésekben. Egyszerűen nem téma.
46

Helyzet függő, hogy hogy

inf · 2013. Okt. 23. (Sze), 00.16
Helyzet függő, hogy hogy indulsz neki. Ha nem igény, hogy menjen javascript nélkül is az oldal, akkor simán csinálhatsz egy single page javascript application-t, ami megjeleníti az adatot kliens oldalon és egy webservice-t szerver oldalra, ami szolgáltatja az adatot a kliensnek. Innentől két projekted van, az egyik a megjelenítéssel foglalkozik, a másik adatot szolgáltat. A sablonok használata ilyen esetben szerintem egyáltalán nem indokolt, vígan meg lehet csinálni függvényhívásokkal sablonok nélkül az egész html generálást a kliens oldalon. Ha a szerver oldal RESTful, akkor a klienst elég csak egyszer megírni egy prototípus projektben, onnantól max a skin-t meg esetleg a layout-ot kell módosítani rajta, semmi máshoz nem kell hozzányúlni. A szerver oldalon is lehetnek ismétlődő elemek, pl beléptető rendszer, stb... de az azért minden projektnél kicsit más lesz. Jelenleg ez a legtakarékosabb megközelítés munka szempontjából, ha egyszer megírtad, akkor a megjelenítéssel alig kell foglalkozni, elég csak az adatlekéréssel. Ha szerver oldalról is kell tudni html-t generálni, akkor ott jó az a megközelítés, amit most használsz, hogy gui-tól adatlekérés felé haladva felülről lefele bontod le a problémát.
62

Az igazi

retnek · 2013. Okt. 24. (Cs), 09.08
Az igazi programozók nem szeretik a bonyolult dolgokat.
108

A korábban említett JS

MadBence · 2013. Okt. 27. (V), 01.23
A korábban említett JS sablonozó: madbence.github.io/jadeite/

Natív JS kód, nyilván megvannak a maga korlátai, leginkább csak just-for-fun jelleggel készült, meg persze azért, hogy megmutassam: ilyet is lehet.

Van benne változó behelyettesítés, néhány vezérlési szerkezet (if, csak az igaz ágra, illetve egy buta loop szerkezet)

Elsőre talán kicsit furcsa lehet a sok zárójel (bele lehet keveredni), azért esett a választás erre, mert csak.

Egy naprakész (és megfelelően beállított) Chrome böngészővel (Version 30.0.1573.2 dev), illetve node.js-ben (v0.10.16, --harmony kapcsolóval) is működik.
119

Adat vagy program

Vilmos · 2013. Okt. 28. (H), 10.00
Ez a fórum téma a közepén bővül, JS zavarokkal kapcsolatban ... az egy másik történet.

A tanácsok szerint a legfontosabb szempont:
- HTML mentesítése mindenféle program kódtól. Amit a böngészőnek küldünk, azt legjobb adatkezelési módszerekkel előállítani.

- Az elterjedt sablonozók nem szakadnak el a kevert nyelvtől. Együtt van minden, pont úgy mint a kezdetek kezdetén. Jól bejáratott megközelítés, szabványnak tekinthető. De itt, valamiért, a sablonozók kikerültek a látótérből. Nem elég praktikusak, vagy csak egyszerűen a szerver oldalon nem érdemes kimenetet előállítani?

- Ha már adat, akkor zavarba ejtő a választék. Maradhat a tartalom előállítás a szerver oldalon. XSLT például, generált kód, stb. Át lehet lapátolni az egészet a böngésző oldalára, vagy éppen meg lehet írni egyszerre mindkét oldalra szimultán. Az adatkezeléssel kapcsolatban:
- Egyedi megoldások tengere, cserébe rugalmasabb mint a sablon, viszont a színvonal erősen függ a programozó képességeitől.