Arbejder du med at lave udvidelser til Umbraco v7 Backoffice, er du sikkert stødt ind i notificationsService. Den bruges til at give brugeren besked via nogle bjælker i bunden af siden, farvekodet alt efter hvilken besked du ønsker at give brugeren.

Jeg stødte ind i en opførsel, som jeg ikke rigtig kunne gennemskue, nemlig at når jeg kaldte mit API, som returnerede en 404, så dukkede der en rød bjælke op med en besked vedr. denne 404. 

Jeg havde ikke selv kaldt genereret denne besked, så min umiddelbare tanke var: "Hvordan slipper jeg af med den!?".

Det viser sig, at der i servicekomponenten er indbygget nogle standardbeskeder, som vises i enkelte udvalgte tilfælde, når der er lavet et API-kald, som returnerer 401-404. Det er sikkert fint, men jo ikke altid hensigtsmæssigt at få besked om.

Heldigvis kan man undertrykke disse beskeder ved at indsætte en header i kaldet, så disse ikke vises. Headeren hedder

x-umb-ignore-error

og skal indsættes således

function doSomethingWithData(data) {
    var config = { headers: {
        "x-umb-ignore-error": "ignore"
    }};
    return $http.post("...url...", data, config);
}

Samme metode gælder for f.eks. get-requests.

Alternativt kan man jo lade være med at returnere 401-404 i sit API, men det kan være man ikke altid har kontrol over API'et og derfor har brug for at styre, hvordan det bliver håndteret på klienten.

Nogle gange har man brug for at rotere indhold for at få en speciel effekt. Dette kan med CSS3 gøres ret let, hvis ellers browseren fatter CSS3.

Her rotetes et element 45 grader med uret:

.label {
    -webkit-transform: rotate(45deg);
    -moz-transform: rotate(45deg);
    -ms-transform: rotate(45deg);
    -o-transform: rotate(45deg);
    filter: progid:DXImageTransform.Microsoft
           .Matrix(m11=0.71,m12=0.71,m21=0.71,m22=0.71);
}

NB: linjeskiftet er for at undgå koden flyder over i siden, det linjeskift skal fjernes, hvis du klipper koden ud og bruger i dit eget stylesheet.

Bemærk filter-reglen, som retter sig mod IE i tidligere versioner. Her er beregningen som følger:

m11 = sin (45 * pi / 180)
m12 = cos (45 * pi / 180)
m21 = cos (45 * pi / 180)
m22 = sin (45 * pi / 180)

Arbejder du med kode til en Umbraco installation, som anvender Entity Framework 6 og Code First Migrations, kan det være du kommer i samme situation som mig, hvor Migrations ikke bliver kørt ifm. Web Deploy.

Jeg kunne ikke umiddelbart finde frem til årsagen, men jeg fandt en vej udenom problemet. Det er ikke en perfekt løsning, da den involverer noget manuelt arbejde, men nogle vil påstå, at det er en bedre metode i et produktionssetup, hvor du gerne vil have 100% kontrol over, hvad der sker med din database og hvornår det sker.

Til formålet anvender jeg Package Manager Console, hvor jeg skyder en update-database af mod min produktionsdatabase server og får et script genereret, som jeg så kan fyre af i MSSMS (mod min produktionsdatabase server).

Inden jeg kunne gøre dette, løb jeg dog ind i et par problemer. Det første var at DbProviderFactory skal være til stede i min web.config, for ellers ville update-database kommandoen ikke køre. Dette betyder helt konkret, at flg. skal tilføjes i system.web-sektionen af web.config:

  <system.data>
    <DbProviderFactories>
      <remove invariant="System.Data.SqlClient" />
      <add name="SqlClient Data Provider"
           invariant="System.Data.SqlClient"
           description=".Net Framework Data Provider for SqlServer"
           type="System.Data.SqlClient.SqlClientFactory, System.Data, 
                 Version=2.0.0.0, Culture=neutral, 
                 PublicKeyToken=b77a5c561934e089" />
    </DbProviderFactories>
  </system.data>

Når dette er på plads kan update-kommandoen udføres med flg. format:

update-database -script -projectname <projektet med entity datacontext>
     -connectionstring <connectionstring til produktionsdatabasen>

NB: Det er naturligvis en forudsætning, at du har adgang til din produktionsdatabase server fra din udviklermaskine (hvilket nok i større setups ikke er sandsynligt), da update-database skal læse migrationshistorikken fra databasen, for at vide, hvilke migrationer der skal udføres.

Efter denne kommando er udført, får du, i Visual Studio, et vindue med SQL-koden, som modsvarer migrationen. Denne kode kan så udføres i MSSMS mod produktionsdatabasen og migrationen er dermed gennemført.

Hvis du føler dig rigtig modig, kan du undlade -script parameteren og få udført opdateringen direkte fra PMC'en. Det sparer dig for at skulle udføre scriptet i MSSMS efter det er genereret i PMC, men det fjerner også muligheden for, at kontrollere, hvad migrationsscriptet rent faktisk har tænkt sig, at gøre ved din produktionsdatabase...

Jeg har i min anvendelse af Entity Framework haft behov for at placere mine migrationsfiler et andet sted end de, som standard, bliver placeret.

Dette kan gøres i constructoren af DbMigrationsConfiguration (Configurations.cs). Denne fil bliver genereret, når man slår migrations til (Enable-Migrations i PMC).

Egenskaben hedder MigrationsDirectory og skal sættes til en relativ sti ift. den DLL, som migrations ligger i. Følgende er et eksempel på dette:

internal sealed class Configuration 
    : DbMigrationsConfiguration<ShopContext>
{
    public Configuration()
    {
        MigrationsDirectory = "Ef\\Migrations";
        MigrationsNamespace = "Shop.Repositories.Ef.Migrations";
    }
}

I ovenstående har jeg dels, med MigrationsDirectory, sat mappen migrationfiler skrives til, dels, med MigrationsNamespace, det namespace, som nye migrations anvender. Det kan være relevant, at namespace følger placeringen af de fysiske filer og det har man, som her demonstreret, mulighed for også at styre.

Jeg sidder og arbejder med CodeFirst i Entity Framework 6 (EF6) og det er sådan set også helt fint. Jeg dog hidtil haft en lille udfordring med, at beregnede egenskaber ikke rigtig kom med ned i databasen og jeg dermed skulle have indlæst objektet i hukommelsen for at kunne arbejde med disse egenskaber.

Det er i mere komplekse tilfælde nok også det rigtige at gøre, men for nogle typer data, kan det være rigtig praktisk, at få den beregnede værdi gemt i databasen, så der kan foretages forespørgsler på disse egenskaber direkte i databasen, uden man skal have dem ind i hukommelsen.

Hidtil har et objekt haft nogenlunde flg. struktur:

public class Kamp
{
    public List<Periode> Perioder { get; set; }

    public DateTime Startdato { get; set; }
    public DateTime Slutdato
    {
        get
        {
            return 
                Startdato.AddTicks(
                    Perioder.Sum(p => p.Loebetid.Ticks));
        }
    }
}

public class Periode
{
    public TimeSpan Loebetid { get; set; }
}

Her har jeg en Kamp som kan have flere perioder. Hver periode har en løbetid på et givet tidsinterval. Slutdatoen bliver derfor summen af løbetider for alle perioder. Hvis jeg ændrer løbetiden på en periode (via objektet af typen Kamp), vil slutdatoen ændre sig automatisk, hvilket jo er rigtig rart!

Nu vil jeg imidlertid gerne finde alle de kampe som er igang, dvs. den aktuelle dato ligger mellem startdatoen og slutdatoen. For at kunne opfylde dette krav er jeg med den aktuelle struktur, nød til at indlæse alle kampe, hvor den aktuelle dato er større end eller lig med startdatoen og derefter gennemløbe alle kampe (i hukommelsen) for at se, om slutdatoen er overskredet. Det er måske ikke det store problem, hvis man har 100 kampe, men hvis man har en mio eller flere, har jeg på fornemmelsen, at det bliver en ret tung omgang. Desuden vil det med tiden blive et større og større problem, da flere og flere kampes startdato vil ligge i fortiden og dermed blive indlæst i denne forspørgsel. Der må altså tænkes lidt alternativt...

En løsningsmulighed

Gem slutdatoen uden at gøre den til simpel egenskab med get og set. Dette gøres ved at lade slutdatoen bibeholde sin getter og så tilføje en tom setter. På den måde vil EF generere egenskaben i databasen og gemme den værdi som getteren genererer, når objektet gemmes.

Når objektet indlæses igen, vil værdien bare blive skrottet, da slutdatoen jo beregnes på grundlag af de indlæste perioder (husk at "Include" Perioder i din query!).

Kamp kommer til at se således ud i stedet:

public class Kamp
{
    public List<Periode> Perioder { get; set; }

    public DateTime Startdato { get; set; }
    public DateTime Slutdato
    {
        get
        {
            return 
                Startdato.AddTicks(
                    Perioder.Sum(p => p.Loebetid.Ticks));
        }
        set {}
    }
}

Kører du nu Add-Migration fra PMC (Package Manager Console) i VS, vil der blive genereret et felt til slutdato i Kamp-tabellen. Dette felt kan nu anvendes til at foretage forespørgsler på, for den gemte værdi er den beregnede slutdato på det tidspunkt, hvor Kampen sidst blev gemt. Det kunne f.eks. se således ud i LINQ to EF:

using(var ctx = new DataContext())
{
    var igangvaerendeKampe =
        ctx.Kampe
           .Include(k => k.Perioder)
           .Where(k => k.Startdato <= DateTime.Now
                       && k.Slutdato >= DateTime.Now)
           .ToList();

     return igangvaerendeKampe;
}

Med ovenstående har du filtreret kampene i databasen og nok gjort noget godt for dit systems performance og skalerbarhed i fremtiden...

Konklusion

Alt efter ens krav og behov til funktionalitet, kan det godt betale sig, at gå lidt på kompromis med de strikse normaliseringskrave der ellers bør herske ifm. databasedesign. I dette tilfælde vil jeg gætte på, at der på sigt er vundet en del performance og dermed et problem afværget - inden det opstod.

Jeg står overfor at skulle arbejde med geolokation på en hjemmeside, nærmere bestemt finde ud af hvormange lokationer der findes indenfor en radius af et givet punkt.

Det har jeg ikke arbejdet med før, men jeg fornemmer det er lettere end det har været, da der dels er nogle gode resurser omkring emner, dels er nogle API'er man kan anvende til udføre noget af arbejdet.

Opgaven er såmænd ret enkel, nemlig "find alle, i en database registrerede, lokationer, som er indenfor en radius af X km fra min aktuelle lokation".

Det involverer umiddelbart flg.

1. at jeg kender eller kan finde den aktuelle lokation
2. at jeg kender lokationen på alle de ting der skal findes
3. at jeg, på en nem måde, kan foretage et opslag på disse oplysninger

Find aktuelle brugers lokation

Det første kan jeg i nogen udstrækning bruge browserens faciliteter til. Nyere browsere har indbygget en eller anden grad af lokationsbestemmelse og den tager jeg udgangspunkt i.

Det kunne f.eks. se således ud:

window.navigator.geolocation.getCurrentPosition(function(pos) { 
    var lat = pos.coords.latitude;
    var lon = pos.coords.longitude;
})

Find lokation på adresser

Det andet kan jeg (nok) bruge Google's Geocoding API til. Det skal bruges på den måde, at jeg vha. en adresse omsætter denne til et sæt længde- og breddegrader. Disse gemmer jeg  sammen med det der skal findes.

Dette API kræver, at jeg opretter en API-nøgle før jeg kan foretage opslag (se instruktionerne på siden til Geocoding API'et), men når det så er gjort, kan jeg spørge på en adresse med et kald til flg. url:

var url = "https://maps.googleapis.com/maps/api/geocode/json?"
    + "address=Hovedgaden+12,8000+Århus&key=[API-nøglem]";

Udtræk lokationer der matcher området

Det tredje kan jeg, med udgangspunkt i jeg anvender SQL Server, gøre ved et fancy opslag, hvor jeg får returneret et antal rækker, som ligger indenfor et givet cirkulært område. Hvordan der foretages en sortering efter nærhed, har jeg ikke gennemskuet, men med noget dataanalyse kan man måske nå frem til et approximeret sorteret resultat - måske endda et reelt sorteret resultat. Hvem ved...? Mit umiddelbare behov er dog ikke, at resultatet er sorteret efter nærhed, så det spekulerer jeg ikke så meget i lige nu.

Anyway! For at udtrække de lokationer, som ligger indenfor en given radius (på grundlag af længde- og breddegrader), kan jeg så bruge denne SQL-konstruktion:

declare 
   @latStartingPoint float, 
   @lngStartingPoint float, 
   @distKmFromStartingPoint float;

set @latStartingPoint = 55.0
set @lngStartingPoint = 9.0
set @distKmFromStartingPoint = 13.0

select * 
from testLocation 
where ( 
   6371 * 
   acos( 
       cos( radians(@latStartingPoint) ) * 
       cos( radians( lat ) ) * 
       cos( radians( lng ) - radians(@lngStartingPoint) ) + 
       sin( radians(@latStartingPoint) ) * 
       sin( radians( lat ) ) 
   )) < @distKmFromStartingPoint

Jeg har erklæret 3 variable i SQL'en ovenfor, hvor

• @latFromStartingPoint er breddegraden for udgangspunktet
• @lngFromStartingPoint er længdegraden for udgangspunkt
• @distKmFromStartingPoint er antal km fra center der ønskes resultater fra
• Det magiske tal 6371, er jordens radius

Konklusion

Som det kan ses, er det i teorien, rimeligt ligetil... så må vi se om det også er i praksis :-)

I disse tider med større og større fokus på SEO-venlighed, kan det være rart, hvis man kan basere sine url'er på data fra eksempelvis sin database.

Man kunne have en produktdatabase, hvor produktet har en unik (url-venlig) streng, som kan anvendes til at finde produktet. I et setup uden nogen specielle regler, kan dette være en udfordring at få gjort stømlinet. Med en routedefinition som denne:

routes.MapRoute(
    name: "Default",
    url: "{controller}/{action}/{id}",
    defaults: new { 
        controller = "Home", 
        action = "Index", 
        id = UrlParameter.Optional 
    }
);

hvor produkt-controlleren hedder ProduktController, action-metoden til at vise et produkt hedder Vis og produktets urlnavn ligger i id-parameteren, kunne url'en til et produkt se således ud:

/produkt/vis/stor-tallerken-med-sort-kant

Det kan være fint nok ift. SEO, men det ville jo være rart, hvis man kunne slippe for de lidt overflødige controller- og action-tekster, så url'en kom til at se således ud i stedet:

/stor-tallerken-med-sort-kant

Dette kan opnåes med en RouteConstraint og en wildcard-urlparameter. Route-mapping kunne derfor se således ud:

routes.MapRoute(
    name: "Default",
    url: "{id}",
    defaults: new { controller = "Produkt", action = "Vis" },
    constraints: new { id = new ProduktRouteConstraint() }
);

Nu kaldes ProduktRouteConstraint's Match-metode hver gang routing kaldes. Denne Match-metode skal så håndtere et opslag i produktdatabasen for at se, om den angivne id refererer til et eksisterende produkt. Match-metoden returnerer en bool, der indikerer om den aktuelle route skal anvendes eller ej, dvs. om produktet findes i dette tilfælde. En implementering kunne se således ud:

public class ProduktRouteConstraint : IRouteConstraint
{
    public bool Match(
            HttpContextBase httpContext,
            Route route,
            string parameterName,
            RouteValueDictionary values,
            RouteDirection routeDirection
        )
    {
        var svc = new ProduktService();
        var id = values["id"].ToString();
        return svc.FindesProduktMedUrlnavn(id);
    }
}

Match-metoden fyrer op under en produktservice-klasse, der, via metoden FindesProduktMedUrlnavn, kan svare på, om produktet med det angivne navn (fra url'en) findes eller ej.

Hvis url'en ikke er et match, fortsætter routing-systemet videre til næste regel (som det altid har gjort). Derfor skal denne regel helst ikke være den sidste regel i rækken af routing-regler. 

En ting man skal være opmærksom på med denne metode er, at routing-systemet aktiveres hver gang der foretages et request til sitet. Derfor skal routingconstraints helst være så optimerede som muligt, da sitet ellers vil virke langsomt. Det vil med andre ord være en god idé, at overveje caching af grundlaget for disse specielle routingregler, i dette eksempel produktets urlnavne.

Jeg sidder lige og arbejder med en webshop, som handler med fysiske varer og i den forbindelse har der været behov for at finde ud af, hvilke rettigheder og pligter kunden hhv. butikken har.

I den forbindelse er følgende links fundet relevante og hjælpsomme i forståelsen af disse emner:

Kundens fortrydelsesret

Tilfælde hvor der ikke er fortrydelsesret

Forretningens oplysningspligt før salg

Generelt omkring net-handel

Alle ovenstående links kommer fra samme side og er en del af samme "kompendie", men udvalgte links er medtaget her, da mit fokus har være på handelsbetingelser og fortrydelsesret.

Jeg sad idag og boksede med et problem i Visual Studio, hvor jeg ikke kunne få intellisence til at fungere. Dette til trods for, at jeg godt kunne complie projektet og køre det i IIS Express.

Der var røde bølgestreger under et namespace i using-sektionen og en type kunne ikke findes. Da projektet kunne compile, tænkte jeg det måtte have noget med udviklingsmiljøet at gøre.

Jeg havde lavet en cleanup og forsøgt at køre "rebuild" på hele min solution, men lige lidt hjalp det. 

Jeg søgte på problemet og fandt dette link: https://stackoverflow.com/questions/21471887/visual-studio-2013-intellisense-stops-working-for-asp-net-mvc5-controllers/23983883#23983883

Løsningen var, i mit tilfælde, helt enkelt, at lukke VS 2013 og slette filen <projektnavnet>.v12.suo og starte VS 2013 op igen.

Det sker at man falder over en opgave, som kan løses ved at importere data fra en CSV-fil (kommaseparerede data) og i den forbindelse kunne man jo strikke sin egen parser sammen.

CSV-formatet er dog lidt mere tricky end man lige umiddelbart skulle forestille sig, så derfor bør man nok kigge på markedet, om der ikke findes en anden som allerede har strikket noget sammen (og som er testet grundigt igennem af mange andre).

Det var netop hvad jeg gjorde. Jeg fandt frem til denne på CodeProject: http://www.codeproject.com/Articles/9258/A-Fast-CSV-Reader

Den ser ud til at fungere fint og kan installeres i et .NET-projekt vha. NuGet, så det bliver vist ikke ret meget lettere at komme igang. Oveni det er den ret simpel at anvende.