Javascript – Reiter István – .NET blog

WebPack(olás) Numero Uno

reiteristvan — Mon, 01 May 2017 16:19:06 +0000

Pár hete “kicsit” elgurult a gyógyszerem, minek eredményeként az alábbi képen látható kirohanás keletkezett. A véleményemet továbbra is tartom (mindjárt leírom majd, hogy miért), de a helyzet az, hogy ha továbbra is akarok frontend fejlesztéssel foglalkozni (márpedig akarok), akkor kénytelen leszek WebPack ~~ninja~~ ~~rockstar~~ SITH LORD lenni.

Persze ettől még elég távol állok. Na szóval, térjünk vissza az ominózus kirohanásomra (elég explicitre sikerült ):

Ahhoz, hogy megértsük, hogy honnan jött ez az egész kicsit felejtsük el a frontendet és nézzük meg az elsődleges skillemhez (C# fejlesztés) kapcsolódó fejlesztői élményt. Visual Studio megnyit, New Project, .NET verzió beállít, Ok, kész. F6, lefordul. Ha adok a projekthez külső függőséget akkor is lefordul. Ha több projektre szedem szét a solution-t akkor is lefordul. Persze könnyű dolga van az IDE-nek, hiszen ami lefordul abból egy csinos kis bináris lesz ami leírja önmagát, így a Visual Studio tudni fogja, hogy merre hány lépés. Nyilván itt is vannak olyan esetek amikor szív az ember, de ez mondjuk az esetek fél százalékának a fele. Pedig tulajdonképpen a folyamat maga egyáltalán nem egyszerű, csak a Microsoft-nál ülő emberek tudják, hogy ha feleslegesen megbonyolítják a dolgot akkor nehéz lesz új fejlesztőket a platformra hozni, ezért mindent megtesznek, hogy a fejlesztői élmény kiváló legyen és a programozó csak a dolgával törődhessen. Ennek meg is van az eredménye, hiszen a Visual Studio a butaságaival együtt is az egyik legnépszerűbb (ha nem A legnépszerűbb) IDE a világon.

És akkor itt van a frontend fejlesztés ahol ugye rögtön nehezíti a dolgunkat, hogy olyan technológiával akarunk alkalmazást írni amit nem igazán erre találtak ki (értsd: HTML + JavaScript + CSS). Ami még rosszabb az az, hogy a platformra (böngésző) nincs egyetlen szervezetnek valós ráhatása, illetve ha lenne is, drasztikusan átformálni szinte lehetetlen, hiszen nem húzhatjuk ki a létező megoldások alól a talajt.

Így aztán az történik, hogy megpróbálunk ruhát adni a szarra, szépen kidíszitjük és próbáljuk elfelejteni, hogy azért így is büdös. Ennek az eredménye a HTML5, a CSS3, a különböző MVVM frameworkök, a TypeScript, az új ECMAScript verziók és sok más amit nem fogok felsorolni.

El is érkeztünk a lényeghez: ahhoz, hogy ez a sok jó cucc működni tudjon mindenféle mágia szükséges ami egybetartja az egészet. Sajnos a mágia világában is a trendek uralkodnak, ennek megfelelően nagyjából kétévente új fasza gyerek jelenik meg a színen: korábban volt a Grunt, majd a Gulp amelyek többé-kevésbé fícsőr parity-ben voltak, majd megjelent a WebPack ami már lényegesen többet tudott náluk (dependency feloldás pl.). Itt egy jó kis összehasonlító írás: link.

A felsorolt eszközökben van egy közös pont: mindegyik open source. Ami egyébként hatalmas királyság, határozottan támogatok mindenféle open source törekvést. Viszont, mivel ezeket az eszközöket egy mindentől független közösség fejleszti, általában nem főállásban ezért a minőség ingadozó lehet. Ezzel együtt is minden tiszteletem ezeké a fejlesztőké, de a WebPack esetében például jól látható, hogy van egy innovatív, sokrétű termék, amit viszont túl nagy erőfeszítés úgy bekonfigurálni, hogy igazán jól működjön. A dokumentáció hiányos vagy már nem érvényes információt tartalmaz és végeredményben komoly mennyiségű időt kell ráfordítani arra, hogy felépítsük a fejlesztői környezetet.

Na de elég a nyavajgásból, csapjunk a lecsóba! Ebben a posztban teljesen az alapoktól fogunk építkezni, egyelőre bármiféle csicsa nélkül, vagyis: legyen dependency feloldás, bundling és minifikáció. Ez nem sok, de tanulságos.

Kezdjük a szokásos npm init-tel:

Majd ha ez megvan hozzuk létre az alábbi mappastruktúrát:

Az ‘app’ tartalmazza majd a javascript forráskódot, az assets-ben a saját CSS definíciók illetve képek lesznek, a dist pedig a bundle kimeneti mappája. Az ‘index.html’ végtelenül egyszerű lesz:



    
        WebPack Demo Application

Természetesen mivel a bundle.js még nem létezik ezért böngészőben megnyitva konzolhiba lesz a jutalmunk meg persze a nagy büdös semmi Csináljunk is egy app.js nevű file-t az app mappába:

function createComponent(){
    var contentDiv = document.getElementById('content');
    contentDiv.innerHTML = 'Hello WebPack!';
}
createComponent();

Nem egy nagy tudomány, de a célnak megfelel. A következő lépésünk, hogy telepítjük a WebPack-et: ‘npm i –save-dev webpack’ . Ezután készítsünk egy webpack.config.js nevű filet a package.json mellé, ez az amit a WebPack alapértelmezetten keresni fog:

var path = require('path');

module.exports = {
    entry: './app/app.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    }
};

Meglehetősen egyértelmű, hogy mi történik, az ‘entry’ szekció tartalmazza azt a filet ahonnan a függőségi gráf kiépítése indul, az output szekció pedig a kimeneti célt tartalmazza. A ‘__dirname’ környezeti változó az aktuális könyvtár elérési útja. Ha most lefuttatjuk a ‘webpack’ parancsot a könyvtárban, akkor el is készül a bundle:

És a böngészőben is minden úgy működik ahogy szeretnénk:

Folytassuk CSS fileokkal, ezekből is szeretnénk egy bundle-t csinálni. Az ‘assets/css/’ mappába készítsünk egy ‘main.css’ nevű filet a következő tartalommal:

div {
    background-color: red;
}

Egészítsük ki az index.html-t is kicsit:



    
        WebPack Demo Application

Telepítsük a szükséges csomagokat az npm segítségével: ‘npm i –save-dev css-loader extract-text-webpack-plugin’.

Ahhoz, hogy a WebPack megtalálja a CSS fileokat azokat be kell importálni függőségként, adjuk is hozzá ezt az ‘app.js’-hez:

import '../assets/css/main.css';

function createComponent(){
    var contentDiv = document.getElementById('content');
    contentDiv.innerHTML = 'Hello WebPack!';
}

createComponent();

Most pedig egészítsük ki a webpack.config.js-t, hogy a CSS fileokat is feldolgozza:

var path = require('path');
var ExtractTextPlugin = require('extract-text-webpack-plugin');

module.exports = {
    entry: './app/app.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    module: {
        rules: [
            {
                test: /\.css$/,
                use: ExtractTextPlugin.extract({ use: 'css-loader' })
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin('styles.css')
    ]
};

Ha lefuttatjuk ismét a ‘webpack’ parancsot már egy fokkal bőbeszédűbb lesz:

És persze a böngésző is reflektál a változásokra:

Mi van akkor, ha valamilyen third party könyvtárat, pl. Bootstrap-et akarok használni? Hasonló a felállás, először ugye a telepítéshez ‘npm i bootstrap’ parancs kell, majd a könyvtárat szintén be kell hivatkozni az előbb mutatott módon:

import 'bootstrap/dist/css/bootstrap.css';
import '../assets/css/main.css';

function createComponent(){
    var contentDiv = document.getElementById('content');
    contentDiv.innerHTML = 'Hello WebPack!';
}

createComponent();

Itt a hivatkozás a node_modules mappára relatív történik, ez automatikusan bekerül a lehetséges mappák közé ahol a webpack a függőségeket keresi. Ha most lefuttatjuk a ‘webpack’ parancsot akkor elkezdhetjük vakarni a fejünket:

Ugye a Bootstrap nem csak CSS fileokat tartalmaz, hanem hoz magával mindenféle egzotikus dolgot is, például fontokat. Csakhogy a WebPack jelen állapotában nem tudja mit kezdjen ezekkel, így összefossa magát. Ez volt az a pont, ahol a dokumentáció megszívatott, ugyanis ott simán be volt hivatkozva a Bootstrap, csak elfelejtették megmondani, hogy az nem lesz elég. Persze értelmes hibaüzenetre sem fussa, pedig ebben az esetben egyértelműen kezelhető lenne a dolog, sőt igazából minden esetben oda is írta, hogy “You may need an appropriate loader” ami azt jelenti, hogy olyan pluginra van szükség ami elbír ezekkel a file típusokkal.

Oldjuk is meg, a ‘file-loader’ npm csomagra lesz szükség, és azt hiszem nem kell elmagyaráznom, hogy mit csinál Ezt még be is kell kötni a WebPack konfigba, a következő módon:

var path = require('path');
var ExtractTextPlugin = require('extract-text-webpack-plugin');

module.exports = {
    entry: './app/app.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    module: {
        rules: [
            {
                test: /\.css$/,
                use: ExtractTextPlugin.extract({ use: 'css-loader' })
            },
            {
                test: /\.(png|jpe?g|gif|svg|woff|woff2|ttf|eot|ico)$/,
                use: 'file-loader'
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin('styles.css')
    ]
};

Ezután már szépen lefut a webpack:

Utolsó napirendi pont a minifikálás ami a legkevésbé lesz fárasztó, ugyanis alapértelmezetten van a WebPack telepítésünkben ilyen képesség mégpedig az Uglify plugin személyében. Mindössze ki kell egészíteni a konfigurációt:

const webpack = require('webpack');
var path = require('path');
var ExtractTextPlugin = require('extract-text-webpack-plugin');

module.exports = {
    entry: './app/app.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist')
    },
    module: {
        rules: [
            {
                test: /\.css$/,
                use: ExtractTextPlugin.extract({ use: 'css-loader' })
            },
            {
                test: /\.(png|jpe?g|gif|svg|woff|woff2|ttf|eot|ico)$/,
                use: 'file-loader'
            }
        ]
    },
    plugins: [
        new ExtractTextPlugin('styles.css'),
        new webpack.LoaderOptionsPlugin({
            minimize: true,
            debug: false
        }),
        new webpack.optimize.UglifyJsPlugin({
            beautify: false,
            mangle: {
                screw_ie8: true,
                keep_fnames: true
            },
            compress: {
                screw_ie8: true
            },
            comments: false
        })
    ]
};

Újabb webpack futtatás után látható, hogy bizony csökkentek a fileméretek:

Nos hát mára ennyi lenne a műsor legközelebb csinálunk külön fejlesztői/release konfigurációkat, illetve elTypeScriptesítjük magunkat.

SignalR 3. – Transzportáció I.

reiteristvan — Fri, 07 Jun 2013 09:12:31 +0000

SignalR ideális környezetéhez WebSocket szükséges, ami azért manapság már elég jó százalékkal teljesül is. Mi történik azonban, ha még sincs lehetőség ennek a technológiának a használatára? Ebben a részben ezt a témakört járjuk be.

Azt, hogy épp melyik böngésző támogat milyen technológiát feleslegesnek érzem itt leírni, hiszen ez kb. hetente változhat. Az aktuális információkról az alábbi oldalon tájékozódhatunk: http://caniuse.com/websockets

Alapvetően két lehetőség létezik: ha a böngésző támogatja a HTML 5-öt, akkor a WebSocket mellett a Server Sent Events áll rendelkezésünkre. Ezzel egy baj van, méghozzá az, hogy az Internet Explorer nem támogatja. Emellett az SSE csak egyirányú (szerverről kliens felé) kommunikációt támogat, de igazából rengeteg olyan helyzet van, amikor nincs szükség kétirányú kapcsolatra.

Ha nincs HTML 5, akkor az ún. Comet modellt veszi elő a rendszer, amely gyűjtőnévként szolgál olyan megoldásokra, amelyek fenntartanak egy HTTP kapcsolatot a szerverrel, így lehetővé téve adatok küldését a kliens felé. Ebben az esetben is két út áll rendelkezésünkre: Forever Frame (Internet Explorer) illetve AJAX Long Polling.

A Forever Frame egy rejtett iframe elemet hoz létre, amely a szervertől kap utasításokat, ezeket pedig a böngésző kiértékeli és végrehajtja.

A Long Polling nyitva hagy egy HTTP kérést, amíg a szerver nem válaszol. Miután megkapta az utasításokat, a kapcsolat lezárul és azonnal újat nyit. Ilyenkor persze számolni kell némi teljesítmény kieséssel.

Amennyiben egy adott technológiára van szükségünk a kapcsolat indításakor lehetőségünk van ezt jelezni, az alábbi példában a Server Sent Events-t kapcsoljuk be. Több lehetőséget is megadhatunk, illetve ki is zárhatjuk őket, mivel ilyenkor csak a felsorolt technológiák közül választ.

$.connection.hub.logging = true; // kliens oldali log bekapcsolása
$.connection.hub.start({ transport: [ "serverSentEvents" ]});

Bekapcsoltuk a kliens oldali logolást is, így a böngésző JavaScript konzoljában megnézhetjük, hogy valóban átváltott:

A következő részben a WebSocket protokollt járjuk majd körbe.

XSRF és AJAX ASP.NET MVC 4 alatt

reiteristvan — Fri, 26 Apr 2013 09:45:49 +0000

Az MVC tartalmaz XSRF támadások kivédésére szolgáló eszközöket, ám ezek néha nagy fejfájást tudnak okozni. Például, ha AJAX hívásokat is szeretnénk használni a controller műveletek eléréséhez.Alapvetően a problémát az jelenti, hogy a ValidateAntiForgeryToken attribútum megköveteli, hogy a beérkező kérésekkel együtt érkezzen egy __RequestVerificationToken nevű mező is, amely az azonosításra kiadott kulcsot tartalmazza. Ez még mindig nem lehetetlen, viszont ha mellette szeretnénk mondjuk JSON adatokat is küldeni akkor mindjárt bajban vagyunk.

Menjünk sorjában, ha paraméter nélküli műveletet akarunk hívni, akkor a következőképpen járunk el. Elsősorban szükségünk van a kliensnek kiosztott kulcsra, ezt normális esetben egy @Html.AntiForgeryToken() hívással tudjuk beilleszteni az oldalba. Most sem lesz ez másként, vegyünk fel egy formot, illetve mellé készítettem egy Javascript függvényt amellyel ki tudjuk nyerni a tokent:


    @Html.AntiForgeryToken()

Ezzel megvagyunk, most építsük fel a kérést! Tegyük fel, hogy az Internet Application sablonnal érkező AccountController műveleteit akarjuk hívogatni, ebben az esetben mondjuk legyen a LogOff mivel annak nincs paramétere. Nyilván feltesszük, hogy be vagyunk jelentkezve, de nincs jelentősége. Tehát a kód:

function logOff() {

    var token = getAntiForgeryToken();

    $.ajax({
        url: "@Url.Action("LogOff", "Account")",
        type: "POST",
        data: { __RequestVerificationToken: token },
        success: function () {
            // OK
        }
    });
                
    return false;
}

Meglehetősen egyszerű, ha sikerrel jártunk a success-nek megadott függvény lefut, át lehet variálni a HTML-t. Na most, mi történik, ha nem mellékelnénk a tokent? Kivételt kapunk, mégpedig: AntiForgery Exception: A required anti-forgery token was not supplied or was invalid.

Ez eddig egyszerű, jöjjön a nehezebbik része, mi van akkor ha paramétert is akarunk küldeni a kéréssel együtt? Ezúttal a kísérleti nyúl szerepét a LogIn művelet veszi át, amely két paramétert vár, LoginModel típusú objektumot amely a felhasználónevet és jelszót tartalmazza, illetve a returnUrl egy string, ami a sikeres belépés utáni oldalt jelöli. Építsük fel először a JSON adatokat:

var loginData = {
    model: {
        UserName: '"' + $("#userName").val() + '"',
        Password: '"' + $("#password").val() + '"',
        RememberMe: $("#remember").val()
    },
    returnUrl: "/Index/Home"
};

Majd a kérést:

$.ajax({
    url: "@Url.Action("Login", "Account")",
    type: "POST",
    contentType: "application/json",
    dataType: "json",
    data: JSON.stringify(loginData),
    success: function () {
        // OK
    }
});

Ha kipróbáljuk, akkor ez bizony a fent említett kivételt dobja, hiszen nincs ott a token. A kérdés, hogy hová tegyük a tokent? JSON-ként nem lehet küldeni, mert nem kezeli le a másik oldal. Phil Haack bejegyzéséből jött az ötlet, hogy tegyük a tokent a kérés fejlécébe, és a szerveren írjuk át a validálást végző attribútumot.

Tehát, a Javascript kódot egészítsük ki egy kicsit:

var token = getAntiForgeryToken();
var headers = {};
headers["__RequestVerificationToken"] = token;

$.ajax({
    url: "@Url.Action("Login", "Account")",
    type: "POST",
    contentType: "application/json",
    dataType: "json",
    headers: headers,
    data: loginData,
    success: function () {
        // OK
    }
});

Oké, nézzük a szervert! A fent említett bejegyzés még MVC 3-hoz készült és nem fordul le, az AntiForgery.Validate HttpContext-et fogadó változata az MVC 4-ben obsolete minősítést kapott, ezért egy kicsit át kell írni. Illetve csak a fejlécben keresi a tokent, én szerettem volna egy univerzális változatot, szerencsére nem volt nehéz dolgom:

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class,
                AllowMultiple = false, Inherited = true)]
public sealed class ValidateHeaderOrFormAntiForgeryTokenAttribute : FilterAttribute, IAuthorizationFilter
{
    private const string TokenName = "__RequestVerificationToken";

    public void OnAuthorization(AuthorizationContext filterContext)
    {
        if (filterContext == null)
        {
            throw new ArgumentNullException("filterContext");
        }

        var httpContext = filterContext.HttpContext;
        var cookie = httpContext.Request.Cookies[AntiForgeryConfig.CookieName];
        var token = httpContext.Request.Form[TokenName] ?? httpContext.Request.Headers[TokenName];

        AntiForgery.Validate(cookie == null ? null : cookie.Value, token);
    }
}

A token vagy a Form vagy a Header felsorolásban érkezik, ha az egyik null akkor a másikban megleljük, jól jött a null coalescence operátor.

Ezután csak ki kell cserélni a ValidateAntiforgeryToken attribútumot a sajátunkra és mindenki boldog.

ToDoSite 8. – Kliens oldal

reiteristvan — Tue, 23 Apr 2013 09:25:47 +0000

Eljött az ideje, hogy lezárjam ezt a sorozatot, jöjjön az utolsó felvonás. Szerveroldalon kész vagyunk, már csak némi Javascript kód szükséges.

Természetesen a Knockout könyvtárat fogjuk használni, ennek beállításáról a korábbi bejegyzésekben untig lehet olvasni, így ettől most megkímélem magunkat. Ajánlom viszont a Visual Studio 2012 Update 2 csomag telepítését ami kiváló Intellisense támogatást ad a Knockout adatkötéseihez.

A projecten belül létrehoztam egy ClientScripts nevű könyvtárat, ezen belül pedig a ToDoViewModel.js nevű fájlt amiben tulajdonképpen a komplett kliens oldali kód terpeszkedik el.

Elsősorban szükségünk lesz egy viewmodel-re, amely majd a szerver felől érkező adatokat tárolja:

function TaskViewModel(task) {
    var self = this;

    self.id = task.id;
    self.description = task.description;
    self.date = task.date;
    self.isCompleted = task.isCompleted;
    self.userName = task.userName;
}

A paraméterként megadott task objektumon is a kisbetűs tulajdonságokat tudjuk hívni, hiszen a szerveroldali osztályokat elláttuk a JsonProperty attribútumokkal, így illeszkednek a Javascript elnevezési konvenciójához.

Kell még egy osztály, ez tartalmazza majd a műveleteket, illetve egy listát a felhasználó teendőiről. A műveletek nélkül ez így néz ki:

function ToDoViewModel() {
    var self = this;

    self.tasks = ko.observableArray();
    self.taskToAdd = ko.observable("");
}

A taskToAdd ebben az esetben egy szimpla string érték lesz, a teljes objektumot majd a feltöltéskor rakjuk össze. Jöjjön a getAll, amivel lekérjük a feladatok listáját:

self.getAll = function () {
    self.tasks.removeAll();

    $.ajax({
        url: "api/ToDo/",
        accepts: "application/json",
        cache: false,
        statusCode:
            {
                200: function (data) {
                    $.each(data, function (key, value) {
                        self.tasks.push(new TaskViewModel(value));
                    });
                },
                401: function () {
                    window.location = "/Account/Login/";
                }
            }
    });
};

A statusCode segítségével tudjuk eldönteni, hogy be van-e a felhasználó jelentkezve, vagy sem. Utóbbi esetben 401-es kódot kapunk vissza, ekkor átirányítjuk a felhasználót a login oldalra. Itt természetesen más megoldás is lehetséges, ez volt a legegyszerűbb.

A post függvényhez szükség lesz az előző bejegyzésben elkészített JsDateConverter osztályra, ami megoldja a Javascript Date és a .NEt DateTime típusa közötti inkompatibilitást. Ha ez megvan, akkor csak JSON formára kell hozni az adatokat. A felhasználónevet itt most üres stringnek hagytam, annak ellenére, hogy az megérkezik a feladatok listájával.

self.post = function () {
    var task = JSON.stringify({
        id: -1,
        description: self.taskToAdd(),
        date: Date.now(),
        isCompleted: false,
        userName: ""
    });

    $.ajax({
        url: "api/ToDo/",
        accepts: "application/json",
        cache: false,
        type: "POST",
        contentType: "application/json; charset=utf-8",
        data: task,
        success: self.getAll
    }).fail(function (xhr, textStatus, err) {
        alert(err);
    });

    self.taskToAdd("");
};

A módosításhoz segítségünkre van a Knockout, így azonnal hozzájutunk a szükséges objektumhoz. Ebben az esetben a módosítás csak annyit jelent, hogy a feladatot elvégzettnek jelöljük, így a függvény első sorában mindössze át kell állítanunk az isCompleted tulajdonságot. Az url-hez pedig hozzá kell még csapnunk az objektumunk azonosítóját, hogy szerveroldalon megtaláljuk azt az adatbázisban. Figyelni kell viszont arra, hogy a felküldeni kívánt példány nem “átlagos” Javascript objektum, ezért a Knockout beépített toJSON függvényét kell használni ahhoz, hogy kinyerjük belőle az adatokat.

self.update = function (task) {
    task.isCompleted = true;

    $.ajax({
        url: "api/ToDo/" + task.id,
        datatype: "json",
        contentType: "application/json; charset=utf-8",
        type: "PUT",
        cache: false,
        data: ko.toJSON(task),
        success: self.getAll
    }).fail(function (xhr, textStatus, err) {
        alert(err);
    });

    return true;
};

Végül a törlés hasonlóképpen igényli az url-hez adott azonosítót, de semmi mást, hiszen nem kell feltöltenünk külön adatokat.

self.delete = function (task) {
    $.ajax({
        url: "api/ToDo/" + task.id,
        type: "DELETE",
        cache: false,
        success: self.getAll
    }).fail( function ( xhr, textStatus, err ) {
        alert(err);
    });
};

Készítettem még egy rendező függvényt is, amely a feladatok állapota (kész-nem kész) alapján sorba rakja azokat:

self.sort = function () {
    self.tasks.sort(self.sortFunction);
};

self.sortFunction = function (a, b) {
    return a.isCompleted < b.isCompleted ? -1 : 1;
};

Már csak annyi a dolgunk, hogy a View fejezetben elkészített HTML kódhoz hozzáadjuk a Knockout kötéseit és készen is vagyunk. Ha emlékszünk, akkor a Twitter Bootstrap könyvtárral tulajdonképpen két sorba rendeztük az oldalunkat, a felső sorban egy táblázat a feladatokkal, az alsóban pedig az új feladat űrlap.

A felső sor kódja:

A rendező gombbal kezdünk, erre csak a sort függvényt kell rákötni. Ezután a táblázaton a már ismert foreach kötést alkalmazzuk, de van egy kis csavar, mégpedig a kész/nem kész állapotok miatt. Ha nem végeztük el az adott feladatot, akkor egy gombot kell megjelenítenünk, ellenkező esetben pedig valami mást. Erre használjuk az if és ifnot kötéseket, amelyek segítségével adott HTML elemet megjeleníthetünk, illetve elrejthetünk. Minden más standard, nincs látnivaló.

A második sor ennyire sem érdekes, minden további nélkül:


    
        
            
                Add new Task

Ezzel el is készültünk, vegyünk érzékeny búcsút a Web API-tól. A ToDoSite forráskódja megtalálható a GitHub-on: https://github.com/reiteristvan/ToDoSite/

Javascript Date vs. .NET DateTime

reiteristvan — Fri, 19 Apr 2013 14:24:00 +0000

Az előző bejegyzésben említettem, hogy a Javascript és a .NET dátum típusai nem szeretik egymást. Most bemutatok egy megoldást, ami eltünteti a gondjainkat.

Ugye kliens oldalról szerver oldalra (és vice versa) JSON formában utaznak az adatok, tehát kézenfekvő a folyamat ezen részét megcélozni. Szerencsére lehetőségünk van tetszőleges JSON konverter megadására, írjunk hát egyet.

A Javascript féle Date.now() függvény a Unix epoch (1970.01.01) óta eltelt ezredmásodpercet adja vissza (nem pedig másodpercet, vigyázat), tehát semmi más dolgunk nincs, mint a beépített DateTime függvényekkel megdolgozni a bejövő adatokat. Készítsünk egy osztályt, amely a DateTimeConverterBase absztrakt osztályból származik, itt a komplett forráskód:

public class JsDateConverter : DateTimeConverterBase
{
    public override object ReadJson(Newtonsoft.Json.JsonReader reader, Type objectType, object existingValue, Newtonsoft.Json.JsonSerializer serializer)
    {
        if (reader.TokenType != JsonToken.Integer)
        {
            throw new Exception("Unexpected token");
        }

        return new DateTime(1970, 1, 1).AddMilliseconds((long)reader.Value);
    }

    public override void WriteJson(Newtonsoft.Json.JsonWriter writer, object value, Newtonsoft.Json.JsonSerializer serializer)
    {
        if (!(value is DateTime))
        {
            throw new Exception("Unexpected type, shame on you");
        }

        var unix = new DateTime(1970, 1, 1);
        var delta = ((DateTime)value) - unix;

        if (delta.TotalSeconds < 0)
        {
            throw new Exception("1970.01.01, let me google that for you");
        }

        writer.WriteValue((long)delta.TotalMilliseconds);
    }
}

Látható, hogy összeadás, kivonás és kész is vagyunk, nem igényel különösebb magyarázatot. A bejövő adat esetében a típust (Integer) ellenőrizzük, visszafelé pedig az 1970 utáni dátumot. Persze a dátum UTC szerint megy, vagyis hozzánk képest 2 óra mínuszban van, erre nem árt figyelni.

Kész a konverter, már csak ki kell dekorálni a szükséges property-t a JsonConverter attribútummal és kész is vagyunk:

[JsonProperty ( "date" )]
[JsonConverter(typeof(JsDateConverter))]
public DateTime Date { get; set; }

A végére egy megjegyzés: az IE 8 óta az összes böngészőben elérhető a Date típus toJSON nevű függvénye, ami olyan formára hozza a dátumot, amivel az alapértelmezett konverter is elbír. Ha nem kell tekintettel lenni a régebbi böngészőkre, akkor bátran használjuk ezt.

RSS olvasó, YQL kalandok

reiteristvan — Fri, 05 Apr 2013 12:09:31 +0000

Mivel a Google Reader bezárja kapuit, úgy döntöttem, hogy saját kezembe veszem az irányítást és készítek egy RSS olvasó alkalmazást, amely egyúttal el is tudja menteni az általam érdekesnek talált bejegyzéseket. Azt is elhatároztam, hogy az adatbázist leszámítva teljes mértékben Javascript kódot fogok használni, ez a döntésem viszont akadályt gördített az utamba.

A Same Origin Policy miatt a Javascript kódom nem fér hozzá más domain alatt lévő tartalomhoz, ez a csodálatos XmlHttpRequest error: Origin is not allowed by Access-Control-Allow-Origin című hibaüzenet formájában manifesztálódik. Ezt a problémát persze át lehet hidalni, de én elegánsabb megoldást szerettem volna, és itt jön a képbe a YQL vagyis a Yahoo Query Language. Ez a szolgáltatás lehetővé teszi, hogy nagyjából minden webes dologra SQL szerű lekérdezéseket írjunk, akár RSS feedekre is. Ami még jobb, hogy az XML-lel való szórakozás helyett rögtön JSON formában is kérhetjük az eredményt.

A http://developer.yahoo.com/yql/console/ oldalon lehet tesztelni a lekérdezéseinket, kellemesen részletes leírások társaságában, a Yahoo-s lányok és fiúk kitettek magukért. A saját blogom RSS folyamáért a következő lekérdezést kell futtatnom:

Ezzel lekérhetem a bejegyzések címét, az url-t, a dátumot, illetve egy bejegyzéshez tartozó kép url-jét, mindezt JSON formában.

Hogyan néz ez ki, ha Javascriptből akarom meghívni? Rendkívül egyszerű, mindössze a jQuery getJSON függvényére lesz szükségünk. Én magam Knockout-ra építem a megoldásom, itt a kódrészlet:

function FeedViewModel(feed) {
    this.title = feed.title;
    this.url = feed.link;
    this.date = feed.pubDate;
}

var query = 'http://query.yahooapis.com/v1/public/yql?q='
                +
            encodeURIComponent('select title, link, pubDate from rss where url="' + feedUrl + '"')
                +
            '&format=json&callback=?';

$.getJSON(query, function (data) {
    var result = data.query.results.item;

    for (var i in result) {
	//Knockout, result[i] tartalmazza az adatokat
        self.links.push(new FeedViewModel(result[i]));
    }
});

FeedUrl tartalmazza az RSS folyam címét, a self.links pedig egy observableArray.

ToDoSite 0. – Előkészületek

reiteristvan — Fri, 01 Mar 2013 13:44:17 +0000

A Web API sorozatnál már jeleztem, hogy bemutatom egy “rendes” alkalmazás elkészítését is, ez nem más mint a ToDoSite. A nevéből gyorsan ki lehet találni, hogy egy “feladatlistáról” van szó, semmi feleslegesen bonyolult. Tulajdonképpen a program külseje meglehetősen puritán, de azért lesz munka vele bőven.

Bár maga a projekt a Web API sorozatból nőtte ki magát ez a technológia viszonylag kevés szerepet fog játszani. Sokkal inkább egy váz felépítését szeretném megmutatni, amire az érdeklődők építeni tudnak. A kész oldal így néz majd ki:

Néhány szót a felhasznált technológiákról:

Az adatelérésért az Entity Framework Code First felelős. A szerver-kliens kommunikáció a Web API-n keresztül történik, jQuery AJAX hívásokkal. Ezeket az adatokat a Knockout Javascript könyvtárral kezeljük majd. A megjelenítésért ez, illetve a Twitter Bootstrap szintén Javascript könyvtár lesz felelős. Végül, de nem utolsósorban az egész fejlesztés egy ASP.NET MVC 4 projekt keretein belül történik.

A fejlesztéshez Visual Studio 2012 Ultimate-et használok, de a Visual Studio 2012 Express for Web is tökéletesen megteszi. Érdemes (kötelező) telepíteni hozzá az ASP.NET and Web Tools 2012.2 csomagot, ami többek között Intellisense támogatást ad a Knockout adatkötéseihez. Persze amilyen szerencsém van pont azután jött ki, hogy végeztem vele…

A Visual Studio és a Web Tools telepíthető a Web Platform Installer-ből, a könyvtárakat pedig vagy kapjuk a projekt sablonban, vagy Visual Studio-ból letölthetőek a NuGet segítségével.

A kész alkalmazás forráskódja megtekinthető itt: https://github.com/reiteristvan/ToDoSite/

A következő bejegyzésben becsszó csinálunk valamit, addig is jó hétvégét!

ASP.NET Web API 4. – Knockout

reiteristvan — Sun, 13 Jan 2013 15:07:06 +0000

Kis kitérőt teszünk, abszolút mellőzve a Web API-t megismerkedünk egy igencsak hasznos Javascript könyvtárral: Knockout.

Amiért nagyon szeretjük őt az az, hogy lehetővé teszi adatkötések létrehozását, vagyis gyakorlatilag csak egy sablont kell megírnunk és a Knockout behelyettesíti az adatainkat. Ezzel nagyon leegyszerűsítettem a könyvtár tudását, megmutatom inkább miről van szó.

A példánkban egy menü megjelenítő/karbantartó űrlapot fogunk létrehozni, hasonló bonyolultsággal mint az eddigi részek példái. A kész program itt megtekinthető: http://dl.dropbox.com/u/6133419/index.html

Készítsük el először az oldal vázát és linkeljük a Knockout illetve jQuery könyvtárakat:


	
		Knockout

A Knockout ún. viewmodel-ekre (és a Model-View-ViewModel mintára) épül, ami gyakorlatilag ugyanaz mint ami WPF/SL/… alatt van, bár közel sem kell annyit dolgozni rajta. Készítsük el első viewmodelünket:

function FoodViewModel(name, price)
{
	this.name = name;
	this.price = price;
}

Egyszerű mint a faék, következő lépésünk, hogy megjelenítjük a viewmodel adatait az oldalon. A Knockout kihasználja, hogy a HTML5 megengedi tetszőleges attribútum kezelését a data- előtaggal. Ebben az esetben a data-bind attribútumot kell használnunk, amelyen keresztül megadjuk, hogy mit akarunk kötni, hová és hogyan. Ha az étel adatait akarom megjeleníteni akkor az így fog kinézni:

Név:  

Ár:

A “text” lesz a hová, utána pedig a megfelelő viewmodel tulajdonság következik (vagyis a mit). Van már viewmodel, meg is tudjuk jeleníteni, már csak össze kell kötni ezt a kettőt. Az eddigi kód kiegészítve a Knockout beindításával:


	
		Knockout
		
		
		
		
		
	
	
	
		Név:  

		Ár:

Első lépés kipipálva, lépjünk tovább. Természetesen módosítani is szeretnénk az adatokat, mi lenne, ha a viewmodel-t egy textbox-ra kötjük?

Név:  

Ár:

Megjelenik a szöveg, szerkeszteni is tudjuk, de jó lenne, ha az oldalon lévő összes kötés is változna. Ehhez ún. observable tulajdonságokat fogunk használni, amelyek “értesítik” a felhasználói felületet a változásokról. Írjuk át a viewmodel-t:

function FoodViewModel(name, price)
{
	this.name = ko.observable(name);
	this.price = ko.observable(price);
}

Ha most átírjuk a szövegdoboz tartalmát és Enter-t nyomunk vagy elvesszük onnan a fókuszt akkor az oldalon lévő másik kötött adat is megváltozik.

Mivel menüt csinálunk, ezért egynél több viewmodel-t is tudnunk kell kezelni. Kézenfekvő, hogy készítünk egy új viewmodel-t és ez tárolja majd a többi objektumot:

function MenuViewModel()
{
	var self = this;
	
	self.foods = ko.observableArray([
		new FoodViewModel("Rántott hús", 600),
		new FoodViewModel("Palacsinta", 800),
		new FoodViewModel("Csokitorta", 1000),
		new FoodViewModel("Almás pite", 1200)
	]);
}

Az első sorban elkövetett “var self = this;” az ún. binding loss effektus ellen véd, ha valakit érdekel akkor látogasson el ide: http://www.alistapart.com/articles/getoutbindingsituations, máskülönben kell és kész. Az observableArray könnyen kitalálható, hogy a sima observable listásított változata, amely maga is viewmodel-eket tárol. Persze a Knockout inicializálása is változik kicsit:

$(document).ready( function (){
	var vm = new MenuViewModel();
	ko.applyBindings(vm);
});

Ok, most kössük rá a listánkat valamire. Ugye itt két kötés is lesz: egyszer magát a listát, másodszor a lista elemeit is külön kötnünk kell. Ehhez a foreach binding-et használjuk, aminek megadhatunk egy sablont, ami alapján a lista elemeit megjeleníti. Kell viszont még egy olyan HTML elem, amely képes egyszerre több elemet megjeleníteni, mi most táblázatot használunk, de pl. lista is megfelelő erre a célra.


	
		
			Név Ár

A táblázat törzsében beállítottuk a foreach kötést, hogy használja a viewmodel foods tulajdonságát, vagyis a listánkat.

A következő funkció a törlés lesz. Azt akarjuk, hogy a lista minden eleméhez tartozzon egy törlés gomb. Elsősorban készítsük el a törlés függvényt a viewmodel-ben, vagyis:

self.remove = function (food){
	self.foods.remove(food);
};

Most pedig egészítsük ki a táblázat sablonunkat:

Az első amit észre kell venni, hogy a gomb click eseményéhez kötöttünk, vagyis egyúttal bevezettük magunkat a Knockout eseménykezelésének világába is. A másik érdekes dolog az az amit kötöttünk. Az ugye egyértelmű, hogy a frissen elkészített remove függvény lesz az áldozat, ám mit keres előtte a $root? Gyorsan gondoljuk át a dolgot! A táblázathoz hozzákötöttük a “fő” viewmodel egy tulajdonságát, viszont a táblázaton/sablonon belül egy új kötés van érvényben, mégpedig a listaelemé. Innen nem tudjuk elérni a MenuViewModel-t, ezért meg kell kérnünk a Knockout-ot, hogy a FoodViewModel helyett a gazda viewmodel-en belül keressen.

Már csak két napirendi pontról kell gondoskodnunk, az első a hozzáadás lesz. Kicsit talán szokatlan megoldást fogunk alkalmazni, ugyanis el akarjuk kerülni, hogy kézzel kelljen lekérni az új adatokat. Azt csináljuk, hogy a viewmodel-ben felveszünk egy változót, amely mindig az aktuális új elemet tárolja és ezt kötjük hozzá egy űrlaphoz. Amikor pedig hozzáadjuk a listához az új elemet, akkor “lenullázzuk” ezt az átmeneti változót, hogy újra munkába állhasson.

self.itemToAdd = ko.observable(new FoodViewModel("Étel neve", 0));

Persze observable lesz és adtunk egy kis segítséget is a felhasználónak. Készítsük el a hozzáadás függvényt is:

self.add = function (){
	self.foods.push(self.itemToAdd());
	self.itemToAdd(new FoodViewModel("Étel neve", 0));
};

Végül az űrlapot. Felhasználjuk, hogy a Knockout képes kezelni a submit eseményt. Az adatkötéseknél figyeljünk a zárójelekre!

Utolsó lépés következik! Már csak valamiféle ellenőrzést szeretnénk az űrlapra rakni, hogy ne lehessen akármit felvinni. Legyenek a feltételeink mondjuk: 1. az ár legyen nullánál nagyobb, 2. az étel neve ne legyen üres string, 3. az étel neve ne egyezzen meg azzal amit mi magunk adtunk meg. Ez önmagában egyáltalán nem bonyolult, viszont azt akarjuk, hogy ezeket a feltételeket a gombhoz köthessük, vagyis olyan mechanizmust kell találnunk, ami folyamatosan követni tudja a hozzáadásra kijelölt elem állapotát. Erre a célra ún. számított tulajdonságokat (computed property eredetiben, jobban is hangzik) használunk, a miénk ilyen lesz:

self.canAddNewItem = ko.computed(function() {
	return (
		self.itemToAdd().name() !== "" && 
		self.itemToAdd().name !== "Étel neve" &&
		self.itemToAdd().price() > 0);
});

Mindössze annyi dolgunk maradt, hogy hozzákössük a gomb enable tulajdonságához:

Egy aprósággal azért kiegészítettem: ha nem adunk meg mást, akkor a kötött elemek értéke akkor módosul a viewmodel-en belül, ha a vezérlőről elkerül a fókusz, vagy Enter-t ütünk. A “valueUpdate”-nek azonban megadhatjuk, hogy minden billentyűlenyomás után tegye ezt meg, így elegánsabb megoldást kapunk.

A következő részben összekötjük a Knockout könyvtárat a Web API-val.

Silverlight metódus hívása JavaScripttel

reiteristvan — Thu, 09 Feb 2012 10:17:41 +0000

Tegnap merült fel egy érdekes probléma az ASP.NET Facebook csoportban, nevezetesen, hogy hogyan adjunk át adatokat a Silverlight alkalmazásnak. Nyílván nem optimális a felállás, de attól még előfordulhat, szóval ha valaki ilyesmibe fut akkor itt a megoldás.

Meglehetősen egyszerű dolgunk van, elsősorban szükségünk van egy hihetetlenül életszerű példára, ez a következő: a SL alkalmazásunkban van egy darab TextBox, amivel kiíratjuk a javascripttel érkező üzenetet.

A következő lépés, hogy hidat teremtünk a SL és a JS között. Ehhez szükségünk van egy metódusra, amelyet a ScriptableMember attribútummal dekorálunk:

[ScriptableMember]
public void SendMessage(string message)
{
    this.messageTextBox.Text = message;
}

Az MSDN nem említi, de az alkalmazást regisztrálni is kell, hogy “lássa” a JS, ehhez a konstruktorban kell elhelyezni pár sort:

public MainPage()
{
    InitializeComponent();

    if (HtmlPage.IsEnabled)
    {
        HtmlPage.RegisterScriptableObject("Communicator", this);
    }
}

Silverlight oldalról ennyi volt, lássuk azt a javascriptet. Első lépésként húzzuk be a jquery könyvtárat:

Majd adjunk nevet (id) a Silverlight objektumnak:

Hozzunk létre egy szövegmezőt és egy gombot:

Ezután az alábbi függvénnyel tudjuk hívogatni az SL metódust:

function sendMessage()
{
    var control = $('#sl-plugin').get(0);
    if (control != null)
    {
        control.content.Communicator.SendMessage($('#message').val());
    }
}

Az eredmény (annyit csinosítottam rajta, hogy a silverlight objektumot tároló div magasságát csökkentettem):