WEB 2.0
Hosszú lesz.
Tegnap elolvastam, hogy a PHP halálra van ítélve. Azt hittem valami klikkvadász bulvár hír, de marhára megfogott és nagyon igaza van.
Emellett kavargott még a fejemben, hogy létezik Node.js ami aszinkron elvekre épül, és nem értjük, hogy mire jó ez. kemma épp a REST-ről kérdezgetett.
Mindeközben mindennapi munkám során elmozdultam olyan irányba, hogy amit tudok kliens oldalon csinálok meg, és tényleg a szerver csak küldjön nekem adatot, meg dolgozza fel amit küldök neki. HTML-t generálok inkább kliens oldalon, amíg csak azon küzd a júzer, hogy a szervernek elküldhető adathalmaz létrejöjjön, nem röpködnek a http kérések.
ez volt a bevezető.
egyre inkább úgy gondolom, hogy ha mondjuk MVC alapokon gondolkodunk, akkor nem annyira egyértelmű, hogy mind a három összetevőnek a szerver oldalon kell futnia. sőt azt gondolom, hogy V (megjelenítés, felület előállítás) és C (események kezelése) komponenseknek inkább a kliens oldalon van a helyük, sőt azt sem tartom extrém dolognak, hogy a adott esetben az üzleti logika (egy része) is futhat kliens oldalon, aztán ha kell szinkronizál a szerverrel (van erre példa).
lesz aki megöl ezért :), de szerintem semmi akadálya, hogy asztali alkalmazásokat hozzunk létre HTML, CSS, JS alapon. annyi hogy a kódbázist, ha épp nincs meg a szervernek el kell küldenie. Nem is kell az egész csak épp az amire szükség van.
és itt jönnek képbe a bejegyzés elején említett dolgok. semmi szükség rá, hogy a szerver oldali folyamatok felhasználó alapon fussanak (1 felhasználó (kérésenként, legalább) egy külön process). Rögtön értelmet nyer az aszinkronitás, a REST elvek.
És akkor belegondol az ember, hogy atyaég mennyit szopattam magam, hány wattot elpazaroltam..
és csinálja tovább azt amit eddig :)
felébredt a kislányom, úgyhogy szerencsétek van, abbahagytam.
..az a kérdés azért felmerült, hogy ha ennyi mindent kitolok kliens oldalra, akkor hogyan tudom megvédeni a létrehozott terméket a konkurensektől (legalábbis HTML, JS, CSS alapokat használva)
■ Tegnap elolvastam, hogy a PHP halálra van ítélve. Azt hittem valami klikkvadász bulvár hír, de marhára megfogott és nagyon igaza van.
Emellett kavargott még a fejemben, hogy létezik Node.js ami aszinkron elvekre épül, és nem értjük, hogy mire jó ez. kemma épp a REST-ről kérdezgetett.
Mindeközben mindennapi munkám során elmozdultam olyan irányba, hogy amit tudok kliens oldalon csinálok meg, és tényleg a szerver csak küldjön nekem adatot, meg dolgozza fel amit küldök neki. HTML-t generálok inkább kliens oldalon, amíg csak azon küzd a júzer, hogy a szervernek elküldhető adathalmaz létrejöjjön, nem röpködnek a http kérések.
ez volt a bevezető.
egyre inkább úgy gondolom, hogy ha mondjuk MVC alapokon gondolkodunk, akkor nem annyira egyértelmű, hogy mind a három összetevőnek a szerver oldalon kell futnia. sőt azt gondolom, hogy V (megjelenítés, felület előállítás) és C (események kezelése) komponenseknek inkább a kliens oldalon van a helyük, sőt azt sem tartom extrém dolognak, hogy a adott esetben az üzleti logika (egy része) is futhat kliens oldalon, aztán ha kell szinkronizál a szerverrel (van erre példa).
lesz aki megöl ezért :), de szerintem semmi akadálya, hogy asztali alkalmazásokat hozzunk létre HTML, CSS, JS alapon. annyi hogy a kódbázist, ha épp nincs meg a szervernek el kell küldenie. Nem is kell az egész csak épp az amire szükség van.
és itt jönnek képbe a bejegyzés elején említett dolgok. semmi szükség rá, hogy a szerver oldali folyamatok felhasználó alapon fussanak (1 felhasználó (kérésenként, legalább) egy külön process). Rögtön értelmet nyer az aszinkronitás, a REST elvek.
És akkor belegondol az ember, hogy atyaég mennyit szopattam magam, hány wattot elpazaroltam..
és csinálja tovább azt amit eddig :)
felébredt a kislányom, úgyhogy szerencsétek van, abbahagytam.
..az a kérdés azért felmerült, hogy ha ennyi mindent kitolok kliens oldalra, akkor hogyan tudom megvédeni a létrehozott terméket a konkurensektől (legalábbis HTML, JS, CSS alapokat használva)
webkettő
A HTML nagyon jó megjelenítésre, de adattárolásra, amire használjuk, pocsék. Szét kéne választani az adatokat és a megjelenítést, és akkor jóval hatékonyabban lehetne dolgozni, az MVC-ből maradna MC, és azt, hogy hogyan jelenítjük meg a dolgokat (V), az legyen mindenkinek a magánügye. Akár weboldal, akár animáció, akár játék formájában, mindegy, csak nem egyedül a HTML-re kell építkezni.
A jelenlegi trendek és szabványok ebben nem feltétlenül segítenek, pedig erre van leginkább igény (te is ezt fogalmaztad meg, ugye). Az AJAX-os bejegyzésemben is felmerült, hogy a programozók (és talán a felhasználók is) már nem egyszerű weboldalakat, hanem weblap-alkalmazás-öszvéreket szeretnének készíteni, amihez egyszerűen nincs meg a normális támogatás. A szabványkészítők (Google, Apple) a saját szekerüket tolják, a saját érdekeiket nézik, ami nem feltétlenül ugyanaz, mint a nagy többségé.
Ezen úgy lehet segíteni, hogy a saját kezünkbe vesszük az irányítást, és mi alakítjuk a sorsunkat. A múlt nem változtatható meg, de a jövő igen.
webalkalmazás -html -css
Ne keverjük a dolgokat!
Az, hogy a scriptből építjük fel az oldalt nem jelenti, hogy nem a HTML oldalt építjük fel scriptből.
tudom én, de…
Nem kötelező
Létezik ingyenesen elérhető kezdeményezés ami egyébként ezt csinálja Zebra UI néven, vagy ottvan lively kernel néven futó project ami együtt használ szokásos html (divek), canvas és svg elemeket mindezt úgy, hogy neked csak js-t kell kódolnod. Érdemes megnézni tavalyi jsconf előadást róla (a smalltalk féle object browsert viszont látni eleve egy hallatlanul izgalmas dolog).
Ehhez hasonló elképzelést valósít meg GTK+ Broadway bár a háttérben nem a böngésző futtatja az alkalmazást, csak megjeleníti.
HTML
Meg JS-re sincs szükség
Az üzleti logikát meg leginkább lefordított bájtkódban lehet elrejteni, ha a kliensnél kell. Itt tehát nem is szabad JS-ezni.
A natív alkalmazások
Adatot kér(het)nek onnan
Kérhetnek, de az
Miért érdekes ez?
Csak annyiban releváns, hogy
Nézőpont
Szerintem akkor is webről beszélünk, ha a Júzer nem látja az URL-t (olvasva többi kommentedet), nem is érdekli, hogy van-e URL vagy nincs, működjön a dolog (jól és gyorsan), amit akart és kész.
Natív alkalmazások
Egy weboldalt felfoghatnánk adatgyűjtőnek is, a weblabor például cikkgyűjtő, fórumgyűjtő, csiripgyűjtő stb. Itt adatok kapcsolódnak adatokhoz (például Joó Ádám hozzászólásai, Galiba Péter cikkei), nem dokumentumok dokumentumokhoz. Egy dokumentum szükségszerűen statikus (ha nem hiszed, végy a kezedbe egy újságot), ráadásul a dizájn bele van égetve. De voltaképpen egy gépet, egy adatgyűjtő robotot hol érdekli, hogy mi hogyan néz ki? Miért terheljük ezzel? Miért kell az adatokat dokumentumszerűen mindig úgy megjeleníteni, ahogy a dizájner elképzelte? Miért ne jeleníthetné meg őket egy natív alkalmazás? Akkor az már nem a web része, még akkor sem, ha onnan veszi az adatokat? Egy WebGL-t használó alkalmazás az miben különb a natívnál? Miért vagyunk a böngészőhöz kötve? Egy emailt is nézhetek a böngészőben meg Outlookban, ugyanúgy email marad.
Miben különbözik egy weboldal egy kőkorszaki barlangrajztól? Más a médium, de az elv az ugyanolyan primitív. Ennyit tudunk felmutatni a XXI. században?
Az van rajta a weben, aminek
Nem értem miért jössz mindig
Ugyanakkor pár napja pont a REST-ről voltál kevésbé jó véleménnyel (vagy nekem nem jött át rendesen a véleményed). Holott a REST (és úgy általában a hozzá hasonló service központú megközelítések) pontosan az, amit te is szeretnél. A szerver kicsit pongyolán fogalmazva a kliens szemszögéből nem más, mint adat és azt előállító, feldolgozó üzleti logika gyűjtemény. Hogy a kliens egy js alkalmazás, vagy egy natív alkalmazás, az tökmind1. Vagyis architektúra szintjén is komolyan szétválik a V az M és C-től.
Böngésző meg azért kell, hogy legyen egy valemennyire egységes értelmező környezet, ami a szerverből kieső tartalmat az ember arcába tolja. Más se kéne, minthogy vissza kelljen térni a natív alkalmazásokhoz, ha már webről beszélünk :)
HTML
A HTML, doc, pdf és társaik mind egyívású, múlt századi eredetű statikus dokumentumok, az utóbbiak legjobban akkor néznek ki, ha kinyomtatjuk őket. A HTML csak annyiban több, hogy linkek segítségével könnyedén ugrálhatunk ide-oda. No, és akkor mi van? A lényegen nem változtat.
Nem kell visszatérni a natív alkalmazásokhoz, de szerintem nem a mi dolgunk eldönteni, hogy milyen formában nézzék meg az adatainkat a látogatók, legfeljebb mankót adhatunk hozzá (például írunk egy alkalmazást vagy készítünk HTML-t).
A HTML a web spagettikódja, pont ez, amitől már évekkel ezelőtt megszabadultak a jobb helyeken:
<table>
<?php for ($i = 0; $i < 10; $i++) { ?>
<tr>
<?php for ($j = 0; $j < 5; $j++) { ?>
<td><?php print $tomb[$i][$j]; ?></td>
<?php } ?>
</tr>
<?php } ?>
</table>
Az általad felvetett
Egyszerű szerver architektúra: statikus fájlok kiszolgálása (css, képek, és html sablonok), gyors JSON-ös REST API, azaz kb zéró szerver oldali logika.
Kliens architektúra: A megfelelő adatok lekérése (AJAX-on keresztül, de lehetne Websocket is) a REST API-val, majd az adatok megjelenítése valamilyen kliens oldali MVC alkalmazáson keresztül.
Előnyök: A szerver alá bármilyen kliens alkalmazást be lehetne tolni, akár natívat is! A formátum univerzális, könnyen parseolható, a szerver csak olyan erőforrást ad vissza, amilyenre a kliensnek szüksége van.
Hátrányok: A megoldás a kliens technológiáira alapoz, aminek a megléte egyáltalán nem garantált (megfelelő odafigyeléssel lehet írni jó fallback megoldásokat, a kikapcsolt JS-t meg 2013-ban el kell felejteni). A keresők valószínűleg kiesnek a buliból (ezzel őszintén szólva nem foglalkoztam, de felteszem erre is van megoldás).
+1
ez adott esetben lehet több szál is, a lényeg annyi, hogy a szerver oldali processzek nem per kérés indulnak, állnak le, hanem vannak.
WSDL
A WSDL nyelvfüggetlen, tehát a szerveroldali szolgáltatás használható akár egy "natív" telefonos alkalmazással vagy beépülő API-ként ha egy másik szolgáltatás szeretne kapcsolódni a mienkhez.
A baj, hogy a szép elvek ellenére igen kevés kész eszköz támogatja. A Java ökoszférán kívül elég nehéz dolga akad annak aki belevág. Az Apache-féle CXF-en kívül nem találni mást ami segíthet a JS-beli klienst elkészíteni, ebből pedig hiányoznak esszenciális funkciók.
A WSDL-lel nekem az a
Pont ellenkezőleg
Persze minden eszközt érdemes ár/érték arányban vizsgálnunk. JSON-t lehet hogy egyszerűbb kézzel írni, de az XML cserébe sokkal hibakereshetőbb, és flexibilisebb (namespace-ek). Amúgy a WSDL2-vel elvben leírható JSON is akár.
Javához több eszköz van, de ez nem jelenti azt, hogy a WSDL jobban működne azzal a nyelvvel mint bármelyik másikkal. Gondoljunk csak az ORM-re, ami a Hibernate volt, aztán szép lassan átszivárgott a PHP világába.
Az alapgondolat itt nem XML vs JSON, hanem, hogy a kliens-szerver kommunikációt egy külön layer végzi. A kommunikáció (XML sémának köszönhetően) bármelyik ponton validálható. Egy rosszul formázott kérés (pl verzió-eltérés miatt) azonnal kibukik, nem gyűrűzik tovább. (Amit aztán kézzel követhetünk vissza).
Off:
Persze hogy van élet az enterprise eszközökön túl. De itt Weblaboron szerintem az ellenkező pontnak kéne kicsit több hangot adni. "Nem csak PHPban lehet webalkalmazást készíteni.. sőt".
Végre
A gondot az okozza, hogy XML-ben lehet sémákat és egyéb hasonlókat használni, amitől terjengőssé, bonyolulttá fog válni, és szerintem szükségszerűen bukni fog a dolog, amint azt láttuk az XHTML esetén. Ezek a technológiák segíthetnek, de nem feltétlenül, úgy látom, minél egyszerűbb a kimenet, annál jobb.
+1
Pont ezt akartam írni én is. :D
Amíg nem kellett típusos nyelven készített alkalmazással kommunikálnom, nem gondoltam ezt fontos pontnak, amióta csak ilyen környezetbe mozgok, az XML/XSD páros előnyt élvez a kommunikáció során a JSON-nal szemben.
pp
A JSON-hoz is készül az IETF
Mutatsz rá eszközt? Mert én
pp
Nem tudok, elhiszem, ha azt
Feladathoz eszközt
Amikor olyan projektben vagy benne, amikor két külön csapat fejleszti a két felet, az egyik PHP-ban a másik Java-ban, akkor jön elő az XML/XSD előnye. Eltér a fejlesztési ritmus. A kész verziókat egy harmadik, infrastruktúrás csapat teszi ki tesztbe, majd élesbe. Na ilyenkor jól jön, hogy már ők is tudnak riportolni arról, hogy hol lehet a hiba. Nem beszélve arról, hogy az adatok ellenőrzését(kötelezően van-e, szám-e, szöveg-e, stb.-e) is nagymértékben meg tudod könnyíteni.
Az, hogy több nyelvre/fejlesztőkörnyezetre elérhető eszköz a validálásra, nagymértékben megkönnyíti a közös munkát.
Ugyan úgy, ahogy egy sikeres db_query után sem kell vizsgálod, hogy a SELECT és FROM közötti mezők kulcsai elérhetőek-e az eredményben, itt se kell aggódnod azon, hogy vajon egy kötelező mező megvan-e. Szemben a JSON-al, ahol hiába írja kötelezőnek a doksi egy elem létét, nem lehetsz biztos abban, hogy ott is van.
pp
A fentiekkel kapcsolatban
„Minél öregebb vagyok, annál jobban értékelem az erősen típusos nyelveket. Minél többet dolgozom gyengén típusos nyelvekkel, annál jobban öregszem.”
XML
fa['ág']['attribútumok']['attribútum']a következő XML-ből:<ág attribútum="érték" />
</fa>
Pedig kb. egyidősek, a JSON
Szerintem jóval fiatalabb szabvány. A DOM fa egyébként jelenleg is könnyen bejárható JavaScripttel (mondjuk az általad felvázolt megoldás hibás, hiszen a fa tetszőlegesen sok ágat tartalmazhatna)
Igaz
Igen, a JSON története
A DOM fa egyébként jelenleg
A könnyen és a triviálisan között szerintem elég jelentős a különbség. És ha megkérdezed a legtöbb fejlesztőt, hogy melyiket járja be szívesebben, vagy csak választ ki egyetlen értéket, valószínűleg a JSON nyerne.
Nem az XML kiemenet
Overhead
Egy azonos neylvben írt XML és JOSN parser sebessége között nem hiszem, hogy számottevő lesz a különbség (a "heavy lifting" része mindkét esetben a memória-menedzsment, nem a string darabolás).
Ha akarod az XML-t is használhatod mezitlábasan, XSD nélkül.
WSDL
targetNamespace="http://example.com/stockquote/definitions"
xmlns:tns="http://example.com/stockquote/definitions"
xmlns:xsd1="http://example.com/stockquote/schemas"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
Mi hasonlót használunk, csak JSON-ban, mindenféle felesleges sallang nélkül, magára az alkalmazásra kihegyezve. Ha cél lenne, hogy mások is értelmezzék az adatokat, akkor talán XML segítségével kommunikálnánk, és megjelölnénk valami egyszerű módon, hogy melyik adat mit jelent.
Namespace
Egy éles fejlesztésben nem is látod ezeket a dokumentumokat. Kész kód generálja le őket a kliensoldalon, a szerveroldalon meg egy másik csomag dekódolja. Az alkalmzásod már objektumokat lát, amik lehetnek publikus adattagokkal vagy getterrel/setterrel működők.
Ha megnézel egy helloworld példát az Apcache CXF-re (ami amúgy nem tartozik a kedvenc implementációim közé) ott láthatod, hogyan interaktálsz alkalmazásban egy szervízzel. (És nem része az, hogy kézzel XML-t geenrálsz).
A beidézett kódrészletet kicsit demagógnak érzem. Azt sem rójuk fel, hogy milyen nehéz egy TCP sessiont létrehozni és mennyi fölösleges dolog van benne... mert természetes, hogy az alkalmazáslogikánk alatti infrastruktúra megoldja. - A célodat nem értem pontosan a linkeléssel.
A linkelt részlet amúgy nem tartalmaz validációs szabályokat. Ezek csak namespace-ek, (amiket XML-ben URL-ek azonosítanak). Éles helyzetben a SOAP szabályokat a szerializálásért felelős csomag ellenőrizné, az example.com-hoz tartozó sémák pedig nyilván elérhetők, hiszen azok elvileg az alkalmazásod részei.
Szerintem a nagy félreértés, hogy ezt kézzel kellene összerakni. (Mint ahogy egy jól megtervezett rendszerben a JSON-t sem kézzel készítjük).
WDSL
Tehát a feltevésem az, hogy most ugye nem ehhez vannak az emberek szokva. A HTML eleve egy nagyon megengedő nyelv, lehet hibázni benne, a böngészők kijavítják, és sokan élnek is ezzel a lehetőséggel. Egy weboldalt elég könnyű összedobni, a neten millió tutorialt lehet találni, ami segít az elindulásnál.
Tehát a belépési küszöb alacsony, viszont ti meglehetősen magasra tettétek a lécet ezzel a WDSL-lel. Lehet ez a végcél, nekem nincs tapasztalatom vele, így elfogadom azt, amit állítotok, de kisebb lépésekben kell haladni, különben továbbra is csak csúcscégek eszköze marad. Továbbá többször is említed, hogy nem kézzel kell összerakni ezeket az XML-eket, az is kérdés, hogy létezik-e olyan eszköz, ami elérhető (árban), és kezelhető is egy átlagos fejlesztő számára? Fontos, hogy bárki tudja használni, különben csak álom marad.
A Visual Studio Express
Gondolom Java-ra hasonló eszközök érhetőek el.
desktop applikáció HTML, CSS alapokon
Sztem a WEB 2.0 olyan mint
Most már csak azt árulja el
Hát most ránéztem a W3C
Nekem ebből az jön le hogy ők se tudják mi az a WEB.
Én úgy gondolom hogy az USA amikor kifejlesztette ezen a néven titkosította az aktát, hogy az oroszok ne találjanak rá könnyen. Ez lehetett a Web [Top Secret], és azé találtak rá ki egy szót, hogy senkinek fogalma se legyen róla mi is ez. :D
Az irónia a csupa nagybetűnek
(A webet pedig a „svájciak” fejlesztették ki.)
Ja közbe már eszembe jutott h
(De az USA pénzén :D)
De az USA pénzén :D A CERN
A CERN teljes egészében európai szervezet :)
Most jut eszembe igazad van,
(én kérek elnézést :D)