Kliens oldali sablon rendszerek
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.
■ 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.
SXOOP Template 1 példa, YUI extension sablonmotorjával
http://toxin.hu/yui/table.htm
lényegi rész
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 :))
És? :)
Jack Slocum, YUI ext főállású programozója
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
DomHelper vs. Scriptaculous Builder vs. MochiKit DOM
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
szerintem nincs olyan, hogy ajax programozó...
dehogynem, és hello :D
üdv t
jóhát felőlem... :)
re
üdv t
csak óvatosan
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.
pontosan.
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. :)
netvibes.com
http://www.gucci.com/
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 :)
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
persze-persze js-tiltás :)))
(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...
Épp ezt kifogásoltam
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 :)
kimaradt link
http://www.psychedelix.com/agents/index.shtml
köszi
1:1 ? á, ez nem focimeccs :)
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 :)
:)
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.
igen, elvesznek a lehetőségek...
É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.
Van jogosultsága az elnevezésnek
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ó.
elbeszélünk egymás mellett
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? :)
ne a szavakon lovaguljunk
üdv t
igaz. igaz.