Bemærk
Viser kun indlæg med etiketten Webudvikling. Vis alle indlæg
04-07-2008

Gravatars på bittert.net

Gravatars på bittert.net

Det er nu muligt at tilknytte et billede til sine kommentarer på bittert.net.

Som det kan ses på billedet til højre vises der et billede til alle kommentarer. For at få vist sit billede skal man oprette sig på Gravatar.com og uploade det billede man gerne vil bruge.

Gravartar står for globally recognized avatar, så dit billede er således også tilgængeligt for alle andre sites.

Billederne skal helst være kvadratisk og ikke større end 80x80 pixels, men der er mulighed for at tilpasse sit billede når man uploader det.

Her på siden indhentes billederne vha. e-mail-adressen. Den krypterers så den umiddelbart ikke er tilgængelig for alle. Hvis man ikke har oprettet en gravatar, får man alligevel et billede i stil med:

Gravatar

Det samme gælder hvis man ikke angiver sin e-mail-adresse; så får man bare et billede genereret ud fra din IP.

Mht. koden bag har jeg lænet mig op af en artikel om emnet og så tilpasset lidt til mine egne behov. Det er jo utrolig simpelt når man har et godt udgangspunkt.

Herunder ses den funktion jeg kalder for at få billede-adressen:

post.aspx.cs
  1. protected string GetGravatarUrl(object dataItem)
    
  2. {
    
  3.     string toBeHashed;
    
  4.     if (DataBinder.Eval(dataItem, "email").ToString() != "")
    
  5.         toBeHashed = (string)DataBinder.Eval(dataItem, "Email");
    
  6.     else
    
  7.         toBeHashed = (string)DataBinder.Eval(dataItem, "IP");
    
  8.     string hash = System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(toBeHashed.Trim().ToLower(), "MD5");
    
  9.     hash = hash.Trim().ToLower();
    
  10.     string gravatarUrl = string.Format("http://www.gravatar.com/avatar/{0}?size=60&d=wavatar", hash);
    
  11.     return gravatarUrl;
    
  12. }

Jeg håber I kan lide det nye tiltag - man kan sige der er kommet lidt facebook over bittert.net nu. fun

Etiketter: Webudvikling
22-06-2008

Bedre formatering af kildekoden på bloggen

Når man skal læse kildekode er det en stor hjælp, hvis den er formateret med forskellige farver og linjenumre. Derfor har jeg undersøg, hvad der er af forskellige muligheder for at få det tilføjet her på siden, på en let måde.

Der er adskillige alternativer at vælge imellem, men ingen af dem er helt optimale. Den første mulighed jeg løb ind i var Manolis source code formatter som ved første øjekast ser ud til at kunne det jeg skulle bruge, og jeg har mulighed for selv atpotentielt at tilrette den efter behov. Slet ikke dumt at få det inkluderet på siden her, men alligevel lidt for besværligt til at jeg lige magtede at sætte mig ind i hvordan.

Koden der bliver lavet er heller ikke helt perfekt. Det er ikke alt kode der får den rette farve; f.eks. bliver nogle classer som StringBuilder, ClientScriptManager og String ikke farvet.

Et problem med alle de værktøjer der kan tilføje linjenumre er at tallene bliver en del af teksten, således man ikke længere kan kopiere koden uden at få linjenumrene med - det er jo ikke optimalt.

For at undgå at markere linjenumrene med skal det hele laves til en nummereret punktopstilling, men det gjorde ingen af dem jeg fandt.

For at få alle koder farvet korrekt som de bliver Visual Studio, har jeg været nødt til at gøre brug af et plug-in til Windows Live Writer. Ja, ikke optimalt, men det er ret ligetil.

  1. Hent Windows Live Writer (Sørg for ikke at hente alt det andet crap den gerne vil sælge med)
Live Writer med Paste from Visual Studio-plug-in

Der findes adskillige værktøjer til Live Writer i Live Gallery, men jeg foretrækker den der hedder Paste from Visual Studio, da den formaterer det præcist, som det står i Visual Studio

  1. Hent plug-in'et Paste from Visual Studio

Nu kan koden fra Visual Studio kopieres ind i Live Writer og derved fås html-koden. Desværre bruges der ikke stylesheet, så det giver en del kode, men det kan jeg leve med. Det eneste der mangler er linjenumre. Det er dog forholdsvis simpelt at tilføje med en tekstboks (TB_Kode) og en knap (B_Linjer):

  1. protected void B_Linjer_Click(object sender, EventArgs e)
    
  2. {
    
  3.     string Kode = TB_Kode.Text;
    
  4.     Kode = "<ol class=\"kode\"><li><pre>" + Kode;
    
  5.     Kode = Kode + "</pre></li></ol>";
    
  6.     Kode = Kode.Replace("\n", "</pre></li><li><pre>");
    
  7.     TB_Kode.Text = Kode;
    
  8. }

Der kan dog være et problem mht. valid XHTML, når der ikke skiftes farve fra én linje til den næste; men det er ikke et stort problem i forhold til det kode, jeg har haft indtil nu her på siden. Hvis det bliver et problem må jeg jo lave en knap mere...

Resten er bare CSS:

StyleSheet.css
  1. ol.kode
    
  2. {
    
  3.     padding: 10px;
    
  4.     border: dashed 1px #000000;
    
  5.     font: 9pt Consolas, "Courier New", Courier, Monospace;
    
  6.     width: 464px;
    
  7.     color: #2b91af;
    
  8.     overflow: auto;
    
  9.     margin: 0px;
    
  10. }
    
  11. ol.kode pre
    
  12. {
    
  13.     margin: 0em;
    
  14.     padding: 1px 5px;
    
  15.     border-left: dotted 1px #2b91af;
    
  16.     font: 10pt Consolas, "Courier New", Courier, Monospace;
    
  17.     color: #000;
    
  18. }
    
  19. ol.kode li
    
  20. {
    
  21.     margin: 0em 0em 0em 30px;
    
  22. }
    
  23. span.kodeoverskrift
    
  24. {
    
  25.     color: #000;
    
  26.     font: 10pt Consolas, "Courier New", Courier, Monospace;
    
  27.     font-weight: bold;
    
  28.     margin-left: 5px;
    
  29.     position: relative;
    
  30.     bottom: -6px;
    
  31.     background-color: White;
    
  32. }

Måden her er måske hverken den bedste eller mest elegante måde, men det virker og er utrolig let at implementere.

Etiketter: Webudvikling
19-06-2008

Fjern live.com spam fra Woopra

Jeg anvender Woopra til at holde øje med besøgsstatistikken her på bittert.net, men som Mikkel Langelykke også nævner på sin blog så spammer live.com ens side med en masse ligegyldige hits, som efter alt at dømme er foretaget af en bot.

Så det vil man jo gerne have fjernet fra sine statistikker og det kan ses at søgningerne kommer fra IPerne 65.55.109.xxx og 65.55.110.xxx, som jo så bare ikke skal præsenteres for woopra-koden. Mikkel har havet hans løsning i php - så jeg vil her fortælle, hvordan man kan gøre i asp.net.

MasterPage.Master.cs
  1. if (!Regex.IsMatch(Request.UserHostAddress, @"^65\.55\.(109|110)\.(\d{1,3})$") && !Page.IsPostBack)
    
  2. {
    
  3.     Type cstype = this.GetType();
    
  4.     ClientScriptManager cs = Page.ClientScript;
    
  5.     String csname = "WoopraScript";
    
  6.     if (!cs.IsClientScriptBlockRegistered(cstype, csname))
    
  7.     {
    
  8.         StringBuilder cstext = new StringBuilder();
    
  9.         
    
  10.         // Woopra-kode
    
  11.         cstext.Append("<script type=\"text/javascript\">");
    
  12.         cstext.Append("var woopra_id = '#########';"); 
    
  13.         cstext.Append("</script>");
    
  14.         cstext.Append("<script type=\"text/javascript\" src=\"http://static.woopra.com/js/woopra.js\"></script>");
    
  15.         
    
  16.         
    
  17.         cs.RegisterClientScriptBlock(cstype, csname, cstext.ToString(), false);
    
  18.     }
    
  19. }

Vi starter med at kontrollere om IPen matcher en IP der starter med 65.55. og så endten 109 eller 110. Den sidste gruppe af tal må være et tal på en til tre cifre. Matcher IP denne Regular Expression vil Regex.IsMatch retunere true, men ! foran Regex.IsMatch betyder not og bytter således om på true og false.

Da det er regular expressions vi anvender skal der også tilføjes et Namespace øvest i codebehind-filen MasterPage.master.cs:

MasterPage.Master.cs
  1. using System.Text.RegularExpressions;

Da kode og webdesign er adskilt fra hinanden i asp.net, skal vi bruge en ClientScriptManager for at få sent javascript fra codebehind til aspx-sidens header.

Der kontrolleres først om vores script tidligere er sendt, så det ikke gøres to gange. Herefter bruges en StringBuilder til at lave en string med Woopra-koden. Tilsidst registreres scriptet, hvilket betyder det bliver skrevet i headeren på aspx-siden.

Ønsker man ikke selv at tælle med i Woopra-statistikken kan man jo tilføje Request.UserHostAddress != "xxx.xxx.xxx.xxx" i den første betingelse:

  1. if (Request.UserHostAddress != "127.0.0.1" && !Regex.IsMatch(Request.UserHostAddress, @"^65\.55\.(109|110)\.(\d{1,3})$") && !Page.IsPostBack)

Etiketter: Webudvikling
05-06-2008

HTML 5 til forbedring af brugervenligheden

Den 22. januar i år blev det første udkast af HTML 5 udgivet af W3C. Jeg har derfor kigget lidt på W3Schools HTML 5 Reference for at finde ud af, hvilke nye muligheder det kan give.

Jeg har derfor valgt at forbedre brugervenligheden, når teksten i CAPTCHA-billedet skal angives. At anvende CAPTCHA er jo ikke ligefrem brugervenligt, men en nødvendighed for at forhindre bots i at tilføje "kommentarer". Derfor bør man jo gøre det så let som muligt for sine brugere at indtaste teksten i billedet, og det er så det jeg har forsøgt at gøre.

HTML 5 giver mulighed for at angive en dataliste som man så kan knytte til et tekstfelt via attributten list. På den måde kan man så bare vælge koden fra en dropdown-liste:

Dataliste tilknyttet et tekstfelt

Man kunne også have lavet en lignende løsning med en almindelig dropdown-boks, men jeg synes jo det er lidt sjovere at bruge de nye muligheder HTML 5 giver, selvom det også indebærer en del problemer.
For det første er Opera og Safari endnu de eneste browsere der understøtter en smule HTML 5, så tilgængeligheden af min dataliste må siges at være ret begrænset.
For det andet er de nye tags ikke en del af XHTML 1.1 så den fejler når der valideres. Well who cares?

Etiketter: Webudvikling
29-04-2008

Send xml til de browsere der kan håndtere det

Som jeg tidligere har beskrevet har jeg haft lidt problemer med at få mine siders ContentType korrekt, således at mine xhtml 1.1 sider bliver sendt som xml i stedet for text/html.

Problemerne er nu blevet løst. Mine problemer har primært været at sende den rigtige ContentType når der W3C valideres, for jeg fandt hurtigt noget kode der kunne klare det meste; nemlig kontrollere om browseren kan modtage xml og så sende det til den, hvis den kan håndtere det. Problemet er så kun at W3Cs validator returnerer null til Request.AcceptTypes, så når koden valideres får man stadig advaslen: Conflict between Mime Type and Document Type.
Jeg har derfor tilføjet lidt kode der ser på om det er W3C Validatoren der kigger forbi:

Global.asax
  1. <%@ Application Language="C#" %>
    
  2. <script runat="server">
    
  3.     
    
  4.     protected void Application_PreSendRequestHeaders(Object o, EventArgs e)
    
  5.     {
    
  6.         if (Request.AcceptTypes != null)
    
  7.         {
    
  8.             String MyRequest = Request.PhysicalPath.ToString();
    
  9.             if (MyRequest.EndsWith(".aspx"))
    
  10.             {
    
  11.                 if (Response.ContentType == "text/html")
    
  12.                 {
    
  13.                     if (Array.IndexOf(Request.AcceptTypes, "application/xhtml+xml") >= 0)
    
  14.                     {
    
  15.                         Response.ContentType = "application/xhtml+xml";
    
  16.                         Response.AddHeader("Vary", "Accept");
    
  17.                     }
    
  18.                 }
    
  19.             }
    
  20.         }
    
  21.         else
    
  22.         {
    
  23.             if (Request.UserAgent.IndexOf("W3C_Validator") >= 0)
    
  24.             {
    
  25.                 Response.ContentType = "application/xhtml+xml";
    
  26.                 Response.AddHeader("Vary", "Accept");
    
  27.             }
    
  28.         }
    
  29.     }
    
  30.     
    
  31. </script>

Desværre er dette ikke tilstrækkeligt til at få W3C validatoren til at validere på den samme kode som sendes til en almindelig browser. Man er nødt til også at lave en .browser fil i mappen App_Browsers med følgende kode:

Læs resten af indlæget...

Etiketter: Webudvikling
16-04-2008

Hvor jeg dog hader Internet Explorer

I al den tid jeg har konstrueret hjemmesider, har jeg hadet alle de ekstra linjer kode, man skal skrive for at Internet Explorer (IE) kan reagere som den skal.

Nu havde jeg så sat mig for at gøre bittert.net XHTML 1.1 valid, og der var kun én "rigtig" fejl og to advarsler - så det skulle ikke være det store problem.

Den rigtige fejl, var en name-attribut i et form-element, der jo ikke må være der. Det var dog ikke noget jeg selv var skyld i, men noget asp.net selv har genereret. Heldigvis var det ikke særlig vanskeligt at bede asp.net om at lade være med de unoder. Tilføj blot følgende kode i web.config under system.web:

  1. <xhtmlConformance mode="Strict"/>

Den første af de to advarsler lød: Character Encoding mismatch! Det var noget med at http-headeren brugte én type (utf-8), og dokumentet en anden (iso-8859-1).
Jeg ville gerne have den til at bruge iso-8859-1 i http-headeren også, så jeg tilføje følgende kode i web.config under system.web.

  1. <globalization culture="da-DK" uiCulture="da-DK" fileEncoding="iso-8859-1" requestEncoding="iso-8859-1" responseEncoding="iso-8859-1"/>

Den sidste advarsel er der stadig, men jeg fandt da ud af, hvad der var galt. Advarslen lyder: Conflict between Mime Type and Document Type.
Den brokker sig altså over, at jeg sender siden som text/html, når dokumentet er af typen xhtml 1.1. W3C synes således, jeg i stedet skal sende siden som application/xhtml+xml. Det lyder jo fair nok, så jeg tilføjede attributten ContentType i Page-elementet øverst på forsiden.

  1. ContentType="application/xhtml+xml"

Det fungerer til fulde i både Opera og Firefox, men IE fucker up. Den bliver bitter og begynder at spørge, om jeg vil downloade aspx-dokumentet. Så det er jo flot. MS har dog lavet en artikel om hvordan man kan kombinere asp.net og webstandarder og jo, det er da også ok, når man har gjort de ting de skriver man skal for at IE kan følge med, men det er da bare virkelig træls at skulle gøre.

Jeg har da også valgt at gå tilbage til bare at sende den gode gamle text/html, fordi xml stiller meget strænge krav til strukturen i dokumentet og kommer med en fejl og vil ikke vise dokumentet, hvis der er den mindste fejl.
Hvis jeg selv styrede alt input på siden, ville det ikke være så vigtigt, men når jeg nu har givet mulighed for kommentering med tekstformatering, kan det let ske at der vil komme mindre fejl i strukturen.

Der er således stadig en lille "fejl" når W3C validerer.

Det er så heller ikke helt så let at validere aspx sider som det er med de mere normale htm-, asp- eller php-sider. Validatoren kan ikke bruge referer til at få fat i filen der skal valideres. Det skyldes at outputtet fra en aspx-fil afhænger af hvem der læser den. Der sendes således ikke den samme kode til en mobil-enhed som til en almindelig pc.

Vil man validere en aspx-side skal man altså gemme den html-kode der genereres (højreklik | Vis kilde) og så validere ved at uploade den.

Højrekliksmenu i Opera med mulighed for at validere

Det er selfølgelig noget forbandet bøvl og ikke noget man vil gide at gøre særlig ofte, men heldigvis kan det gøres let med det rette værktøj.
Opera, viser sig endnu engang som værende den bedste browser på markedet ved at give mig mulighed for at validere via en højrekliksmenu. Yndlings Opera!

Etiketter: Bittert! | Webudvikling
Side 3 af 3 Navigation: 1 2 3