ugrás a tartalomhoz

Kliens oldali sablon rendszerek

Bártházi András · 2006. Nov. 19. (V), 16.30
Mint AJAX programozó, több projektem kapcsán is használtam már sablonrendszert, mely a kliens oldalon, vagyis a böngészőben, JavaScript alapokon dolgozott. Előnye ennek a megoldásnak, hogy a szerver felől JSON formátumban érkező adatokat könnyen és átláthatóan formába lehet önteni, a helyzettől függően akár több megjelenésben, teljesen független megjelenítési formában. A kód és a megjelenés elválasztásáról pedig gondolom nem kell papolnom: egyszerűen hatékony módja a programozásnak. Eddig a TrimPath féle JavaScript Template megoldást használtam, most egy másik megoldás jelent meg, mely hasonlóan jónak, esetleg jobbnak bizonyulhat.

A SXOOP Template megoldásról van szó, melyet szerzője TrimPath-os tapasztalatok után hozott létre. A lényeg ugyanaz, a sablonnak átadott JavaScript objektumot a rendszer HTML-lé képes alakítani, hatékonyan, gyorsan. A SXOOP szerzője inkább a beágyazott programkódok híve, ezáltal viszont a rendszer kódja a TrimPath megoldásához (~400 sor) képest is kisebb (~75 sor) lett. Én azt hiszem, hogy maradok a TrimPath-nél, mivel az jobban megvalósítja a kód és a megjelenés különválasztását, de jó, hogy bejött egy másik lehetőség is a képbe, gazdagítva a palettát.
 
1

SXOOP Template 1 példa, YUI extension sablonmotorjával

toxin · 2006. Nov. 19. (V), 20.48
pusztán kiváncsiság meg, hogy lehessen majd méricskélni, http://pxn8.com/sxoop_template/template_intro.html példáját megcsináltam YUI extension sablonmotorjával

http://toxin.hu/yui/table.htm

lényegi rész


YAHOO.namespace ('myTemplate.table');

YAHOO.myTemplate.table = function(){
	// shortcuts
	var $E  = YAHOO.util.Event;
	var $D  = YAHOO.util.Dom;
	var $DH = YAHOO.ext.DomHelper;
	var $X  = YAHOO.ext;
		
	return {		
		inic : function (employees){
		 	// create table,tbody
			var table = $DH.append(this.id,{tag:'table',id:this.id+'_table',border:0,children: [{tag: 'tbody'}]}); 
			this.tbody = table.firstChild;
			// add first and content rows template			
			this.tableHead = new $DH.insertHtml('afterBegin',this.tbody,'<tr><th>Name</th><th>Dept.</th><th>Manager.</th></tr>');		
			this.tableRow = new $DH.Template('<tr class="row{rowNum}"><td>{name}</td><td>{dept}</td><td>{manager}</td>');
			// fill template from employees, use http://www.dustindiaz.com/basement/sugar-arrays.html 1.6 js forEach method emulation
			employees.forEach( 	function(employee,index){
					this.tableRow.append(this.tbody,{
						rowNum : index%2,
						name : employee.name,
						dept : employee.dept,
						manager: employee.manager
					})
					this.maxIndex = index;
			},this);
			// add last footer row
			this.tableFooter = new $DH.insertHtml('beforeEnd',this.tbody,'<tr><td colspan="3" style="background: rgb(204, 204, 204) none repeat scroll 0%; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">There are '+(this.maxIndex+1)+' Employees</td></tr>');					
		}		
	}
}();
// set the source array
var employees = [
    {name: "Jimmy Corrigan", dept: "I.T.",       manager: "Pete O'Reilly"},
    {name: "Louis O'Neill",  dept: "Purchasing", manager: "Derek Mahoney"},
    {name: "Larry Murdoch",  dept: "I.T.",       manager: "Pete O'Reilly"},
    {name: "John Doe",       dept: "Sales",      manager: "Terry Dunne"}
];
// shortcut
var $E  = YAHOO.util.Event;
// set Y! onAvailable event (DOM id, inci method, inic : function (employees))
$E.onAvailable('table_wrapper',YAHOO.myTemplate.table.inic,employees);

mivel közben a scriptaculous Builder-e is frissült,
http://dev.rubyonrails.org/browser/spinoffs/scriptaculous/CHANGELOG?rev=5468
de azt még nem néztem meg, az azzal készült példát holnap beszúrom, aztán lehet tesztelni :)

üdv t

--
megj : fenti kódformátumról, sablonmotorról weblabor kereső YUI
megj2 : fenti kód jelenlegi YUI tudásom alapján készült, lehet nem optimális, a YUI extension, compile metódusáról mint lehetséges gyorsítási lehetőségről természetesen tudok
megj3: fenti példában this/context object, végig a table_wrapper DOM objektum, ez vszeg nem a legszerencsésebb, de most a Base oop motort nem akartam használni, viszont ronda kódot sem :))
2

És? :)

Bártházi András · 2006. Nov. 19. (V), 23.03
És mi jött ki a méricskélés eredményeként? Nálam (nem ilyen gyakorlatias tesztet használva) az jött ki, hogy a DOM építés felejtős játék. A SXOOP és a TrimPath kapcsán a parse-olás nélkül is mérhető a dolog, illetve vele együtt is. Emlékeim szerint még a parse-szal együtt is gyorsabb volt, mint a DOM építés. A probléma, mint legtöbbször, Internet Explorerrel van, de a DOM építgetés amúgy is lassabb, mint az innerHTML megoldás.
4

Jack Slocum, YUI ext főállású programozója

Anonymous · 2006. Nov. 20. (H), 08.10
már méricskélt
http://www.jackslocum.com/blog/2006/10/06/domhelper-create-elements-using-dom-html-fragments-or-templates/
alul benchmark,

csak a maradékot Trimpath, SXOOP Template -t is kéne :) , ill. megnézem még mit alkott Thomas Fuchs a Scriptaculous-al, este

üdv t
5

DomHelper vs. Scriptaculous Builder vs. MochiKit DOM

toxin · 2006. Nov. 20. (H), 08.48
hamár Jack megcsinálta akkor nem este, de ez csak nekem nem megy

http://www.jackslocum.com/blog/examples/domhelper.htm

kolléga csak a YUI-t nem csatolta be :S ,

szóval
YUI Extensions 0.33 beta
MochiKit-1.3.1
scriptaculous-js-1.6.5

(AMD XP 2400+, winXP prof 2002, sevice pack 2)
http://toxin.hu/yui/bench.html

fx 2.0

MochiKit: 3.469 seconds
Scriptaculous Builder: 3.312 seconds
Basic Dom Helper: 1.313 seconds
Dom Helper w/ Compiled Template: 0.75 seconds

fx 1.5.0.7

MochiKit: 4.281 seconds
Scriptaculous Builder: 3.719 seconds
Basic Dom Helper: 1.141 seconds
Dom Helper w/ Compiled Template: 0.922 seconds

ie6 (hú *** :) )

Scriptaculous Builder: 7.328 seconds
MochiKit: 6.172 seconds
Basic Dom Helper: 1.64 seconds
Dom Helper w/ Compiled Template: 0.672 seconds

ie7 csal vpc-n van, valaki?

Opera 9.02 (riszpekt :) )
MochiKit: 2.641 seconds
Scriptaculous Builder: 1.109 seconds
Basic Dom Helper: 0.344 seconds
Dom Helper w/ Compiled Template: 0.141 seconds

Trimpath, SXOOP Template ? :)

üdv t
3

szerintem nincs olyan, hogy ajax programozó...

virág · 2006. Nov. 20. (H), 07.23
Mi az, hogy "Ajax" programozó? Szerintem helyesebb lenne: "mint Ajaxot használó programozó", vagy "mint Ajaxot rendszeresen használó". Egy egyszerű módszerről van szó, nem hinném, hogy ez egy új programozói "fajt" hozott volna létre. :)
6

dehogynem, és hello :D

toxin · 2006. Nov. 20. (H), 09.15
új faj : sitebuilder + js programozó = ajax programozó , mint a liligo.fr ajax programozója :) , szerver oldali kódot már nem is látok

üdv t
7

jóhát felőlem... :)

virág · 2006. Nov. 20. (H), 10.08
Felőlem lehet így nevezni :) Szép dolog az Ajax, de azért mégse kéne :P. Engem már a Web 2-től is kiráz a hideg, picit mondvacsinált dolog ez az egész. De ízlések és pofonok, nem fárasztom magamat ezzel. :)
8

re

toxin · 2006. Nov. 20. (H), 10.24
jó hát lehetne, felhasználói élményt fokozó programozó is :D csak az ajax szebb :)

üdv t
9

csak óvatosan

Anonymous · 2006. Nov. 20. (H), 10.35
Én mindig is mértéktartással vélekedtem az Ajaxot illetően. Ha igazán korrektek akarunk lenni és valóban mindenki számára (értsd: minden internetező számára) elérhetővé akarjuk tenni a tartalmat, akkor azt Ajax nélkül is elérhetővé kell tenni.

Egy régebbi böngésző, vagy egy hibás kiadás, vagy egy másik oprendszer és valahol elakad a JS, akkor toszhatod. Arról nem is beszélve, ha szorult helyzet, ssh, vagy akármilyen okból kifolyólag mondjuk csak linx-et, vagy ami még rosszabb, de működik, wget-et tudnád csak használni. Akkor mi lenne? Szép is volna, ha ilyen helyzetbe kerülnél és a hibajhavításos letöltős oldalak mind csak Ajax mellett működnének.

A keresőkről nem is beszélve.... A HTML-t több száz "böngésző" támogatja (mondjuk ki, ami rendelkezik USER_AGENT-tel annak támogatnia kell, mert különben nem jó arra, amire való), míg a HTTPREQUEST-et mennyi? 10? 15? A JS által "generált" kódban nem sok kereső tud keresni (ha van egyáltalán egy is, ami tud).

Az Ajax kiegészít, nem helyettesít.
10

pontosan.

virág · 2006. Nov. 20. (H), 10.55
Pont így, ahogyan írod. Igazából mindent ki lehet izzadni, a könyvjelző kezelést is, de minek? Belőlem egyszer kifacsarták egy projekt keretein belül, hogy ezt megvalósítsam...szép élmény volt.

Szerintem azért sok jó példa is van a neten, mármint ahol megtalálták a helyes használati módokat, pl. a keresést, webshopnál a kosár kezelést stb. irányítják "Ajax"-al.

Ott kell használni, ahol helye van. Felhasználói élmény növelésére, könnyítésre, háttérben adatküldésre (pl. számolásnál, tárolásnál) stb. ( de szerintem tök jól használják, igazán rossz példát még nem is láttam.)

Aki tud rossz példákat az linkelje be. :)
11

netvibes.com

Anonymous · 2006. Nov. 20. (H), 11.06
tiltsd le a JS-t :)
12

http://www.gucci.com/

toxin · 2006. Nov. 20. (H), 11.16
tiltsd le a js-t, de miért kéne letiltani, a fentiekkel teljes mértékben egyetérve (nincs: bookmarks, history, back gomb, offline böngészés, search bot-ok kizárása stb ) de az ajax technológia, a Grade A-s böngészők/platformokon ill ezen halmazon belül, a js 90%+ ban elérhető

http://developer.yahoo.com/yui/articles/gbs/gbs_browser-chart.html
http://www.w3schools.com/browsers/browsers_stats.asp

, és az IE7 vmint a crossbrowser kódbázisok, megjelensével böngészőfüggetlenebb a css-nél is, akkor miről beszélünk :)



JavaScript Statistics

There are no absolute trends about the use of JavaScript. Some users have scripting turned off. Some browsers don't support scripting:2006 JavaScript On JavaScript Off
January 90% 10%


ergo éljen az ajax, csak módjával és okosan :)

üdv t
13

persze-persze js-tiltás :)))

virág · 2006. Nov. 20. (H), 11.36
Azért azt leszögezhetjük, hogy 2006-ban a JS letiltása nem egy természetes állapot, aki letiltja az viselje a következményeit :)
(persze kivételt képeznek azok a helyzetek, ahol önhibáján kívül speciális helyzetbe kerül valaki - vakok, mozgássérültek, de erre külön kell felkészülni szerintem (a fejlesztőknek és tartalomgazdáknak is) és más dolgokra is oda kell figyelni, nem csak mechanikusan levenni a színeket, megnövelni a betűméretet és elkerülni a JS-t... ez szerintem nem sokat ér azoknak, akiknek készülne... - igazából oda kellene figyelni az embereknek egymásra, nem csak mechanikusan elvégezni valamit...)


Margóra:
...tessék megnézi a Magyar Vakok és Gyengénlátók Országos Szövetségének weblapját, találni abban táblázatot és Javascriptet is, talán jó lenne jobb példával elöljárni :) De ez más téma, nem az én dolgom.

http://mvgyosz.budapest.hu



"ergo éljen az ajax, csak módjával és okosan :)"

szerintem is, ugyanakkor éljen az egyszerűség és az egyszerű, átlátható megoldások :) a kettő sztem nem zárja ki egymást...
14

Épp ezt kifogásoltam

Anonymous · 2006. Nov. 20. (H), 11.48
A "böngésző" nem csak azt a pár programot jelenti, amivel az átlagember netezik. A statisztikák persze 90%-ot mutatnak, mert csak ezeket figyelik. Ha minden programot figyelnének, ami a weboldalak "feldolgozásával" foglalkozik, akkor már nem lenne ilyen magas a pontszám.

Ott van az a csomó Spider, Robot, és Crawler is, nem beszélve a vakok és gyengénlátóknak szánt felolvasó programokról (ne ragadjunk le a magyarországi színvonalnál), amik nincsenek a statban, ellenben szeretnének indexelni, mert a kereső oldalak ezek alapján működnek. Plusz vannak szerver oldali keresők (pl htdig), amik a saját oldalad leindexelésére valók, és ezzel gyors és hatékony keresőt adva a kezedbe (ezt se kell külön megírni).

Vagy ott vannak a PDA-k a Smartphone-ok, amiken limitált lehetőségeket lehet belezsúfolni egy böngészőbe. Vajon azok ismerik-e az ilyen mértékű javascriptezést?

Ezért írtam, hogy "Ha korrektek akarunk lenni".

Bár én eléggé fafejű vagyok és törekszek a rendes munkára, hogy ne zárjak ki senkit az információhoz való hozzáférés lehetőségétől. Persze ez így rengeteg plusz munka, és szöszmötölés, talán "fölöslegesen". De mindenkép pjó érzés, ha kész :)

Persze kétségtelen előnye az Ajax-nak, hogy valamiképpen tehermentesíti a szervert, mert a kliens oldalon állít elő sok mindent.

Magyarán 1:1 :)
15

kimaradt link

Anonymous · 2006. Nov. 20. (H), 11.50
Érdemes átnézni. Nincs nagy jelentőségük, de jó látni, mennyien is vannak :)

http://www.psychedelix.com/agents/index.shtml
17

köszi

virág · 2006. Nov. 20. (H), 12.21
Ez egy jó kis lista, de remélem nem akarod az oldaladat mindegyikkel letesztelni! :)))
16

1:1 ? á, ez nem focimeccs :)

virág · 2006. Nov. 20. (H), 12.20
:) én nem versenyezek, teljesen egyetértek veled, egészen addig, amíg nem csúszunk át egyik szélsőségbe sem, azaz nem mellőzünk semmilyen új technológiát (persze csak azt, ami bevállt és nem egy felvillanó csillagocska, ami egy hónap alatt eltűnik) és a másik oldalra sem, hogy mindent ami újnak tűnik lihegve belezsúfolunk a szoftverünkbe. (ez nem csak a webes projektekre igaz).

Az információhoz való hozzáférésből egy csomó ember ki van zárva (szegénység miatt stb.) , ez nem a mi hibánk, ez ocsmány politika, de persze mindent meg kell tennünk nekünk is, a "szöszmötölés" ezekkel a dolgokkal csak tiszteletreméltó, különösen ebben az iparágban.

szerintem az a megoldás, hogy minden változatra egyedi látványt kell biztosítani, nyilvánvaló, hogy egy PDA-n vagy mobilon másképpen jelenik meg egy weboldal, erre nyilván készülni kell. de ezzel remélhetőleg tisztában van minden fejlesztő :)

szal 1:1 okay :)
22

:)

Anonymous · 2006. Nov. 20. (H), 14.46
Erről van szó! :)

Vele is (ha van rá mód), nélküle is (mert "illik").

Kicsit más: a w3schools-on szoktam böngészni az xhtml tagek leírását, és mindig találok valami újat és izgalmasat, és mindig belegondolok, hogy mennyi lehetőség lenne a "nyelv"-ben, de mennyire csak a felszínt kapargatjuk, nem használjuk ki.

A weblabor egy nagyon jó, és szép példa arra, hogy mi mindent lehet belerakni egy oldalba. És ha elsőre nem is látjuk, tényleg van hasznuk azoknak a fránya "alig használt" tag-eknek és/vagy attribútumoknak.
23

igen, elvesznek a lehetőségek...

virág · 2006. Nov. 20. (H), 15.05
Pontosan, ez már engem régebben is idegesített, talán az lenne a megoldás, ha a projektek meg lennének tervezve rendesen...De nincsenek. Egyszerűen nincsenek átgondolva a tervek, ma ugyanolyan weboldalak készülnek mint régebben, tele rossz beidegződésekkel.

Épp ma hallottam: "ez csak egy X összegű projekt, nem érdekel bennünket, hogy megy-e Firefox alatt, az ügyfél meg úgyse tudja mi az a Firefox..."

Ha itt tartunk, akkor mit akarunk? Ez szánalmas...Ehhez képest az XHTML lehetőségeinek kihasználása nagyon távolinak tűnik és mégsem, mivel hálistennek nem mindenki ilyen, itt a Weblaboron nyilván sok olyan ember van, aki nagyon is odafigyel a minőségre, lehetőségekre - csak sajnos, nem ők kapják azokat a projekteket, amiket elharácsolnak a "nagy" cégek és a korrupt pályázati rendszer...

Az XHTML-t nem is nagyon ismerik. Általában ilyen kategóriájú weblapok, mint a weblabor azért jobbak minőségileg, mert saját maguknak csinálják az emberek. Egy céges weblap még sokáig nem lesz ilyen, mert a fejlesztő cégek nagyon sokat kérnek mindenért, irreális árakat számolnak fel pl. az RSS beépítéséért, validitásért, ún. keresőmarketingért, rövid URL-ért, arra építve, hogy a felhasználó úgyse tudja mi mennyi munka és mennyi érték, jól átvágjuk. Szerintem.


stb. stb. eléggé fárasztó dolog ez.
18

Van jogosultsága az elnevezésnek

Jano · 2006. Nov. 20. (H), 13.06
Hagyományosan idegenszóval Sitebuildernek szokták nevezni a HTML+CSS+JavaScript fejlesztőt. A feladata az, hogy az oldal lapjait megjelenítse a böngészőkben. A logika a szerver oldalon van, neki csak a kimenetet kell formázni.

Manapság azonban a bőngésző nem csak egy buta képernyő ami kirakja amit küldtek neki. Megjelent a böngésző mint platform felfogás és egyre komplexebb feladatokat bíznak a bőngészőben futó JS-re, illetve okosan megosztják a böngésző és a szerver feladatait. Ez alapvetően más képességeket követel meg.

Ha szavakon akarunk lovagolni: egy sitebuilder valójában nem is programozó. Leírónyelvvel jelöl meg szöveget. Az AJAX programozó már valódi programozó.
19

elbeszélünk egymás mellett

virág · 2006. Nov. 20. (H), 13.22
elbeszélünk egymás mellett, én nem erről beszéltem, hanem arról, hogy "Ajax programozó" nincs és nem arról, hogy a HTML+CSS szerkesztőt hogyan nevezzük (a "sitebuilder" tényleg erre szolgál, ez okay) :).

Arról nem tehet senki, hogy a HTML és JavaScript programozásban annyira nagy durranás, hogy lehet közvetlenül kérést kezdeményezni a szerver felé. Pl. a C-nyelvben sem nevezzük Socket programozónak azokat, akik használják ezeket, vagy ahogyan PHP-ban sem nevezzük Curl programozónak azokat akik kihasználják a Curl lehetőségeit. Ugyanígy, szerintem Ajax programozó sincs, csak azért még nem lesz külön programozói állatfaj valaki, mert kihasználja a JS ezen lehetőségeit (vagyis a böngészőét, de tudja mindenki mire gondolok).

Nem? :)
20

ne a szavakon lovaguljunk

toxin · 2006. Nov. 20. (H), 14.00
egyébként http://liligo.fr/air/js/core.js szóval ha ilyet sitebuilder csinál ám legyen :) , de a témához tessék hozzászólni, az-az méricske-méricske ;)

üdv t
21

igaz. igaz.

virág · 2006. Nov. 20. (H), 14.15
Igaz, ne lovagoljunk a szavakon és ne is fűzzük tovább. Egyébként szerintem Jano nem erre gondolt, mármint arra, hogy egy sájtbilder ilyet csinálna, szerintem te is félreértetted őt :) :D