To remedy this use this snippet of code:

public static class ControllerHelpers
{
  public static bool TryUpdateGenericModel(this Controller controller, object model)
  {
    var param = new Type[] { model.GetType() };
    var controllerType = controller.GetType();
    var controllerMethods = controllerType.GetMethods(BindingFlags.NonPublic | BindingFlags.Instance);
    var TUMmethod = controllerMethods.First(x => x.Name.StartsWith("TryUpdateModel") && x.GetParameters().Count() == 1);
    var TUMgeneric = TUMmethod.MakeGenericMethod(param);
    var result = TUMgeneric.Invoke(controller, new object[] { model });
    return (bool)result;
  }
}

And in your controller when trying to update your model, use it like this:

var emptyModelObject = Activator.CreateInstance(modelType); // whichever way you get it doesn't really matter.
var result = this.TryUpdateGenericModel(modelObject);

Let’s start with an example of the problem. We use a repository pattern to encapsulate our Linq our Linq-queries into manageable and reusable componentes. Are repository can look kindof like this:

public class ClipRepository : IClipRepository
{
    IDataContext _dc;
    IDataContext dc
    {
        get
        {
            if (_dc == null)
            {
                _dc = new PiratDataContext();
            }
            return _dc;
        }
    }
    public IQueryable getClipsFromSite(int siteid)
    {
        return from sc in dc.SiteClips
        where sc.SiteID == siteid
        select sc.Clip;
    }
}

The repository implements a IClipRepository interface an all code that depends on the repository is written against the interface instead of the specific implementation. This is great because we can then switch from a database backend-implementation to, say, a cachebackend without changing any of the dependant code. We use a servicelocator to provice simple inversion-of-control and break dependencies, and as a bonus, we can write unittest of code that uses the repository be reconfiguring the servicelocator to return a MockedClipRepository instead of the real one.

However, as mentioned above, the DataContext itself does not implement an interface, so we cannot use the servicelocator to provide the datacontext, and therefore we cannot really unittest our repositories without great difficulty.

Wrapping the DataContext

C# is flexible – with generics we can create a proxy class around a DataContext, and we can make that class implement a suitable interface.

public interface IDataContext
{
    /// <summary>
    /// Gets the repository for the given type of entities
    /// </summary>
    /// <typeparam name="T">The type of the entity</typeparam>
    /// <returns>The repository of the given type</returns>
    IQueryable<t> GetTable<t>() where T : class, INotifyPropertyChanged;
 
    /// <summary>
    /// Adds a new entity to the repository
    /// </summary>
    /// <typeparam name="T">The type of the entity</typeparam>
    /// <param name="item">The entity to add</param>
    void Insert<t>(T item) where T : class, INotifyPropertyChanged;
 
    /// <summary>
    /// Deletes the specified entity from the repository
    /// </summary>
    /// <typeparam name="T">The type of the entity</typeparam>
    /// <param name="item">The entity to delete</param>
    void Delete<t>(T item) where T : class, INotifyPropertyChanged;
 
    /// <summary>
    /// Commits the changes to the repository
    /// </summary>
    void Save();
 
    /// <summary>
    /// Provides access to the modified objects tracked by the system
    /// </summary>
    ChangeSet GetChangeSet();
}

And the wrapper class implementation for LinqToSql datacontexts:

public class LinqToSqlDataContext<t_datacontexttype> : IDataContext where T_DataContextType : DataContext
{
    private DataContext _dc;
    private DataContext dc
    {
        get
        {
 
            if (_dc == null)
            {
                _dc = Activator.CreateInstance<t_datacontexttype>();
            }
            return _dc;
        }
    }
 
    public IQueryable<t> GetTable<t>() where T : class, INotifyPropertyChanged
    {
        return dc.GetTable(typeof(T)).Cast<t>();
    }
 
    public void Insert<t>(T item) where T : class, INotifyPropertyChanged
    {
        dc.GetTable(typeof(T)).InsertOnSubmit(item);
    }
 
    public void Delete<t>(T item) where T : class, INotifyPropertyChanged
    {
        dc.GetTable(typeof(T)).DeleteOnSubmit(item);
    }
 
    public void Save()
    {
        dc.SubmitChanges();
    }
 
    public ChangeSet GetChangeSet()
    {
        return dc.GetChangeSet();
    }
 
    #endregion
}

Using the wrapper

With this wrapper in place, we then change the implementation of the repository above so that instead of creating it’s datacontext directly it uses the wrapper:

// creating the context
// in the ServiceLocators config, IDataContext is setup to return LinqToSqlDataContext<piratdatacontext>
_dc = ServiceLocator.New<idatacontext>();
 
// using it
return from sc in dc.GetTable<siteclip>()
         where sc.SiteID == siteid
         select sc.Clip;

Unit testing

With the above setup we can now create a MemoryDataContext, that has the same interface as the LinqToSql context, but does not depend on a database:

public class MemoryDataContext : IDataContext
{
    private readonly List<object> _inMemoryDataStore = new List<object>();
    private readonly IList<object> _Inserts = new List<object>();
    private readonly IList<object> _Deletes = new List<object>();
    private readonly IList<object> _Updates = new List<object>();
 
    public MemoryDataContext()
    {
    }
 
    public MemoryDataContext(params INotifyPropertyChanged[] objects) : this()
    {
        foreach (var obj in objects)
        {
            _insert(obj);
        }
    }
 
    private void _insert(INotifyPropertyChanged item)
    {
        _inMemoryDataStore.Add(item);
        item.PropertyChanged += new PropertyChangedEventHandler((s,e) => _Updates.Add(s));
    }
 
    public IQueryable<t> GetTable<t>() where T : class, INotifyPropertyChanged
    {
        var list = from objects in _inMemoryDataStore
                    where typeof(T).IsAssignableFrom(objects.GetType())
                    select objects as T;
        return list.AsQueryable();
    }
 
    public void Insert<t>(T item) where T : class, INotifyPropertyChanged
    {
        _insert(item);
        _Inserts.Add(item);
    }
 
    public void Delete<t>(T item) where T : class, INotifyPropertyChanged
    {
        _inMemoryDataStore.Remove(item);
        _Deletes.Add(item);
    }
 
    public void Save()
    {
        if (Completed != null)
        {
            Completed(this, EventArgs.Empty);
        }
    }
 
    public ChangeSet GetChangeSet()
    {
        var constructor = typeof(ChangeSet).GetConstructors(BindingFlags.Instance | BindingFlags.NonPublic).First();
        var changes = constructor.Invoke(new object[]
        {
            new ReadOnlyCollection<object>(_Inserts),
            new ReadOnlyCollection<object>(_Deletes),
            new ReadOnlyCollection<object>(_Updates),
        }) as ChangeSet;
 
        return changes;
    }
 
    public event EventHandler Completed;
}

And there – we can now write unittests of our repository methods like this:

        [TestInitialize]
        public void init()
        {
            var memContext = new MemoryDataContext();
            memContext.Insert(new Clip { ID = 1, Title = "hest" });
            memContext.Insert(new Clip { ID = 2, Title = "giraf" });
            memContext.Insert(new Clip { ID = 3, Title = "tobis" });
            memContext.Insert(new Clip { ID = 4, Title = "laks", AllowExternalEmbedding = true });
            memContext.Insert(new SiteClip { ClipID = 1, SiteID = 50 });
            memContext.Insert(new SiteClip { ClipID = 2, SiteID = 50 });
            memContext.Insert(new SiteClip { ClipID = 3, SiteID = 4 });
            memContext.Insert(new SiteClip { ClipID = 4, SiteID = 4 });
            memContext.Insert(new SiteClip { ClipID = 4, SiteID = 50 });
 
            ServiceLocator.Add(typeof(IDataContext), memContext);
        }
 
        [TestMethod]
        public void getClipsFromSiteTest()
        {
            ClipRepository target = new ClipRepository();
            Assert.AreEqual(3, target.getClipsFromSite(50).Count());
            Assert.AreEqual(2, target.getClipsFromSite(4).Count());
            Assert.AreEqual(0, target.getClipsFromSite(1).Count());
        }
    }

During the development of SKUM3 some problems have not manifested themselves while developing for one simple reason: Visual Studio 2008 uses a version of IIS 6 as a development server, but our final setup will be an IIS 7 server. The differences between these two version are significant enough to cause headaches.

One such headache is the inability to debug code running on the remote server. This combined with differences in how errors are handled, both in the setup in the web.config file, and in the way a custom error handler is called, produced a very difficult to solve problem. Also a lack in documentation is partly to blame.

The problem

web.config differences.

IIS 7 version:

<httpErrors>
    <remove statusCode="404" subStatusCode="-1" />
    <error statusCode="404" prefixLanguageFilePath=""
        path="/path/to/handlerwebservice"
        responseMode="ExecuteURL" />
</httpErrors>

 IIS 6 version:

<customErrors mode="On">
    <error statusCode="404" redirect="webservices/media/image"/>
</customErrors>

With the IIS 6 version all 404 errors are redirected to webservices/media/image?aspxerrorpath=original/path. In IIS 7 though this querystring parameter is missing so what to do?

The Solution

Well, microsoft is not very helpful and I tried asking my question to the Internet but as I didn’t receive any answers I just tried changing

context.Request.Path

to

context.Request.RawUrl

Resulting in this code to handle the differences:

string requestpath;

if(context.Request.QueryString.AllKeys.Contains("aspxerrorpath"))
{
    requestpath = context.Request.QueryString["aspxerrorpath"];
}
else
{
    requestpath = context.Request.RawUrl;
}

This seemed to have the desired effect. The difference between these two are that RawUrl contains the requested path unaltered by redirection or anything else and Path is the Url after any redirection. I had forgotten this minor detail even though I’ve used it in the breadcrumb method to split an original path up into individual pieces, after the request had been redirected by our UrlRewriter.

If you are getting weird errors about httpErrors being locked down use a cheat code

%windir%\system32\inetsrv\appcmd.exe unlock config -section:system.webServer/httpErrors

Jeg skriver at det er uden problemer og det er en sandhed med modifikationer. Det er problemfrit når man bare bruger det som tekst rendering og ikke forventer at det kan redde verden. Det virker i de fleste grade A browsere. Lige netop det at det ikke virker i alle grade A browsere er det som denne artikel handler om.

I Opera virker det nemlig overhovedet ikke. Det påstås heller ikke fra forfatterens side, men det virkede lidt underligt at det ikke skulle virke, for Opera plejer at opføre sig ordentligt det meste af tiden.

Efter en hurtig omgang debugging i typeface kilden med Operas indbyggede debugger værktøj, fandt jeg ud af at Opera opfattede at de elementer som skulle have specielle fonte, skulle renderes med Arial. Det er jo ikke rigtigt til at forstå, eftersom Arial ikke var i stylesheet’et. Jeg kom frem til at Opera måtte smide specialfonten væk, fordi den ikke kunne finde den, og så bruge det den troede man havde brug for i stedet.

Efter en del søgen på det store Internet fandt jeg et indlæg i Operas developer forum om emnet. Det som Operas udvikler svarer er at de har taget en design beslutning og implementeret det på den måde de har. w3’s specifikation på området omkring computed styles (den værdi som der bliver hentet ud i dette tilfælde, og som indeholder beregnede værdier af de værdier som står i stylesheet’et) er yderst vag, og den beskriver kun at man skal lave pixel beregninger og sørge for at inherit værdier er ændret til de værdier som skal bruges. Mozilla skriver i deres developer central wiki at de faktisk har snydt lidt og bruger used styles som resultat af computed styl, men det ændrer ikke ved at de returnerer det rigtige resultat, nemlig en streng som indeholder en kommasepereret liste af de fonte som er i stylesheet’et. Forhåbentligt går der ikke mange dage før Opera har rettet op på denne fejl. Indlægget blev besvaret i går af en af deres udviklere og han skriver:

This was by design but will be “fixed”

Så man har to valg:

• Vente og se hvornår de får implementeret den nye funktionalitet
• Implementere en traversering af tilknyttede stylesheets for at finde de regler som berører netop de elementer man har brug for

I dette tilfælde vil det nok være lidt nyttesløst at vælge det sidste, eftersom der ikke er nok der bruger Opera til at det giver mening, derudover er Opera ikke en standardbrowser på nogen platform, så folk der bruger Opera kan se siden i mindst én anden browser.

Hvis man endelig skulle vælge vej nummer 2 og kigge stylesheet’ene igennem, så skulle man nok implementere et fuldt css bibliotek, som også vil kunne bruges til at udjævne forskelle mellem browsere i forhold til implementationer af nuværende standarder og også i forhold til at implementere kommende standarder, indtil browserne selv gør det. Javascript er jo netop nået et punkt hvor det er gjort så hurtigt at det ikke vil betyde store ventetider at have store scripts.

Den browser som givers os flest problemer er jo selvfølgeligt Microsofts Internet Explorer version 6.

En af de utallige bugs vi har haft problemer med er at vi har nogle popup-elementer som sidder på vores brugerprofiler. Det virker som det skal i alle andre browsere, men ie6 synes ikke at det z-index popup-elementet har fået er godt nok og derfor vil den måske kunne skjule det bag andre elementer.

Måden den skjuler elementet på var dog ikke lige til at finde ud af, for det var kun nogen elementer der gemte popup’en. Efter lidt undersøgelse fandt jeg at de elementer der skjuler popup-elementet var relativt positioneret. og det element som popupen var i også var relativt positioneret. Det viser sig nemlig at ie6 ikke er tilfreds med at hvert element har deres helt eget z-index. I stedet siger den at den boks som elementet er inden i ligger i et lag for sig selv, som ingen andre elementer udefra kan komme imellem.

Dette betyder at man kan komme et hvilket som helst z-index på popup-elementet, det er stadig relativt i forhold til det element det er indeni. Og elementer der kommer umiddelbart efter vil, i kraft af at de kommer senere i dokumentet, overlappe ved “by-design” at have et højere z-index (på en måde). For atfå ie6 til at tegne det ordentligt, så bliver man nødt til at sætte z-index’et på popup-elementets relative parent til et andet højt z-index.

For mere dybdegående information: http://aplus.rs/lab/z-pos/

Det er mig en gåde hvorfor jeg dengang syntes at det var skægt, og efterhånden som jeg blev ældre lagde min fascination af den her helt særlige form for totur sig, og blev afløst af en langt mere naturlig foragt for den slags programmering. Ikke at jeg synes man skal svine unødigt med hukommelse, men inden for moderne udvikling så kan det simpelthen ikke være rigtigt at programmøren selv skal side og manuelt tilrette hver eneste datastruktur, og selv sidde og finde hver eneste lille ekstra byte ud af hukommelsen – og det ER selv følgelig heller ikke rigtigt. Med garbage collection, smartere compilere og nærmest uendelig performance og hukommelse så er det ikke noget programmører i dag nogensinde prøver at beskæftige sig med.

Derfor har det også overrasket mig pænt meget, når jeg tænker tilbage på hvad jeg har lavet den sidste uge. Jeg har siddet og kigget på lange, lange stackdumps, aflæst hvor meget hukkomelse hver enkelt object bruger, flyttet rundt på kode, tænkt datastrukturer om og klappet i mine små hænder hver gang jeg har sparet 15-20 bytes. Præcis som da jeg var en lille dreng på DTU – forskellen er bare at i dag hader jeg det som pesten.

Det jeg laver er at gå alle vores ASP.NET controls igennem og få styr på hvor meget de plads de bruger når de er serialiseret ud i ASP.NETs ViewState. 200 controls, hvoraf hveranden gemmer bare 100 bytes i viewstate giver 10kb i ViewState, og det bliver overført frem og tilbage mellem server og klient hvert eneste gang siden forsager et postback – og med moderne ting som AJAX og asynkrone postbacks, så kan det ske masser af gange i minuttet. I Skum 3 har vi nogen widgets (Skum fiduser) og hver gang de bliver flyttet melder de tilbage til serveren, at de bor et andet sted igennem et postback: Med et ViewState på 10kb skal man kun flytte en widget 50 gange, før man har overført en megabyte data. Ingen billeder, ingen ting, bare retursvar til serveren om hvor den her widget bor nu.

Med andre ord, hvis man ikke passer ekstremt meget på hvad man har i ViewState laver man meget, meget nemt den største og tungeste website nogensinde – uden at man får noget ekstra funktionalitet ud af det.

Så nu går jeg altså alle vore controls igennem en for en og sikrer mig at de ikke sviner i ViewState, ligesom programmørene i 1978 gik deres C eller Fortran kode igennem funktion for funtion, og datastruktur for datastruktur for at sikre sig de ikke svinede med hukommelsen. Jeg har lært mig følgende regler som alle folk burde følge når de udvikler ASP.NET controls:

1. Det eneste der skal bo i ViewState er information som er direkte forsaget af en brugers handlinger, og ikke er gemt i databasen endnu.
2. Alt, hvis værdi på nogensomhelst måde kan sættes før eller under en controls init-event skal sættes der. Efter Init event’et tracker ViewState og så bliver alting serialiseret ud til klienten.
3. I UserControls skal alle værdier der overhovedet kan sættes i .ascx filen (som properties på et tag) sættes der. Den slags properties bliver sat før ViewState begynder og tracke, og derfor sviner de ikke i ViewState.
4. Hvis man endelig ikke kan undgå at noget skal være i ViewState, så vær ekstremt omhyggelig med hvad du kommer derind. Alt andet end strings, bytes, bools og andre simple typer bliver serialiseret med en byteserializer der er ekstremt ueffektiv. Controls i ViewState er især super forbudt – brug ID’er i stedet. Overload hellere SaveViewstate og LoadViewstate en gang for meget end en gang for lidt.

ViewState kan være svært at forstå, og det er svært at læse sig frem til hvad det er og hvad det gør, hvis man kun bruger Microsofts dokumentation. Den her artikel er absolut den bedste jeg har set om ViewState og det bør være “required reading” for alle der har med ASP.NET at gøre:

Infinities Loop: Truly Understanding Viewstate

Visual Studio Source Safe er IKKE et versionsstyringssoftware! Det er et filkontrolsystem designet til at kun én person kan arbejde på en fil samtidigt. Sletter man filer fra ens kodetræ, så skal man først ofre 7 jomfruer og derefter håbe på at ingen andre har problemer med at få opdateret deres træ. Jeg har endnu ikke oplevet noget tidspunkt, hvor en refaktorering af selv en mindre stump af koden ikke er gået galt og er endt i et projekt der ikke ville kompilere, for alle andre, som efterfølgende forsøger at bruge rettelserne.

Og fordi det er så meget forskelligt fra alle andre VCS’er så er der åbenbart ikke rigtigt nogen der kan finde ud af det heller, eftersom tingene selvfølgeligt ikke har navne som stemmer overens med alle andre former for vcs’er. Det resulterer i at nogle filer bliver checket ind mens andre ikke gør. Som eksempel kan jeg jo tage .csproj som er filer der styrer enkelte projekter i en visual studio solution. Åbenbart er der nogen der ikke checker rettelserne i den fil ind, hvis de f.eks. sletter en fil. Og hvorfor skal man have ting checket ud hele weeken den? Kan man ikke have lavet ens ændringer og lagt dem op? Det giver bare konflikter på så mange niveauer.

Der er ingen mulighed for at eksludere filer såsom binaries (.dll’er eller .pdb’er), som jo ikke behøver versionskontrol eftersom de genereres hver gang man bygger projektet. At man har disse filer i ens “pending check ins” gør at folk der arbejder med systemet bliver mistroiske over hvilke filer de skal checke ind.

Og dertil kommer at klient programmet fylder 212 mb (eller noget i den stil). sammenligner man det med Tortoisesvn (8,9 mb installer) så fylder det 23,5 gang så meget.

Hvis du ikke er blevet udsat for Source Safe, så vil jeg på det kraftigste fraråde dig at ønske det. Det giver ikke andet end problemer langt hen ad vejen.

Den er ikke så satans avanceret: Det er bare en lille menu til – fx. – brugersider. Så som sådan er det ikke det vilde. Næh, det vilde ligger i at jeg endeligt, grundlæggende har forstået (og haft tid til at forstå) hvordan hele det her ASP.NET-cirkus fungerer.

Jeg er stadigt ikke vildt begejstret for det. Men det er heldigvis heller ikke det jeg får mine penge for at være.

Nå, men se den fine menu i aktion her:

På Skum kan brugerne – som så mange andre steder – sende private beskeder til hinanden. Disse ligger i tabellen “tblMessage”. Vel at mærke kun de ulæste af slagsen, for læste beskeder flyttes – på snedigste vis – til tabellen “tblMessageRead”. Normalt ville man nok have et felt i tabellen der angav om beskeden var læst eller ej, men i Sverige giver det åbenbart mere mening at fordele det på 2 tabeller.

I “tblMessage” og dens søstertabel er vi faldet over et spøjst felt. Det hedder “blnDoNotShowAsNotInList”, og værdien af dette felt er altid False. Er der mon nogen der kan gætte hvad dette felt er til?

Løsningen skal åbenbart findes i hvordan PNG formattet virker – hele PNGen skal være genereret før den kan skrives til en stream.

Til at sikre dette kan man skrive PNG’en til en MemoryStream, og derefter skrive den MemoryStream til Response.OutputStream.

AsyncButtonResult async = result as AsyncButtonResult;
using (MemoryStream ms = new MemoryStream())
{
     async.img.Save(ms, ImageFormat.Png);
     ms.WriteTo(async.context.Response.OutputStream);
}

Kode eksemplet ovenover er fra en IHttpAsyncHandler  der genererer knapper der skal bruges på SKUMs nye community.