- A hozzászóláshoz be kell jelentkezni
- 4520 megtekintés
Hozzászólások
Alakul ám a böngészők Flash Playeresítése.
- A hozzászóláshoz be kell jelentkezni
Kifejted mire gondolsz?
- A hozzászóláshoz be kell jelentkezni
Arra, hogy a HTML5 + CSS + JS alapvetően arra kell most a cégeknek, hogy ne legyenek beszorítva az Adobe platformjára a webappok. Viszont ezzel a lépéssel ugyanazok a problémák meg fognak jelenni, mint a Flash esetében is.
Igazából már most őrületbe kergetnek még a nagyobb oldalak is (Google, Facebook, stb.) az elbaszott input fókusz kezelésükkel, az elbarmolt UI-val, azzal, hogy olyan technológiára építenek appokat, ami alapvetően nem arra való (a HTML alapvetően szöveg megjelenítésre jött létre, ennek a mai napig érződik a hatása, pl. nincs kijelölhetetlen text, ami enyhén esztétikusabb lenne a tartalmon kívül kb. minden szövegre). De brutálisan sok példát lehetne még mondani, szerintem el is fogom kezdeni jegyzetelni, hogy mi az, ami bosszant.
Szóval az irány, amerre a web most halad, az egy inkozisztens trágyadomb felé mutat. Hakkolás hakkolás hátán, egyszerűen gusztustalan.
- A hozzászóláshoz be kell jelentkezni
És mi lenne a megoldás?
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
- A hozzászóláshoz be kell jelentkezni
Udi említette a kommentjében a Shumway Open SWF Runtime Project-et. Ezt kellett volna pár évvel ezelőtt beindítani, Flex SDK eddig is nyílt volt, aztán annyi. Lehetne szépen, elegánsan, profi módon webappokat készíteni, amik esetleg (Air runtime-ban) még desktop appként is futnak (vö. Chrome, FF hasonló taknyolásai).
- A hozzászóláshoz be kell jelentkezni
A tökéletes mindig az lenne, hogy kompromisszumok nélkül lefejleszteni egy új dolgot, amely az aktuális igényeknek meg fog felelni. De aztán telik az idő, és saját régebbi verzióival kompatibilisnek kell maradnia, meg az igények is változnak. Sőt, ha valamiért egy adott megoldás nagyon elterjed, akkor annak támogatása nagyobb súlyt kell hogy kapjon, és egyre jobban belebetonozottnak fog tűnni. Stb.
És a végén megint ugyanott vagy. Szerintem ez nehezen kiküszöbölhető hosszú távú kompatibilitás tartásánál bármilyen megoldásnál.
- A hozzászóláshoz be kell jelentkezni
Miert zavar, hogy valami kijelolheto? Szerintem ez direkt elorelepes. Mindig utalom, ha a ui-on valamilyen szoveg nem kijelolheto/masolhato.
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Mert például a vezérlőelemek cimkéi nem a tartalomhoz tartoznak.
- A hozzászóláshoz be kell jelentkezni
Viszont ezzel a lépéssel ugyanazok a problémák meg fognak jelenni, mint a Flash esetében is.
pont az a lényeg, hogy nem, mert a HTML5 az szabvány -> nincs vendor lock.
A többi amit írtál pedig vagy lényegtelen (szar UI-t bármilyen technológiával lehet fejleszteni), vagy lejárt lemez.
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
A html5 nem szabvány, legfeljebb az lesz valamikor. Az sem igaz, hogy nincs vendor lock, mert gyakorlatilag nincs olyan böngésző, amelyik a html5 jelenlegi változatát 100%-osan implementálná. Vagyis akármilyen kis subsetet is használsz, minden böngészőt nem fogsz tudni támogatni.
Ebből a szempontból a flash még jobb is, mert ott legalább 1 vendor dönti el, hogy mi legyen a saját szabványában és mi nem, vagyis fejlesztőként pontosan tudod, mit használhatsz és mit nem. Ha pedig akarsz egy saját flash playert, pontosan tudod, mit kell támogatnod egy 100%-os implementációhoz.
Szar ui-hoz annyit, hogy egy normális fejlesztői környezet ad eszközöket arra, hogy könnyen alakíthass ki jól használható ui-t. Vagyis rossz ui létrehozásához vagy direkt kell rosszul csinálni a designerben (több munka), vagy a designer nélkül kell csinálni (még több munka).
- A hozzászóláshoz be kell jelentkezni
A HTML5 annyira szabvany, hogy egyreszt maximum ajanlas, masreszt a W3C is 2014-re teszi a veglegesitest, es felmeresuk szerint 2020-ban jelenhetnek meg az elso, 100%-osan kompatibilis implementaciok.
- A hozzászóláshoz be kell jelentkezni
Szvsz a fókuszkezelés egyértelműen az appokat fejlesztők hibája, ugyanúgy, ahogy flash-ben is el lehet rontani _bármit_.
Kijelölhetetlen szöveg pedig minimum 4 éve van.
A hakkolás a sok delphi kóderből php kóderré vált, majd flash-ben, most pedig jquery/társai-val "fejlesztők" "munkájának" az eredménye. Olyan sok "web"fejlesztőt ismerek, aki alapvető dolgokkal nincs tisztában, hogy ihaj - tisztelet a kivételnek.
De még1x: ez rohadtul nem a google/mozilla/egyebek hibája. Egy eszközt lehet jól és rosszul is használni.
- A hozzászóláshoz be kell jelentkezni
Van kijelolhetetlen szoveg, utalom is. (Mi van, ha ra akarok keresni? Gepeljem be kezzel a google-be?)
- A hozzászóláshoz be kell jelentkezni
"nincs kijelölhetetlen text"
de van.
Kíváncsi lennék a listádra :)
- A hozzászóláshoz be kell jelentkezni
Mert ez aztán tényleg ultimate megoldás :) Sokkal elegánsabb, mint a gagyi Flex :)
Azt, hogy gányolással meg lehet oldani, azt azért ne nevezzük már annak, hogy "van" :)
- A hozzászóláshoz be kell jelentkezni
user-select: none;
ez gányolás?
- A hozzászóláshoz be kell jelentkezni
-webkit-touch-callout: none;
-webkit-user-select: none;
-khtml-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
Ez gányolás.
- A hozzászóláshoz be kell jelentkezni
Nem, nem az. Így lehet új funkciókat tesztelni a kompatibilitás megtartása mellett. Majd idővel kikopnak az eltérő variációk és az utolsó sort fogja értelmezni mindegyik.
- A hozzászóláshoz be kell jelentkezni
Majd idővel eljön a Linux Desktop Éve is...
- A hozzászóláshoz be kell jelentkezni
Nem, a Linux-os verzió az lenne, ha ugyanúgy kéne előhívni minden böngészőben, de máshogy működne. Ezzel szemben ebben a formában a böngészőben el lehet választani a kísérleti funkciókat a többitől.
- A hozzászóláshoz be kell jelentkezni
Arra akartam utalni, hogy a "majd a jövőben nem lesz gányolás" az nem jelenti azt, hogy jelenleg nem gányolás és azt sem, hogy a jövőben ez biztosan változni fog.
- A hozzászóláshoz be kell jelentkezni
Nana.
A W3C még vitatkozik, hogy része legyen-e (újra) a specifikációnak, vagy sem. Régebben része volt egy draftnak, azóta kivették a jelenlegi specifikációból, de most megint filóznak, hogy kell-e vagy nem.
http://lists.w3.org/Archives/Public/www-style/2012Jul/0573.html
- A hozzászóláshoz be kell jelentkezni
Igen, pontosan ezért fontos, hogy ilyenkor még egyértelmű legyen, hogy ez egy kísérlei funkció.
- A hozzászóláshoz be kell jelentkezni
Akkor kijelenthetjük, hogy jelenleg az egyetlen hivatalos út a JavaScriptes gányolás.
- A hozzászóláshoz be kell jelentkezni
ezt szépen levezetted a css példából
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
A fentiek szerint a CSS-es gányolás is hivatalos?
- A hozzászóláshoz be kell jelentkezni
Kísérleti funkciót nem használunk máshol, csak kísérleti projekten. Persze a webpistikéknek jó dolog az, hogy napról napra változik a specifikáció, így aztán a böngészőt készítők gyakorlatilag teljesen szabad kezet kapnak abban, hogy mit lehet és mit nem. Persze az IE-t azért fikázzuk a saját dolgai miatt, de a többi böngészőt nem. Pedig azok is pontosan ugyanígy viselkednek.
- A hozzászóláshoz be kell jelentkezni
Várj, én úgy tudom, ez a user-select már nem része az ajánlásnak, superseded.
Lásd:
http://www.w3.org/TR/css3-userint
Ennek a része volt a user-select anno, http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-select itt látható is.
Azonban a helyére lépő CSS3 Basic User Interface Module (http://www.w3.org/TR/css3-ui/ ) már nem tartalmaz ilyen propertyt.
Ez az igazi gányolás, amikor még a "szabványügyi testület" sem tudja mit akar, a böngészők már megint nem szabványkövetők, mert nem lehetnek azok.
- A hozzászóláshoz be kell jelentkezni
Függetlenül attól h a folyamat jó-e vagy sem, ezek a dolgok eleve azért kerülnek bele a böngikbe, hogy lássák h van-e értelme. Nem azért van benne mert követnék
- A hozzászóláshoz be kell jelentkezni
Ezek szerint úgy gondolod, teljesen helyénvaló az egyes böngészőkben a vendorspecifikus funkciók megléte. Végülis, a Netscape és IE által vívott első böngészőháborúban meg pont az volt a baj, hogy az IE és az NS egyedi funkcionalitásokat implementált, amit a versenytársa nem. Most akkor nem értem, mi is kell igazán nektek? Egyedi funkció, csak ne a MS csinálja? Nem baj, ha az Apple csinálja? Vagy a Google? Elárulom: ugyanakkora baj.
- A hozzászóláshoz be kell jelentkezni
Szerintem helyénvaló, amíg egyértelmű, hogy vendor-specifikus és nem arról van szó, hogy egy adott dolog másképp viselkedik mint a többiben (ld. IE6) vagy olyan kiterjesztést nem implementál, amit a versenytársak a szabadalmak vagy a technológiai korlátok miatt (ld. ActiveX vs multiplatform böngészők) nem tudnak implementálni.
A web organikusan fejlődik, ezek a vendor specifikus kiterjesztések segítenek felmérni azt, hogy egy technika a gyakorlatban működik-e vagy nem, tökéletesíteni lehet, ha pedig életképesnek bizonyul, be lehet emelni a szabványba. Sokkal életképesebb szabvány jön így létre, mintha a széles körben ki nem próbált, elméleti dolgokat vetnének a papírra.
Vannak itt, akik egy ceruzával és papírral egy ültő helybe megalkotnák a HTML6-ot is, de a világ már csak ilyen igazságtalan; aki nem ért hozzá az tanítja és az szabványosítja. :P
- A hozzászóláshoz be kell jelentkezni
"ld. ActiveX vs multiplatform böngészők"
Még jó, hogy az ActiveX egy nyílt specifikáció 1996 óta, a specifikációs az az Open Group kezeli, akinek a felelőssége a UNIX specifikálása is (SUSv4) és a UNIX trademark is az övék. Nem hiszem, hogy az MS rosszhiszeműségén múlna, hogy implementálja más is az ActiveX-et.
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.js…
"A web organikusan fejlődik"
Éppen ez a baj. Ez technológia, nem biológia. Ez mérnökség. Az pedig nem organikus. Nincs olyan, hogy szabvány, nem tudsz hosszú (5 év) távra normálisan megtanulni/megtanítani bármit is, így idővel egyre drágább lesz ez a technológia, ahelyett, hogy olcsóbb lenne. 2020-ra várható az első teljesen kompatibilis HTML5 böngésző.
"Sokkal életképesebb szabvány jön így létre"
Nem, nem jön létre szabvány. 2014-re saccolja a W3C a HTML5 szabványt, addig ki tudja, menyire fognak divergálni a böngészők.
- A hozzászóláshoz be kell jelentkezni
Ezek nem egyedi funkciók, és épp a közös nevező megtalálása a cél. Az activex, a filterek, a scripttelt css funkciók, htc és tsai meg mind a ms egyéni elgondolása a webről, miközben telibesz.rta, hogy ki mit gondol erről. A dart már inkább mondható hasonló elgondolásnak, bár a dart implementálásához nincsen szükség arra, hogy a teljes win32 API alatta álljon.
- A hozzászóláshoz be kell jelentkezni
Hozzáteszem, ha kijelölhetetlen a szöveg, akkor lőttek a SEO-nak, mivel az a keresők részére is olvashatatlanná válik. Szóval jó az, ha kijelölhető.
- A hozzászóláshoz be kell jelentkezni
Egy webalkalmazásnak nevezett izében található teszemazt törlés gombhoz mi köze van a keresőnek?
- A hozzászóláshoz be kell jelentkezni
Miért is?
Nem arra gondolsz ha képként rakod be a szöveget is?
Indexeléskor felesleges CSS-t értelmezni.
- A hozzászóláshoz be kell jelentkezni
Nem. Ha tiltod a kijelölhetőséget, akkor eleve nem tudod textként értelmezni az adott szöveget, ergo más se fogja tudni. Legalábbis olvastam ilyet. Viszont most logikusan belegondoltam: ezt javarészt javascriptel lehet elérni, a google azt meg úgy sem ismeri. Szóval tévedtem.
- A hozzászóláshoz be kell jelentkezni
csak gondolkodom, de ha css-sel tiltod, akkor elvileg az megjelenés, nem tartalom, azt nem kellene figyelembe vennie a böngészőnek. Ha js-sel tiltod egyértelmű hogy nem fog tudni arról a kereső, ha pedig html-ben tiltod (mint ha az IE úgy találta volna ezt fel korábban hogy egy html attribútumot lehetett megadni - lusta vagyok rákeresni most)... na akkor lehet hogy azzal foglalkozna a keresőmotor is.
Bár nem tűnik logikusnak az összefüggés a kijelölhetőség és a tartalomként értelmezés között.
- A hozzászóláshoz be kell jelentkezni
Szerintem amit olvastal az a kepkent vagy flashkent beagyazott tartalomra vonatkozott. Egy normal indexelo robot nem ertelmezi a HTML-t es a CSS-t csak kibanyassza a fajlbol a szoveget es az URL-nek latszo dolgokat.
- A hozzászóláshoz be kell jelentkezni
"normal indexelo robot nem ertelmezi a HTML"
De
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy ő arra gondolt ami a kocsiban van :oP
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
- A hozzászóláshoz be kell jelentkezni
Ugyan most vicceltél, de már készül az is.
- A hozzászóláshoz be kell jelentkezni
Na ez máris egy normálisabb irány lett volna a HTML megerőszakolása helyett. Hogy csak egy aprócska példát hozzak, Flashben lehetőség van socketek kezelésére, nem kell szívni az Ajax-szal real-time kommunikáció esetén.
- A hozzászóláshoz be kell jelentkezni
Hát én nem vagyok egy webfejlesztő alkat, és van véleményem az egész HTML5-ös, Javascriptes, böngészőben appos takonyolásról, de azért a WebSockets még én is ismerem... :)
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Igen, a taknyolás a helyes kifejezés:)
http://en.wikipedia.org/wiki/WebSocket#Browser_Implementation
- A hozzászóláshoz be kell jelentkezni
a taknyolás a helyes kifejezés
gondolom még nem láttál javascript mvc/mvvm keretrendszert (backbone, knockout, angular, ember, stb)
Sztem hagyd abba az okoskodást, nagyon nem megy.
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
Te meg nem lattal valodi MVC-t desktop alkalmazasban, Observer patternnel megvalositva. A weben ennek imitalasa nem mas, mint taknyolas.
Es ne keverjuk az n-tier architekturat meg az MVC-t, mast jelent. Hasonlo, de mast jelent.
- A hozzászóláshoz be kell jelentkezni
Te meg nem lattal valodi MVC-t desktop alkalmazasban, Observer patternnel megvalositva
de láttam, és a fentebb felsorolt javascript frameworkök pontosan ezt csinálják. Pontosan ezért preferálom ezeket, mert rendes UI architektúrát eredményeznek, és nem találják fel újra a kereket, hanem a klasszikus desktop MVC rendszert valósítják meg, csak más nyelvi/technológiai környezetben.
A struts-szerű szerver-oldali MVC (amit átvett kb az összes PHP framework) tényleg nem sokban hasonlít a desktop MVC-re (max. annyiban, hogy van benne M meg V meg C), de most nem erről van szó.
Es ne keverjuk az n-tier architekturat meg az MVC-t, mast jelent. Hasonlo, de mast jelent.
ilyenről szó sem volt
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
"de láttam, és a fentebb felsorolt javascript frameworkök pontosan ezt csinálják."
Oh, tehat kepesek arra, hogy ha az adatmodell modosul, akkor minden kliens azonnal kapjon rola ertesitest. Peldaul van egy egyszeru szamlalo, nevezzuk online userek szamanak. persicsb beloginol, es ekkor mindenki azonnal, felhasznaloi interakcio nelkul latja, hogy nezd mar, 5 helyett 6 user van online?
Mert en ilyet meg nem lattam. 1-1 kliensre mukodik az, hogy egy felhasznalo altal kezdemenyezett HTTP roundtrip alapjan frissulnek az oldal elemei, de erre keretrendszert meg nem lattam. A periodikus polling pedig nem MVC.
- A hozzászóláshoz be kell jelentkezni
Oh, tehat kepesek arra, hogy ha az adatmodell modosul, akkor minden kliens azonnal kapjon rola ertesitest
félreértettél. Csak JS-ről beszéltünk, tehát ha egy adatelem változik, akkor az azt reprezentáló UI elem is változik (kap eseményt) böngészőn belül.
A szerver-kliens kommunikációt nem érinti a dolog. Én Hevi-nek a "js = taknyolás" felvetésére reagáltam, hogy vannak már normális JS MVC keretrendszerek. Az más kérdés, hogy ezek nem oldják meg a webfejlesztés összes problémáját.
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
"ha egy adatelem változik, akkor az azt reprezentáló UI elem is változik "
Es ez hol a feneben MVC? Ez egy alap dolog minden alkalmazasban :)
Adatelem az is, amit a szerver a sajat allapotabol allit elo az oldalon.
Pont webes 'alkalmazasoknal' szokas azt emlegetni, hogy a szerveroldalon van az allapot, egy helyen, es te akarhonnan belepsz, ugyanazt latod, mert nem a geped tarolja az allapotot. Erre varj gombot.
Ertsd meg, weben valodi MVC-t a HTTP half-duplex jellege miatt nem lehet csinalni.
- A hozzászóláshoz be kell jelentkezni
Es ez hol a feneben MVC?
miért, akkor az observer-megközelítés alatt te mit értettél?
más: az MVC az nem alkalmazás-architektúra hanem GUI architektúra. Ha nekem a javascriptes felületem MVC szerint működik, akkor az MVC.
mégegyszer: maradjunk a "csak js" kontextusnál, http meg szerver nem igazán érdekel
Pontosabban, a kliensoldali adatmodellemet megfelelő felhasználói interakció esetén (save gomb onclick, akármi) szinkronizálom a szerver-oldallal, de ettől még a GUI adatmodellje mindig a böngészőben marad. Mi is maradjunk ott, mert ez volt a vitaindító. A "weben valodi MVC-t a HTTP half-duplex jellege miatt nem lehet csinalni" dologgal természetesen tisztában vagyok, de - immáron harmadjára - pls maradjunk a kliensoldalon.
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
A weben nem létezik olyan, hogy csak kliensoldal. Ha létezne, léteznének offline is működő webes alkalmazások, azonban pont az a mondás, hogy mivel az alkalmazás a szerveren van, egyszerűbb frissíteni, minden user azonnal a legfrissebb változatot látja, nem kell külön kliensoldali update-mechanizmusról gondoskodni stb.
"miért, akkor az observer-megközelítés alatt te mit értettél?"
Az Observer csak előfeltétele az MVC-nek, de máshol is jó.
"maradjunk a "csak js" kontextusnál, http meg szerver nem igazán érdekel"
Akkor az nem webes alkalmazás. Én is tudok olyan, kizárólag JS-sel működő HTML oldalt készíteni, aminek nem lesz köze a HTTP-hez, a user szépen megnyitja lokálisan, file:// protokollal és örül. De akkor az nem webalkalmazás. Gondolj egy lokális, intelligens súgóra. Abban hol van meg a webalkalmazások összes előnye? A központi frissítést szokták nagy előnynek tekinteni.
- A hozzászóláshoz be kell jelentkezni
Akkor az nem webes alkalmazás.
szemléld másképp a dolgot: van egy kliensoldali javascriptes mvc kisalkalmazásod (egy felület), ami kommunikál egy szerver-oldalon futó webservice-el (jellemzően json alapú), amit különálló alkalmazásként kezelsz. Én arra szerettem volna rámutatni, hogy a kettő közül a kliensoldali alkalmazásban megvalósítható normális, letisztult, desktop-szerű mvc architektúra, innentől kezdve a "js taknyolás"-ról van szó. Ennyit mondtam, semmi többet, és ebben szerintem igazam van.
Te azt mondod, hogy attól, hogy a kliensoldalon van MVC, attól még az egész együtt nem lesz normális MVC. Ebben meg neked van igazad.
Ámen
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
Itt azért még hozzátenném, hogy a kliensoldali kód csak akkor tud a szerver-oldali WS-sel kommunikálni, ha az a kliensoldali kód is ugyanonnan származik, a Same Origin Policy miatt. Persze most már ennek a security képességnek a kikerülésére is vezetnek be új 'szabványokat', mint Cross-Domain Resource Sharing és társai, de ez meg méginkább jelzi a böngészőalapú alkalmazások esetében azt, hogy a taknyolás bizony helyes kifejezés.
- A hozzászóláshoz be kell jelentkezni
Same-origin policy-ről tudok, de ritkán szokott zavaró lenni (legalábbis nekem eddig ritkán volt az).
A fenti megközelítésnek (js mvc + json ws) egyébként van egy olyan előnye is, hogy az lesz belőle, hogy minden, amit a szerver-oldali alkalmazásod tud, elérhető nem csak a kliensoldali js app számára, hanem más alkalmazások számára is, így veszettül könnyen integrálható lesz. Ez ugyanaz az elv, mint mikor egy c program úgy van megírva, hogy függvénykönyvtárként is használható meg van hozzá egy parancssoros frontend is. Ugyanezt az ötletet alkalmazzuk ebben az esetben, csak weben. Ez nekem veszettül bejön =)
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
Nem tudnátok ezt a péniszlengetést máshol folytatni? Kurvára nem érdekel senkit, hogy ki mit látott és az mekkora volt.
- A hozzászóláshoz be kell jelentkezni
Úgy néz ki, a Firefox új JS motorja sem érdekel senkit. Vagy esetleg te tudsz a témához valamit?
- A hozzászóláshoz be kell jelentkezni
alert(window.atob('RWzpZyBsZXN6'));
- A hozzászóláshoz be kell jelentkezni
Az a faszlengetés sem a témához tartozik, amit itt folytattok.
- A hozzászóláshoz be kell jelentkezni
Neked minden taknyolás ugye amit nem lehet egy sorral elintézni? :)
- A hozzászóláshoz be kell jelentkezni
Vagy akkor legalább valami normális OOP/komponens gyártási lehetőség legyen már.
HTML esetén is baromira zavar, hogy nem tudok egyszerűen önálló komponenseket gyártani.
- A hozzászóláshoz be kell jelentkezni
Hogyne tudnál. Külön HTML fileok, amiket iframe-ként beemelsz mindenhova. Szükség esetén a HTML file-nak paramétert is megadhatsz, amit a fileban található JS dolgoz fel. Persze mivel beépített funkcionalitás nincs arra, hogy a megadott oldal query paramétereid elérd, ezért itt is taknyolni kell.
Szép, nem? :)
- A hozzászóláshoz be kell jelentkezni
ha egy egyszerű komponens-modellt nem tudsz összehozni kb tetszőleges szerver-oldali technológiával, akkor lehet nem a rendszerben van a hiba.. ;)
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
Döntsd már el, hogy szerveroldal vagy kliensoldal közül melyik az, ami igazán olyan jó. Mert ha csak szerveroldalon tudsz normális komponenseket kialakítani, akkor az előbbi beszélgetésünk, ami a kizárólagos kliensoldali MVC-ről szólt, megintcsak értelmét vesztette. Döntsd el, hogy akkor most a webes alkalmazás működik-e szerveroldal nélkül, vagy nem.
- A hozzászóláshoz be kell jelentkezni
szerver-oldali komponenseket lehet fejleszteni elég egyszerűen, de nem mindig érdemes ebbe az irányba indulni.
Egy kliensoldali komponensmodellt macerásabb épkézláb módon megtervezni, de ez is megoldható.
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
Valami ilyesmire gondoltam.
Amivel ilyeneket tudok a későbbi kódomba írni:
<MyComp:StateComboBox maxChars="25"
close="handleCloseEvent(event);"/>
- A hozzászóláshoz be kell jelentkezni
akkor sztem a knockout.js és az angular.js háza táján nézz körül
--
CyclonePHP
- A hozzászóláshoz be kell jelentkezni
ilyet simán csinálhatsz most is, nem tudom láttad-e a facebook like gombját amit kell html-be illeszteni. Vagy lehet nem pontosan így...
- A hozzászóláshoz be kell jelentkezni
Mi extjs-t használunk, és egész jól konvergál ahhoz, amire rá lehet mondani h használható.
- A hozzászóláshoz be kell jelentkezni
++;
- A hozzászóláshoz be kell jelentkezni
Közben felmerült bennem a kérdés, hogy miért para ha afelé haladnak a böngészők, hogy képesek legyenek a flash player képességeit pótolni? A flashban nem az volt a rossz, hogy gazdag ui-t lehetett vele csinálni, hanem az ahogy muzsikált teljesítmény szempontjából, az, ahogy elzárja a tartalmat a keresők elől, az hogy nem free...
- A hozzászóláshoz be kell jelentkezni
Jópár esetben nem is volt baj, hogy nem tudtak vele mit kezdeni a keresők, gondoljunk például a flashjátékokra. Azért meg kár volt erőltetni a html5-öt, hogy most abban csináljunk olyat, amiben nem talál semmi érdekeset a kereső. A fullflash oldalak nekem se tetszettek, de mindent lehet szarul is, meg jól is csinálni. A többi felvetésbe nem tudok belekötni.
- A hozzászóláshoz be kell jelentkezni
Btw, a JavaScript önmagában is egy elég csúnya, gusztustalan nyelv és jelenleg valahol az ActionScript 2.0 környékén tanyázik, amit már ugye évek óta leváltott a végre rendesen használható 3-as verzió.
- A hozzászóláshoz be kell jelentkezni
Miközben mások arról áradoznak mennyire szép és kényelmes nyelv. Szerintem ez szubjektív :)
- A hozzászóláshoz be kell jelentkezni
Új motor, új bugok. Ráadásul a telepítését átlaguser nem is fogja elhalasztani mert települ kérdés nélkül. De jó is lesz...
--
Gábriel Ákos
http://i-logic.hu
- A hozzászóláshoz be kell jelentkezni
Ehhez kell az emberi zsenialitás, hogy alkossunk egy szinte teljesen optimalizálhatatlan dinamikus nyelvet, majd a legragyogóbb elmék összes erőforrását arra pazaroljuk, hogy megpróbálják ezt optimalizálni :-).
- A hozzászóláshoz be kell jelentkezni