March 2009 - Posts

Det finns ett nytt projekt på MSDN Code Gallery som heter SpicIE och som låter utvecklare enkelt skapa plugins till Internet Explorer i form av:

  • IE browsing event handlers
  • IE toolbar buttons
  • IE menu entries
  • IE context menu entries
  • IE explorer bars
  • IE toolbars

Har inte hunnit testa det själv än, men det låter väldigt lockande då det tidigare har varit riktigt krångligt att skriva bra plugins (med metoder som Navigate och Navigate2 vilka inte säger ett dugg om vad som egentligen sker).

Du hittar projektet här:

http://code.msdn.microsoft.com/SpicIE

Om du har testat det så kom gärna med kommentarer om vad du tycker om det!

Packt Publishing har släppt en bok vid namn ASP.NET MVC 1.0 Quickly och som tar upp det nyligen släppta ASP.NET MVC.

Jag väntar på att få hem boken för recension, men under tiden så är det möjligt att ladda ned ett gratiskapitel.

Ladda ned kapitlet här!

Jag har börjat ha reklam i slutet av alla poster i RSS-feeden. För er (66 stycken :-)) som prenumererar på den – stör reklamen er? Ska jag ta bort den, eller är det ok att den finns där?

Kommentera gärna och säg vad ni tycker.

Det finns en del diskussioner om vart internet är på väg. Jag var med på ett möte i torsdags som hölls av Microsoft där bl.a. det diskuterades. Fredrik Normén har även tagit upp att HTML är så 1990 och att RIA är framtiden.

Internet har utvecklats relativt fort, men vad händer härnäst? Tidigare så har man lätt kunna skylla på att internet explorer håller tillbaka utvecklingen på grund av dess egna varianter på allt (en kvarleva från browser-kriget 1.0 mellan Internet Explorer och Netscape). I och med Internet Explorer 8 som äntligen klarar Acid 2, har fullt stöd för CSS 2.1 och även delvis stöd för HTML 5 så är det svårt att skylla allt på det nu.

En fördel med webbstandarder är att det är helt öppet för vem som helst att implementera, och att det finns en organisation vid namn W3C (World Wide Web Consortium) som tillhandahåller och utvecklar dessa standarder. Nackdelen är att det är just W3C som tillhandahåller dessa. Ser vi till t.ex. HTML 5 så har det räknats ut att det blir en rekommendation (kräver att minst två mjukvaror har fullt stöd) år 2022! Ska vi behöva vänta i 13 år innan vi till fullo skall kunna använda denna standard? En annan standard som jag verkligen ser fram emot är XHTML 2, vilket började utvecklas 2002. Det är 7 år sedan och det är fortfarande bara en draft.

Utvecklingen av standarder går på tok för segt och håller inte i närheten samma tempo som resten av webben. Senaste tiden har vi kunnat se en utveckling som vi inte har haft sedan 90-talet när Netscape kom med Livescript, vilket senare blev javascript. Det dök upp mängder av “standarder” under 90-talet då Internet Explorer och Netscape tävlade om att implementera allt först och på sitt eget sätt.

Webben som den såg ut då var stela sidor (förutom animerade eldflammor och bakgrundsmusik) som inte lät användaren blanda sig in på något sätt. Sedan kom DHTML där vi helt plötsligt kunde få liv i sidorna och få dem mer levande. Nästa steg var Ajax som kom i slutet av 90-talet, men inte bredde ut sig ordentligt förrän ett par år senare.

Internet som det ser ut nu är helt annorlunda än mot vad den var för 10 år sedan. Vi har sociala nätverk som Facebook och MySpace, mikrobloggar som Twitter och Bloggy, vanliga bloggar som låter helt vanliga medel-Svenssons skriva dagböcker som kan läsas av vem som helst i hela världen, vi kan dela med oss utav våra bilder osv osv.

Vad är nästa steg? Vi kan på de flesta tjänster använda oss utav API:er för att arbeta mot dessa och integrera i antingen applikationer anpassade för just dem, eller i mashups. Dessa applikationer behöver inte vara på internetbaserade, utan kan lika gärna vara vanliga applikationer som körs i operativsystemet. Sedan så har vi hybrider som Adobe Flex och Silverlight 3.0 som kan köras i både webbläsaren och på klienten.

Så vad har vi att vänta oss? Är internet som vi ser det nu dött till förmån för rika internet applikationer och skrivbordsapplikationer, eller kommer den att fortsätta att utvecklas? Jag ser att W3C har en stor del i detta och kan vara en av anledningarna till att utvecklare vänder sig mot dessa rika applikationer som utvecklas med tredjepartsprodukter.

Jag själv tror att webben kommer att fortsätta leva som den gör nu, och är precis som tidigare ett utmärkt sätt att visa information på. En stor fördel med detta är att det är en otroligt utbredd teknik som finns implementerad i otroligt många applikationer. Vem som helst kan på vilken enhet som helst se webbsidor då de följer samma standarder. Nackdelen är att dessa standarder utvecklas långsamt.

Rika applikationer i Silverlight och Flex däremot utvecklas i rykande fart och låter utvecklare att skapa applikationer som är långt mer interaktiva än vi någonsin tidigare har kunnat använda. Dessa applikationer ser mycket bättre ut än tidigare, och ger större möjligheter än vad vi tidigare har haft. Nackdelen är dock att dessa inte är alls lika utbredda och går att använda på mycket färre enheter än vad HTML-sidor kan. Det kan även vara problematiskt att utveckla sidor som är tillgänglighetsanpassade, vilket det finns standarder för när det gäller “vanlig” webbutveckling (bl.a. WCAG för vanliga webbplatser och WAI-ARIA för rika applikationer med javascript).

Så, vart är webben på väg?

Jag är säker på att det kommer att komma många fler applikationer byggda på dessa RIA-tekniker än vad det finns nu – när väl tekniken har brett ut sig. Det kräver att utvecklingen går snabbare på andra enheter än de vanligaste. Man måste ha åtkomst till dessa på – förutom Windows och Mac OS X – Linux och andra mindre utbredda operativsystem, mobila enheter samt även skärmläsare. Jag är säker på att detta stöd kommer att breda ut sig, men det kommer att ta lång tid innan den är så utbredd att vi helt kan lita på att användarna har dessa. Samtidigt så kommer personerna bakom de större webbläsarna att tillsammans se till att standarderna går snabbare framåt än vad W3C behöver på sig.

En sak är dock säker – webben som vi ser den idag kommer vi att skratta åt lika mycket om 10 år som vi nu gör åt den som vi jobbade med för 10 år sedan.

Vad tror du?

Microsoft har släppt en riktigt härlig video (med bl.a. ninjan!) som handlar om historien bakom internet.

Klicka här för att se den

Posted Monday, March 23, 2009 9:57 PM by Vimpyboy | with no comments
Filed under:

Då har jag slutfört artikelserien om nya funktionerna för utvecklare i Internet Explorer 8.

Här är en lista på dessa:

När man lagrar information för en viss användare så brukar man använda antingen cookies för långvarig lagring, eller sessionsvariabler för kortvarig. I HTML 5 så finns en funktion som heter DOM Storage och gör det möjligt att lagra informationen på ett annorlunda sätt. Cookies kan t.ex. ha 4 kb eller max 20 värden, men med DOM Storage så kan man lagra upp till 10 MB på klienten, vilket gör det möjligt att spara annan information än man tidigare har kunnat göra.

Det går precis som tidigare att spara i sessionen eller permanent. För sessionen så används sessionStorage och mer permanent localStorage. De har samma metoder, men lagrar bara informationen på olika sätt. All informationen sparas som strängar, så vill vi använda t.ex. datum eller olika typer av tal så måste vi typa om variablerna innan de används.

Storage-objektet innehåller dessa metoder:

  • clear
    • Tar bort alla värden ur storage-objektet.
  • getItem
    • Hämtar värdet för den aktuella nyckeln.
  • setItem
    • Sätter ett värde för den aktuella nyckeln.
  • removeItem
    • Tar bort värdet med den aktuella nyckeln.
  • key
    • Returnerar nyckeln för att visst index.
  • length
    • Hämtar antalet värden som finns sparade.
  • remainingSpace
    • Returnerar hur många bytes som finns kvar för lagring.

Både localStorage och sessionStorage kan använda dessa metoder.

För att använda dessa så kan vi sätta värdet direkt på objektet:

localStorage.firstname = ‘Mikael’;
alert(localStorage.firstName);

Detta visar en alert-ruta med “Mikael”.

Vill vi ta bort just det här värdet så kan vi sedan använda removeItem:

localStorage.removeItem('firstname');

Vi kan alltså på ett mycket enkelt sätt lagra stora mängder data, på ett sätt som påminner om cookies och sessionsvariabler.

En nyhet i IE 8 är inbyggt stöd för att hantera JSON. De metoder som finns är stringify() och parse(). För den som inte vet vad JSON är så har jag en kort genomgång.

JSON är en förkortning för JavaScript Object Notation. Det är egentligen helt vanliga Javascript-objekt. Det används ofta i samband med Ajax då det innebär mycket mindre overhead än XML och går därmed snabbare att ladda.

Ett exempel på JSON:

var json = {
    'firstname': 'Mikael',
    'lastname': 'Söderström',
    'age': 112,
    'skills': ['ASP.NET', 'C#']
};

Det här är ett JSON-objekt skapat direkt med javascript. För att använda det i Ajax-sammanhang så har man tidigare fått använda eval(json-sträng) för att få det till objekt. Det innebär dock stora säkerhetsproblem då man kan exekvera i stort sett vilket javascript som helst. I Internet Explorer 8 så finns det dock nya metoder för att lösa detta.

För att använda objektet ovan så kan vi köra det här:

alert(json.firstname + ' ' + json.lastname);

Det som sker här är att en alert-ruta dyker upp med texten “Mikael Söderström”.

Om vi vill få hela vårt JSON-objekt till en sträng så kan vi med de nya API:erna använda stringify(). Säg att vi kör denna kod:

var jsonString = JSON.stringify(json);
alert(jsonString);

Det som sker nu är att vi får en alertruta med texten:

{"firstname":"Mikael","lastname":"S\u00f6derstr\u00f6m","age":112,"skills":["ASP.NET","C#"]}

Det är så her det hade sett ut om det hade kommit via ett Ajax-anrop.

Vill vi nu få den här strängen tillbaka till ett JSON-objekt så kan vi använda parse():

var parsedJson = JSON.parse(jsonString);
alert(parsedJson.firstname);

Det som sker nu är att vi återigen kan anropa objektet som vanligt.

Fördelarna med att använda dessa inbyggda funktioner är att vi får bättre prestanda och bättre säkerhet när vi arbetar med JSON.

Något som blir allt vanligare på webben är mashups, vilka ofta används tillsammans med javascript och iframes för att kunna visa applikationer från andra domäner. För att göra detta säkrare så finns det i Internet Explorer 8 stöd för Cross Document Messaging, vilket är en nyhet i HTML 5.

Det går ut på att vi använder dels metoden postMessage för att posta ett meddelande och eventet onmessage för att kunna ta emot ett meddelande.

Med Cross Document Messaging kan vi alltså skicka och ta emot meddelanden mellan olika domäner. Vi kan med detta tillåta att meddelandena kommer från en specifik domän, samt att meddelanden skickas till en specifik domän. På detta sätt kan vi vara säkra på att inga meddelanden skickas från en felaktig domän, samt att inga meddelanden skickas till en felaktig domän.

För att testa detta så behöver vi två sidor, A.html samt B.html. Den förstnämnda kommer att ha en iframe med den andra sidan och kommer att skicka meddelanden till denne när användaren klickar på en knapp. När meddelanden har kommit fram så kommer ett svar tillbaka som säger att det lyckades.

A.html:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>Cross Document Messaging</title>
    <script type="text/javascript">
        window.attachEvent('onmessage', function(e) {
            document.getElementById('message').innerHTML = e.data;
        });
        
        function SendXDMMessage() {
            var msg = document.getElementById('receiver');
            msg.contentWindow.postMessage('Hello, B!', '*');
        }
    </script>
</head>
<body>
    <iframe src="B.html" id="receiver" style="width: 500px; height: 200px;"></iframe>
    <br />
    <div id="message"></div>
    <input type="button" value="Skicka meddelande" onclick="SendXDMMessage()" />
</body>
</html>

B.html:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>Cross Document Messaging</title>
    <script type="text/javascript">
        window.attachEvent('onmessage', function(e) {
            document.getElementById('message').innerHTML = e.data;
            e.source.postMessage('Hello, A!', '*');
        });
    </script>
</head>
<body>
    <div id="message"></div>
</body>
</html>

För att testa detta så skall vi först öppna A.html. När vi klickar på knappen där så anropas SendXDMMessage(), vilken skickar ett meddelande till den iframe som vi plockar fram. Den andra parametern i anropet visar vilken domän vår iframe måste innehålla, genom att ha en asterisk så spelar det ingen roll. Vill vi att det ska vara en specifik domän så bör vi ange den istället för asterisken.

Vi har även sett till att vi  sätter innerHTML på div-elementet med data som skickas till A.html.

I B.html så väntar vi på att ett meddelande skall tas emot, och när vi får ett så sätter vi innerHTML på div-elementet till värdet som har skickats. Om vi vill vara säkra på att meddelandet kommer från en specifik domän så kan vi använda e.origin för att se vilken domän anropet kommer från. När vi har satt värdet i div-elementet så returnerar vi ett meddelande till A.html.

Med Cross Document Messaging kan vi alltså skicka meddelanden fram och tillbaka mellan två olika domäner på ett väldigt smidigt sätt.

Det är nog ingen som har missat att Internet Explorer 8 släpptes i förrgår, men det är däremot inte alla som vet vilka nyheter som finns för utvecklare, utöver den nya sökningen, web slices och acceleratorer. En av dessa nyheter är XDomainRequest som gör det möjligt att med javascript köra anrop mot andra servrar.

Det är dock ej möjligt att göra anrop mot vilken sida som helst, utan en HTTP-header måste sättas på den sidan som anropas, av säkerhetsskäl.

Till att börja med så skall jag använda en handler som skall anropas från javascriptet.

<%@ WebHandler Language="C#" Class="XDR" %>
using System.Web;
 
public class XDR : IHttpHandler
{
 
    public void ProcessRequest(HttpContext context)
    {
        context.Response.AddHeader("Access-Control-Allow-Origin", "*");
        context.Response.ContentType = "text/plain";
        context.Response.Write("Hello, XDR!");
    }
 
    public bool IsReusable
    {
        get
        {
            return false;
        }
    }
}

Det här är en helt vanlig webhandler, med undantaget att vi skickar med en extra header med namn “Access-Control-Allow-Origin”. Värdet för denna är i exemplet “*”, vilket betyder att anropet skall kunna göras från vilken domän som helst. Vill vi begränsa oss till t.ex. enbart vår egen domän så kan vi skriva in den där istället.

För att se hur det ser ut så kan ni klicka här. Jag har lagt upp sidan publikt för att ni enkelt skall kunna göra tester mot den själva.

För att nu kunna anropa filen så skall vi skapa upp ett XDomainRequest-objekt med javascript.

if (window.XDomainRequest) {
    //Skapa XDomainRequest-objektet
    var xdr = new XDomainRequest();
    
    //Hantera events
    xdr.onerror = function() { alert('Ett fel uppstod') };
    xdr.onload = function() { alert(xdr.responseText) };
    
    //Anslut mot servern
    xdr.open("get", "http://dev.mikaelsoderstrom.se/scripts/asp.net/xdr.ashx");
    xdr.send();
    
}
else {
    alert('Din webbläsare har inte stöd för XDomainRequest!');
}

Det vi gör här är att först och främst se om webbläsaren har stöd för XDomainRequest, vilket är ett krav för att det öht skall gå att skapa anropet. Sedan skapas objektet och vi tar hand om två olika event, ett som sker om ett fel uppstår och ett som sker när anropet är slutfört.

Om vi nu kör den här koden rakt av i Internet Explorer 8 så bör vi få upp en alert-ruta med texten “Hello, XDR!”.

För att se så att kontrollen fungerar som väntat så kan vi testa att kommentera bort raden i handlern där vi sätter headern. Om vi gör det så kommer vi istället att få “Ett fel uppstod” då vi inte längre har rätt att anropa filen.

More Posts Next page »