49
-
ThiefHu #49 Akit erdekel a teljes tanulmany magyarul az megtekintheti itt: http://insecurity.hu -
wanek #48 "java appletek nagyon lassuak, legalabbis amiket en lattam, cgi, asp, perl ... megatobbi nem kell." - szerintem nagyon nem vagy képben. A Java applet a gépeden fut (és a Java szerintem is nagyon lassú), a "cgi, asp, perl" pedig a szerveren, aminek az eredménye a képernyődön megjelenik, de a felhasználónak ebből a szempontból lényegtelen, hogy a szerveren mi fut. -
#47
"...ami a forma es a tartalom elvalasztasat illeti - hat az adat pl. mysql adatbazisba kerul a format meg lehet varialni"
Csak itt a tartalom és a forma szétválasztásáról, nem az az adatbázisban tárolt adat és a felhasználó által böngészhető tartalom szétválasztásáról volt szó.
Két különböző dolog.
"cgi, asp, perl ... megatobbi nem kell."
HTML-ből nem fogod elérni az adatbázist...
"Ami a tablakat illeti - minden bongeszoben egyforman nez ki"
1. Hogy táblázatos oldalszerkezetet használsz, annak az az oka, hogy a HTML nyev eredetileg nem arra lett kitalálva, amire mostanság használják - azaz layout-ok készítésére. Ez menti meg egyedűl a táblázatokat - a régi böngészők - de szerencsére nem sokáig.
2. Jelenleg arra felé halad a trend, hogy minden egyes taget arra használjanak, amire való. Táblázatot táblázatos adatok megjelenítésére, CSS-t a formázásra.
3. Vajon miért beszélnek egyre inkább szakmai fórumokon (kis hazánkban például a Weblabor) egyre többet a táblázatos oldalszerkezet elhagyásáról? CSS-redesign-ról? Szemantikusságról? Akadálymentességről?
Miért nem ennek ellenkezője (igénytelenség, nem-törödömség) a húzóerő? Miért nem ezekről tartanak konferenciát, adnak ki szakkönyveket? Ja, mert a webes nyelvek fejlődnek! -
vaddiszno #46 ...ami a forma es a tartalom elvalasztasat illeti - hat az adat pl. mysql adatbazisba kerul a format meg lehet varialni .... gondolom a tartalmat nem text fileokban tartjatok ... ott a Joomla meg a tobbiek. Es ami a server terheltseget illeti, php-ban is lehet optimalizalni a kodot, erre az egyik rossz pelda a Typo3. Ami az internetes vasart illeti, mondjuk ott rendelek, de a fizetest nem ott bonyolitom le. En meg a bankoknak a webes szolgaltatasait se hasznalnam. Az emberkek egy rakas scriptet hasznalnak , de a nagyresze az oldal pofazmanyat befojasolja, vagy felmegoldasokat nyujt ... java appletek nagyon lassuak, legalabbis amiket en lattam, cgi, asp, perl ... megatobbi nem kell. Ami a tablakat illeti - minden bongeszoben egyforman nez ki, a css deklaracios reszerol meg irtak mar elottem ... de az kimaradt h mennyit kell bogozgatni h egy par ablakot/cellat normalisan elhelyezz ... a tablaknal meg minimalis energiaval szep dolgokat lehet kihozni - table bg + cell bg + kep a cellaba, esetleg meg page bg ... es persze minden darabka minden bongeszoben a helyen van. Azzal mondjuk egyetertek h mega-siteoknal/portaloknal nem szamit a design, de a tobbieknel biza sokat nyom a latban. -
wanek #45 "Mégis rengetegen fejlesztenek pl. ActiveX-es alkalmazásokat intranetre - ami alapból csak IE-n működik" - itt van az igénytelenség remek mintapéldája. Egy webes alkalmazást azért készítenek webesre, mert akkor a kliens oldalon egy gyengébb gép is elegendő, amin elmegy egy böngésző. Ez egyben elvileg platformfüggetlenséget is eredményezne. Persze nem úgy, hogy csak szutyok msie-activex-windows alatt mehet, mert azzal csak adtak a szarnak egy pofont.
"Ha sűrűn van használva a Windows Update (ami azért elvárható dolog - mármint az operációs rendszer frissítéseinek rendszeres telepítése), akkor az IE 5-nek is illett volna frissülnie IE 6-ra..." - na persze. Ismerjük a taktikát. Ha egy biztonsági rést egy harmadik cég befoltoz, akkor jön egy update, ami további hibákat eredményez, vagy nemkívánatos dolgokat csempész az ember gépére (lásd az eredetiségvizsgálat árulkodó tevékenységét, amire szerencsére fény derült. És még ki tudja, mennyi ilyen árulkodó van? Pontosabban: lehet tudni egy jópár beépített "kémprogramról". WMP, MSIE, ActiveSync, Outlook, stb.). Köszi, de nem kérek belőle. Ez így egy végtelennek tűnő mókuskerék, amiből még időben ki kell szállni.
"Bűn, de édes bűn." - én inkább keserű pirálának nevezném.
"Mégis rengetegen fejlesztenek pl. ActiveX-es alkalmazásokat" - Egy klasszikus mondás erre: "Többmilliárd légy nem tévedhet! Együnk szart!" -
wanek #44 Beidézhetted volna a továbbiakat is, és akkor ilyen népi "bölcsességeket" nem tudtál volna elsütni. -
#43
""A fejlesztő cég felmérte/megkapta-e, hogy a cég milyen verziójú szoftvereket használ?" - minek azt tudni?"
Azért hogy ne kerüljön a fejlesztő/a felhasználó zűrös helyzetbe.
Például más-más motor kell egy lemezjátszóba és egy porszívóba. Mindkettő elektromos motor, mégis más elvárások vannak velük szemben. -
#42
" biztos a legfrissebb Mozilla volt rajta. Szóval mennie kellett volna, ha a kritérium a "legfrissebb"."
Ha sűrűn van használva a Windows Update (ami azért elvárható dolog - mármint az operációs rendszer frissítéseinek rendszeres telepítése), akkor az IE 5-nek is illett volna frissülnie IE 6-ra...
"Egy ilyen böngészőre fejleszteni a legnagyobb felelőtlenség. Én azonnali hatállyal világgá zavartam volna azt, aki olyan webes alkalmazást készít, ami csak a szutyok msie alatt megy."
Mégis rengetegen fejlesztenek pl. ActiveX-es alkalmazásokat intranetre - ami alapból csak IE-n működik. Miért? Mert egyszerűen integrálható a Windowsos alkalmazásokhoz.
"de bűn olyan alkalmazást készíteni, ami csak egy meghatározott böngészővel megy."
Bűn, de édes bűn. Lásd az ActiveX-re tett megjegyzésem. -
wanek #41 "És mivel ez egy céges/oktatási intézményes alkalmazás lehetett, elvárható lett volna a webböngésző legfrissebb változatának használata (biztonsági frissítésekkel egyetemben)." - biztos a legfrissebb Mozilla volt rajta. Szóval mennie kellett volna, ha a kritérium a "legfrissebb".
Mellékesen megjegyezném, hogy pont a mikrofos volt az, ami - különböző biztonsági problémák miatt - állandóan azt javasolta a felhasználóknak, hogy ezt, meg azt a funkciót kapcsolják ki, bizonyos dolgokat ne engedélyezzenek, stb. Nos, ha ezt az ember megtette, akkor egy olyan nulla tudású böngészője maradt, ami gyakorlatilag semmire sem volt alkalmas. Egy ilyen böngészőre fejleszteni a legnagyobb felelőtlenség. Én azonnali hatállyal világgá zavartam volna azt, aki olyan webes alkalmazást készít, ami csak a szutyok msie alatt megy. A hozzá nem értés magasiskolája.
"A fejlesztő cég felmérte/megkapta-e, hogy a cég milyen verziójú szoftvereket használ?" - minek azt tudni? Olyat kell csinálni, ami minden elterjedt böngészővel megy. Az elterjedtséget úgy határoznám meg, hogy ami (ha csak magyarországi felhasználóknak készül) Magyarországon 1%-osnál nagyobb "piaci részesedéssel" rendelkezik. Persze lehet vitatkozni a százalékon, de bűn olyan alkalmazást készíteni, ami csak egy meghatározott böngészővel megy. -
#40
"van rajta egy ie5, mire a válasz, ja azzal sem megy 6.0 xxxx kell neki!"
Valószínűleg akkor már létezett az IE 6-os változata.
És mivel ez egy céges/oktatási intézményes alkalmazás lehetett, elvárható lett volna a webböngésző legfrissebb változatának használata (biztonsági frissítésekkel egyetemben).
"Na ennyit a javaról meg a kompatibilitásról."
Ez most javas, vagy javascriptes alkalmazás volt?
A fejlesztő cég felmérte/megkapta-e, hogy a cég milyen verziójú szoftvereket használ? -
#39
A java-t és java scriptet is utálom mint a szart!
Hoztak egy webes alkalmazást, és mondták, hogy csak ie-vel megy, mozilával nem. Na mondom mekkora egy rakás szar, mindegy alapban van rajta egy ie5, mire a válasz, ja azzal sem megy 6.0 xxxx kell neki!
Na ennyit a javaról meg a kompatibilitásról.
A sebességról már nem is beszélek!
Érdekes nekem interaktív flash mozik mennek php-vel, egy árva majmoknak való java sincs benne, és nem lassú.
stargateszink.uw.hu pl. -
nedudu #38 Nana, a perlt csak nem bántani 
-
#37
ha úgy gondolod, hogy a php-t csak divatból használják a webprogramozók, akkor használj csak perlt :P -
wanek #36 Lehet, hogy érthetetlen lesz számodra, de én kb. 1 hónapig használtam WYSIWYG szerkesztőt annak idején, hogy egyáltalán megtanuljam a HTML-t, azóta ha valamit csinálok (statikus oldal), akkor csak és kizárólag Ultraedit-et használok. Dinamikus oldalaknál meg ugye úgyis legeneráltatja az ember az oldalt, de itt is törekszem a pure HTML-re, mert azt a legprimitívebb browser is tudja értelmezni. És úgy látszik én nem követem a divatot, mert nem PHP-t használok, hanem Perl-t :) -
#35
" A leíró részeket miért nem számolod bele?"
Mert nem a HTML része, hanem a CSS-é. Tartalom/design különválasztása. -
#34
"Nem akarlak győzködni, látom, hogy reménytelen. Megkajáltad te is "az újabb mindig jobb" maszlagot."
Szerinted nem jobb egy összeszedettebb XHTML+CSS páros mint egy non-valid (xyz WYSIWYG szerkesztővel összeberhált) táblázatos/spacer gif-es kialakítás?
Szerinted nincs értelme egy mindenki számára normálisan elérhető tartalomnak (ami igényesen van összerakva)? -
wanek #33 A példád tipikus csúsztatás. A leíró részeket miért nem számolod bele? -
wanek #32 "Lehet csak a weblap megtekintése után dönti el a termék boltban történő megvásárlását" - oké, így már jobban hangzik. De hát ez szerintem édeskevés, mert semmivel sem ad sokkal több _hasznos_ infót, mint egy reklámújság. Viszont felhasználói vélemények és tapasztalatok egyes fórumokon sokat nyomnak a latban. Persze ezeket a véleményeket is szűrni kell, de ezek mennyisége nem összemérhető egy termék bemutatkozó oldalával.
Nem akarlak győzködni, látom, hogy reménytelen. Megkajáltad te is "az újabb mindig jobb" maszlagot. Pedig az állítás nem minden esetben igaz. Tipikusan az objektumorientált programozási szemlélet hozadéka, de mint tudjuk, nem ez eredményezi a kis méretet, most pedig erről volt szó. -
#31
"ez csak akkor igaz, ha külső file-ra hivatkozik."
Márpediglen a tartalom és a design különválasztásának ez a legjobb módja.
"De az mennyivel rövidebb, mint a font?"
<p class="piros">Ez egy piros bekezdés</p>
<p><font color="red">Ez egy piros bekezdés</font></p>
"Annak meg eltörném a kezét, aki spacert használ."
Magyarországon ez még bevett szokás. De reméljük nem sokáig...
Validság? Minek?
Igényesség? Ugyan már!
Akadálymentesség? Az vicc!
-
wanek #30 "De mivel a CSS-kód újrafelhasználható (több oldal is használhatja ugyanazt a CSS állományt;" - ez csak akkor igaz, ha külső file-ra hivatkozik.
"lásd: például class attribútum" - látom, látom. De az mennyivel rövidebb, mint a font? Annak meg eltörném a kezét, aki spacert használ. -
wanek #29 "Ha kifogytál a szakmai érvekből, személyeskedsz..." - nem én kezdtem... -
#28
"internetes vásárlásra gondoltál? Nekem ilyen soha eszembe sem jutna, hogy így vásároljak."
Nem feltétlenűl internetes vásárlásra. Lehet csak a weblap megtekintése után dönti el a termék boltban történő megvásárlását. És az már potenciális vásárló. -
#27
"ezt sem merném így kijelenteni, akárhány "megmagyarázó" linket és szöveget emelsz be."
De mivel a CSS-kód újrafelhasználható (több oldal is használhatja ugyanazt a CSS állományt; és csak egyszer kell letölteni), illetve egy adott CSS deklarációt több elem is használhat egyszerre (lásd: például class attribútum), ezért a CSS mérete mégiscsak kisebb, mint egy újra- és újradeklerált <font> tag, vagy spacer gif.
"Tipikus szolgáltatói hozzáállás. Észt nem osztottál, mert nem volt mit. Abban viszont igazad van, hogy feleslegesen irkaFirkáltál :)"
Ha kifogytál a szakmai érvekből, személyeskedsz... -
wanek #26 "mindegyik lehet potenciális vásárló" - internetes vásárlásra gondoltál? Nekem ilyen soha eszembe sem jutna, hogy így vásároljak. -
wanek #25 Tipikus szolgáltatói hozzáállás. Észt nem osztottál, mert nem volt mit. Abban viszont igazad van, hogy feleslegesen irkaFirkáltál :) -
#24
"Nem a dialup user a lényeg, hogy neki hamar meglegyen az oldal."
Hanem mindegyik (mindegyik lehet potenciális vásárló!). Olvasgassatok egy kis Jakob Nielsen-t (ő foglalkozik a webergonómiával).
"minden script veszélyes, aminek az adott platformon az implementációja el van szva."
Épp ez az, hogy elvileg a Javascript-nek alapból nem kellene veszélyesnek lennie, de elszúrják az implementálását.
"ez egy komoly szakmai fórum :DD"
Ugye te ezt viccnek szántad? ;)
A Weblabor ebből a szempontból az lenne... ...bár a fórumon ott is vannak érdekes anonymous-ok.
"Amúgy meg a flash nem rosz dolog, csak a legtöbb helyen kb az animált gif helyett használják."
Ahol animációra (gif-hez hasonlítani - ami csak 256 szines - kissé túlzás), mozgásra, pixelpontos grafikára, különböző betűtípusokra van szükség ott kiválóan alkalmas. -
irkab1rka #23 minden script veszélyes, aminek az adott platformon az implementációja el van szva.
Amig a stackben hoz létre valami adatokat, és azokon szarul implementált függvényeket (strcpy) hív, addig bármi (script, kép, stb) veszélyes.
Olvassatok már el egy-egy security bulletint légyszives. A microsoft hetente átlag kettőt ad ki :)
Amúgy Faustus: Nem a dialup user a lényeg, hogy neki hamar meglegyen az oldal. _Nekem_ nem mindegy szerver oldalon, hogy mennyi adatot kell cache-ben tartanom, és mennyi idő alatt nyomom ki a csövön.
Az aki azt gondolja, hogy a szervernek kell minden megcsinálnia az nagyon nem ért hozzá (Wanek)
és még életében nem látott WAN-ra irt alkalmazást, aminek x millió user-t kell kiszolgálnia. Nézz utána légyszi a near cache fogalmának, mondjuk indulásnak. Örülök, hogy segithettem...
És ha tájékozatlan vagy AJAX-ban, akkor inkább ne írjál le semmit. Az XMLHTTPRequest-nek annyi köze van az ActiveX-hez, hogy az egyik böngésző esetében egy activex component, de a többi esetben (pl mozilla szoftverek) már nincs is activex-ed :)))
FYI:
var req = new ActiveXObject("Microsoft.XMLHTTP");
var req = new XMLHttpRequest();
ugye...
Amúgy tegye fel a kezét, aki clusterezett itt már LAMP-ot. Köszi. Gondoltam. A PHP-vel meg ne viccelődjünk itt, ez egy komoly szakmai fórum :DD
Amúgy meg a flash nem rosz dolog, csak a legtöbb helyen kb az animált gif helyett használják. Van egy pár profi oldal a neten, ahol mesterien megirt flash van. Az igaz, hogy nem volt olcsó :)))
És a reprezentáció - ugye - nem keverendő össze az adattal és a business layer-el. Ha jól irtad meg, akkor xml-ben kiszolgálhatsz flash-t, vagy egy ajax-os oldalt, vagy direktben egy kliens programot.
Hé. Minek osztom itt az észt? Aki felfogja, az vagy nálunk, vagy a konkurenciánál dolgozik, a többinek meg minek? :)))) -
wanek #22 "De ha van lehetőség arra, hogy egyes feladatokat levegyünk a szerver válláról - akkor miért ne?" - azért, mert ő szolgáltat, nem én. Vagy innentől kezdve én is a szolgáltató része vagyok? Mert akkor kérem a részesedésemet!
"Normális esetben nem szabadna. Sajnos hogy egy böngészőben van/volt ilyen exploit az más tészta." - exploit minden böngészöben volt már. Jellemzően a legtöbb a msie-ben.
"Másrészt a HTML kód mérete éppenhogy kisebb lesz" - ezt sem merném így kijelenteni, akárhány "megmagyarázó" linket és szöveget emelsz be. Csak a CSS definíciós része akár nagyobb is lehet, mint a hasznos tartalom. Sok ilyet láttam már. És ezekre ugyanúgy hivatkozni kell, mint pl. a <font>-ra.
A poénkodó szövegedre nem tudok hasonló stílusban válaszolni, érdemben meg így minek? -
#21
"ez a szolgáltatói oldal feladata. Gondoskodjon róla, ha akar valamit. "
De ha van lehetőség arra, hogy egyes feladatokat levegyünk a szerver válláról - akkor miért ne?
"De memóriatartalom is kiolvastatható, stb, de ebbe ne menjünk bele."
Normális esetben nem szabadna. Sajnos hogy egy böngészőben van/volt ilyen exploit az más tészta.
"szerintem meg nem. Ettől nő meg igazán a méret. És a veszély is így sokkal nagyobb."
Hol "nagyobb" a veszély? A CSS-nél (megeszi a gépedet vacsorára egy gonosz border-top tulajdonság)? Az XHTML-nél (a nagybetűk - akik nem szerepelhetnek a tagekben - fellázadnak és elhagyják a gépedet, és nem tudsz ZSUZSI SZERETLEK-jellegű kiabálásokat produkálni a csevgőcsatornákon)? A diszkrét Javascriptnél (maximum a HTML forrásban kevésbé észrevehető kód miatt nagyobb az eredetileg is veszélyes Javascript)?
Másrészt a HTML kód mérete éppenhogy kisebb lesz például egy táblázatos oldalkialakítás lecserélésénél CSS-re (sok spacer gif elhagyása, sok <tr>/<td>/</tr>/<td> elem lecserélése); a <font> elemek elhagyása; az újrafelhasználható kód (mind CSS-nél, mind Javascriptnél, illetve a jövőbeni XML+XSLT technológiáknál) miatt. Persze ehhez ésszerű használat szükséges.
Idézet egy szakoldalról:
Well-structured markup that separates structure and content from presentation is generally much more compact than table-and-spacer-image-based tag soup. Documents will be smaller and faster for visitors to download. Like it or not, there are still many, many people connecting to the Internet through dialup.
If your site has a hosting plan with a limit on free bandwidth usage, smaller documents will reduce costs - provided traffic doesn’t increase.
456 Berea street - Ten reasons to learn and use web standards
Egy másik:
Reduction in File Size: I reduced the file size of the SitePoint page from 34,353 bytes to 18,585 bytes. It would be smaller again if it wasn't for all those rounded corners!
One file controls the whole site design: OK you've heard this before - it is part of the beauty of CSS in general. Should you decide to add Geneva to your font family because you're becoming Mac friendly then modify your style sheet and the changes will be reflected across your whole site.
Sitepoint - HTML Utopia! Design Websites Without Tables - Parts 1 and 2 -
wanek #20 "De nem annyira, hogy más felhasználóktól vegyük el a rá eső feldolgozási időt." - ez a szolgáltatói oldal feladata. Gondoskodjon róla, ha akar valamit.
Az iwiw más miatt veszélyes. Olyan adatokhoz és kapcsolati rendszerekhez lehet hozzájutni, ami még csak véletlenül sem a felhasználó érdekeit szolgálja. Én pl. soha nem használnám. Mint ahogy a telefonos közvéleménykutatóknak sem mondok soha semmit (ingyen). Az információ érték, és ezt az adatgyűjtők rendesen pénzre is váltják. Az adatot szolgáltatót pedig mindig elfelejtik díjazni...
"A javascripttel keveset tudsz kutakodni - szerencsére." - ez majdnem így van, de nem is a javasriptre gondoltam. Egyébként az általad felsoroltakon kívül nagyon kellemetlen meglepetés érhet valakit a cookie-k miatt is, és mellesleg azt is javascripttel lehet írni-olvasni. De memóriatartalom is kiolvastatható, stb, de ebbe ne menjünk bele.
"Ezért jó a XHTML+CSS+diszkrét Javascript alapú weboldalkészítés." - szerintem meg nem. Ettől nő meg igazán a méret. És a veszély is így sokkal nagyobb.
Nem azzal van bajom, ha valami elegánsan van megoldva. De rettenetesen sok a sallang, így az ember a NoScript mellett kénytelen Adblock-ot is használni :) Így elérhető, hogy a képernyőre tényleg csak a valós hasznos tartalom kerüljön, a hirdetések, a különböző felhasználói szokásokat gyűjtő javascriptek és egyéb sallangok nálam meg sem jelennek. :) -
#19
"A szervernek az a dolga, hogy dolgozzon."
De nem annyira, hogy más felhasználóktól vegyük el a rá eső feldolgozási időt.
Lásd pl: iwiw.
"Akkor pedig elég visszatetsző, ha olyan technikákat próbálnak erőltetni, ami a kliens gépen tud a felhasználó tudta nélkül kutakodni."
A javascripttel keveset tudsz kutakodni - szerencsére. IP-cím, felbontás, használt pluginek, cookie-k - de felhasználói file-ok, privát adatok nem kerülhetnek a felhasználó tudta nélkül illetéktelen kezekbe.
"Ma már nagyon sok mobil támogatja a flash-t (persze nem a low-end kategóriában)"
Flashlite néven van rá megoldás - de a Flash-ben elterjedt izgő-mozgó-animálódó dolgok mennyire hatékonyak egy szimplán tartalmat kívánó alkalmazás esetén? Mert játéknál, mozibemutatónál, csak-csak...
"Sajnálatos módon manapság egy oldalnak a kódja szükségtelenül nagy. Sok esetben tizedakkora méretben is megoldható lenne valami, simán html tag-ekkel."
Ezért jó a XHTML+CSS+diszkrét Javascript alapú weboldalkészítés. Az XHTML-be csak a tartalom és a struktúra kerül, a CSS-be csak a design, a diszkrét javascriptbe csak a viselkedés. Ha valamelyikre nincs szükség, kiiktatható.
"Valóban a tartalom érdekli a felhasználókat, ehhez pedig a sok csilivili csicsa érdemben nem tud hozzátenni."
Természetesen az igényes design (nem a csilivili) kellemes hatással lehet a látogatóra, de ezzel óvatosnak kell lenni.
-
wanek #18 A szervernek az a dolga, hogy dolgozzon. És persze nem egy árva gép van általában beállítva, hanem az igényeknek megfelelően szerverpark.
Ez a kliens-szerver megoldás eléggé vitatható hatékonyságú. Akkor pedig elég visszatetsző, ha olyan technikákat próbálnak erőltetni, ami a kliens gépen tud a felhasználó tudta nélkül kutakodni. Persze ez a céljuk, de ezt nem kell megengedni. Csak a birkákat lehet a vágóhídra terelni...
Sajnálatos módon manapság egy oldalnak a kódja szükségtelenül nagy. Sok esetben tizedakkora méretben is megoldható lenne valami, simán html tag-ekkel.
Ma már nagyon sok mobil támogatja a flash-t (persze nem a low-end kategóriában), a wap pedig már induláskor is halott ötlet volt, mára tulajdonképpen le is áldozott.
Valóban a tartalom érdekli a felhasználókat, ehhez pedig a sok csilivili csicsa érdemben nem tud hozzátenni. -
#17
"...es mondjatok h miert/mire nem jou a php?"
Mert jobban terheli a szervert, mintha Javascript-tel tehermentesíted.
Például: elküldöd a termékek listáját PHP segítségével, és Javascripttel rendezed sorba.
"Mi a fenenek kell osszekavarni mindenfelet. CSS, jscript, ajax megatobbi."
A tartalom ((X)HTML), a forma (CSS), és a viselkedés (Javascript) szétválasztására (hogy ne egy nyelvbe legyen sűrítve minden). Ha majd közbelép a tartalom (XML) és a struktúra (XST) különválasztása akkor még inkább részekre lesz bontva az egész (ami a jobb struktúráltság szempontjából eléggé előnyös).
"meg flash elmegy"
A Flasht nem lehet tökéletesen mobilplatformra vinni (például wap-ra), nem kezelik a felolvasószoftverek, a keresők sem szeretik, és nem kifejezetten a web központi "nyelve".
"a pofazmany nagyreszet ugyis a Photoshop vegzi"
És ez érdekli a mobilplatformot használókat? A keresőket? A felolvasószoftvereket használókat? Nem, őket (mint általában mindenkit) elsősorban a tartalom érdekli. -
vaddiszno #16 ...es mondjatok h miert/mire nem jou a php? Mi a fenenek kell osszekavarni mindenfelet. CSS, jscript, ajax megatobbi... minimalis jscript meg flash elmegy, a pofazmany nagyreszet ugyis a Photoshop vegzi, akinel meg nem, az majd rajon idovel. Ha fizetosdirol van szo akkor meg egyszerubb megadni egy bank kontot, mint gateway-t belekavarni, egy normalis vasarlonak mindenkepp nagyobb a bizalma, legalabbis en biztos nem fogom weboldalra beirni az adataimat. -
irkab1rka #15 Mióta mondom, hogy a webes alkalmazásokat megbszhatjátok...
Szenvedsz egy csomót, a végén meg vagy csak explorerben megy, vagy van annyi javascripted, hogy öröm maintainelni :) -
#14
"Szerintem a jó öreg HTML ben mindent meglehet oldani ami egy normális böngészéshez kell, nekem nem kell a flash meg a többi brandwith evő cucc ami "elméletileg" szebbé teszi a környezetet... megaztán álltalában minden egyes újítással egyre kevesebb levegője van a kliensnek, azaz annál több a megkötés."
Vissza a HTML 2.0-hoz... Nincs <script>, nincs <style>, nincs <object>, nincs <embed>... -
wanek #13 Így van. -
#12
1. Egy árva XMLHTTPRequest (se M$-os megfelelője: XMLHTTP) nincs se az adott oldalon, se az oldalról elérhető Javascript szkriptben.
2. Nem ActiveX-et használ, mert működik Firefox alatt is, amiben alapból nincs ActiveX-támogatás (bár van hozzá ActiveX kiterjesztés...).
3. Az XMLHTTPRequest nem működik megfelelően külső domainen. Lásd itt: . -
#11
személyszerint kikapcsolom a scripteket (még egy pár apróságon kívül) böngészésnél, csak ha éppen igényeli az oldal (és persze én is, mert látni akarom az oldal tartalmát, vagy egy két speciális funkciót) akkor lövöm be. álltalában amelyek oldalok erősen vannak scriptelve azoktól túl sok jóra sem lehet számítan, sőt mondhatni, hogy egyenesen rosszindulatúak a kliensel szemben. Agresszív "de én telepíteni akarom a gépedre" utasítások, pop-up ok, ilyen-olyan átvezetések különböző oldalkra mind az engedélyen kívül stb, stb nagy a lehetőségek listája, és nem szégyenlik kihasználni őket egy kicsit sem :). Szerintem a jó öreg HTML ben mindent meglehet oldani ami egy normális böngészéshez kell, nekem nem kell a flash meg a többi brandwith evő cucc ami "elméletileg" szebbé teszi a környezetet... megaztán álltalában minden egyes újítással egyre kevesebb levegője van a kliensnek, azaz annál több a megkötés. -
wanek #10 Ez is az activex-et baszkurálja, ami egyébként is potenciális veszélyforrás. Nem kell msie-t használni.