Website vs Webapplication

Som udgangspunkt er vi begyndt for et stykke tid siden at bygge vores sites som det der i Visual Studio hedder Web Application Projects (eller bare WAP). Denne projekttype blev udgivet af Microsoft, da det viste sig at der var kompatibilitets problemer omkring bl.a SourceSafe når man arbejder med websites i VS 2005.

Det viser sig imidlertid at den nye projekttype har sine egne mangler, idet Profile API'et ikke fungerer som det skal idet proxyklassen der repræsenrerer profile-objektet ikke genereres. Ligeledes er der problemer omkring brugen af BuildProvidere der ellers er et af de hotte emner omkring .NET 2.0.

Så egentlig står man lidt med valget imellem pest eller kolera, idet man må leve med en eller anden slags småproblemer lige meget hvad man vælger. Jeg har ladet mig fortælle at det nye SourceSafe heller ikke altid kører helt smertefrit, men min forhåbning lige pt er at det kan løses. På den måde vil det forhåbentlig være muligt at bruge website projects, også i SourceSafe, og derved vil problemet være løst.

Model View Controller pattern

Når man har for meget tid ender det gerne med at man får en eller anden halvskør ide til noget der skal prøves af - livet som udvikler i en nøddeskal.

Jeg fik derfor, efter at have kigget lidt nærmere i Microsofts anbefalinger og nærstuderet Enterprise Library, lyst til at prøve at lave mit eget model view controller pattern. Idéen er at kunne skille UI fra modellen, således at man kan lave en applikation hvor det uden videre er muligt at udskifte f.eks en webfront med en windows form.

At lave backend-delen er egentlig meget let, idet man kan lade ens interface være en "controller" der stiller et event til rådighed. Eventet giver derved besked til frontenden om tilstandsskift der bør (eller bare kan) medføre ændringer af det der vises for brugeren.

For at få det implementeret på en pæn måde som webapplikation skulle jeg derved finde en måde at koble en tilstand sammen med bestemte websider. Det jeg fandt ud af at man passende (i .NET ihvertfald) kunne gøre er at lade hver side i ens sitemap indeholde en attribut der beskriver en tilstand. Derved kan man lave en generel funktion som kan arves af alle ens websider. Funktionen skal så bare lytte på eventet og skifte til den tilsvarende tilstand når eventet affyres.

Hvad passede mig endnu bedre var at denne idé var en oplagt chance for at arbejde lidt med Visual Basic, idet jeg står og skal til at skifte over fra C#.

Alt i alt en sjov lille øvelse - der så forhåbentlig ender med at blive implementeret i en applikation inden længe.

Hvad sendes og modtages med ASP.NET Ajax?

Klokken er 04:55 og jeg kan ikke sove mere. Et af livets vigtigste spørgsmål trænger sig på: Hvad sendes og modtages med ASP.NET Ajax? Lidt nørdet, ja - men her er svaret.

Altså - hvis man har et UpdatePanel på sin ASP.NET Ajax-enablede side, som indeholder rigtig mange elementer og man kun ønsker at opdatere en enkelt værdi, hvor meget sendes til serveren og hvor meget returnerer serveren til klienten.

For at finde svaret, indsætter jeg to TextBox-elementer i mit UpdatePanel, hvor den ene sættes til AutoPostBack=true og i den tilhørende event definerer jeg, at TextBox2.Text = TextBox1.Text og intet andet. Med andre ord, jeg overfører værdien fra én TextBox til en anden. Derudover indsætter jeg 5 andre TextBox-elementer i mit UpdatePanel, med hvilke der ikke skal ske noget.

Nu åbner jeg Fiddler, som er et fremragende værktøj til at spore hvad der sendes og modtages af min computer. Herefter indtaster jeg hej i TextBox1 og forlader feltet - næsten med det samme dukker teksten op i TextBox2. Fantastisk.

Men hvilke data blev faktisk overført? Her er svaret:

Klienten sender samtlige formular-værdier når et UpdatePanel skal opdateres.

Serveren returnerer hele det HTML-indhold som UpdatePanel skal indeholde. Også de uændrede elementer.

Hvis du har 100 elementer i et UpdatePanel bliver disse transporteret fra din webserver og ned til brugerens computer, hver gang noget som helst skal opdateres.

Spørgsmålet er besvaret og jeg kan hoppe i seng igen - klokken er nu 05:28.

Menu i ASP.NET Ajax

Microsofts 'nye' framework, ASP.NET Ajax er kommet! Det er ikke rigtig nyt, for det har eksisteret i årevis under kodenavnet Atlas. Men nu er det udgivet for alvor og jeg har benyttet lejligheden til at prøve det.

Det er utroligt nemt og lige til at gå til. Der er nogle fremragende introduktionsvideoer på ajax.asp.net. Der er vist 20 stykker, men jeg har kun set den første, som varer ca. 5 minutter - og det er faktisk rigeligt til at kunne stort set alt.

Jeg indsætter et UpdatePanel. Deri indsætter jeg en Menu, et MultiView indeholdende tre View's, med hvert sit GridView som indeholder nogle testdata. Resultatet er et lille typisk eksempel på en ASP.NET-applikation - nu med Ajax.

MEN DET VIRKER IKKE! Man kan ikke benytte en Menu-kontrol i et UpdatePanel. Der er simpelt hen fejl i ASP.NET Ajax. Heldigvis er der et trick som jeg har set her:

Indsæt følgende i dit UpdatePanel og lad ControlID være ID på din Menu-kontrol.

<Triggers>
    <asp:AsyncPostBackTrigger
    ControlID="menu"
    EventName="MenuItemClick"
    />
</Triggers>

Så virker det igen - og det er samtidig en slags Wildcard som du også kan benytte næste gang der er noget som driller i dit UpdatePanel.

C# til VB - lidt hjælp til konvertitter

Da jeg skal til at arbejde med VB har jeg brugt lidt tid på at bore i forskellene imellem C# og VB.

Det har vist sig at der er en række interessante forskelle, så jeg har derfor valgt at skrive denne artikel således at andre der skal til at skifte sprog eller eventuelt bare skal vælge sprog i det hele taget kan lade sig inspirere af mine opdagelser.

Jeg forgiver på ingen måde at dette er et komplet opslagsværk over forskelle (da der allerede findes den slags lister), da det udelukkende er de ting
jeg personligt mener man skal vide for at komme igang krydret med nogle af de ting jeg finder interessante.

De største forskelle imellem de to sprog ligger i syntaksen, men der er også enkelte features som er specifikke
for de enkelte sprog - og så er der forskel på hvad visual studio har af funktionalitet til at støtte op om sprogene.

Struktur og syntaks forskelle
Det første man får øje på når man sammeligner sprogene er hvordan scope angives,og hvordan man afslutter en linie.

C# benytter tuborgklammer til at angive scope, hvorimod der i VB er et reserveret ord (eller to om man vil) der angiver at en given konstruktion slutter.

Afslutning af en linie i C# sker ved at man skriver et semikolon, og i VB skifter man bare linie så det er end of line karakteren der egentlig afslutter linien.

Gode eksempler til at illustrere dette kan være at se på en enkel forgrening eller løkke konstruktion.

C#
if (myVar == 1 && yourVar == 2)
{
//Do stuff
}

VB
If (myVar = 1 AndAlso yourVar = 2) Then
'Do stuff
End If

Eksemplet illustrerer forskellen i angivelse af scope med henholdsvis klammer og et End nøgleord.

Derudover kan man se at operatorer også er forskellige idet C# bruger en mere matematisk notationsform, hvor VB nærmere ligner engelsk.

C#
for (int index = 0; index<collection.Count; index++)
{
//Do stuff
}

VB
For index As Integer = 0 To 8 Step 2
'Do stuff
Next index

Forløkken adskiller sig mere rent rent syntaktisk, da det igen er tydeligt at notationsformen i C# er mere matematisk hvor VB søger at ligne engelsk. En detalje der er værd at bemærke er at incrementering og decrementering i C# kan gøres ved hjælp af shorthand notation som ++ og -- hvilket ikke findes i VB.

Andre syntaktiske forskelle er instantiering af objekter, brug af indexere og generics.
Disse ting er hurtigst og bedst illustreret ved et lille eksempel.

C#
string navn = "";
myHashTable["Hans"]
List myList;

VB
Dim navn AS string = ""
myHashTable("Hans")
myList as List(Of Integer)

Parameter passing er endnu et sted hvor sprogene adskiller sig markant idet C# passer simple typer by value og komplekse typer by reference. I VB er alt derimod passed by reference med mindre man angiver det med nøgleordet ByVal.

Og en sidste lille detalje til det her afsnit er conditional statements hvor man i C# laver en ?: konstruktion findes der i VB en IF funktion.

C#
int i = obj==null?0:(int)obj;

VB
Dim i As Integer = IF(obj IS Nothing, 0, DirectCast(obj, Integer))


Klasse og metode signaturer
Omkring signaturer er den mest markante forskel ved angivelse af returntypes,
men der er også enkelte modifiers der hedder noget forskelligt.
I C# angiver man hvad de returnerer og void hvis de ikke returnerer noget.
I VB derimod angiver man en Sub hvis der ikke returneres noget og ellers angives en Function.

Metode der ikke returnerer noget:

C#
void DoStuff()
{
//Do stuff
}

VB
Sub()
'Do stuff
End Sub

Metode der returnerer en string:

C#
string DoStuff()
{
return "Hello world";
}

VB
Function() As String
return "Hello world"
End Function

Derudover består forskellen i navngivningen, idet ting der kun er synlige indenfor et assembly angives med henholdsvis internal og Friend, metoder der ikke kræver en instans af et objekt hedder static og Shared og man gemmer metoder med henholdsvis new og Shadow.

Type håndtering
En markant underliggende forskel på de to sprog ligger i håndteringen af typer.
C# er meget stringent og kræver præcis angivelse af casts, hvorimod VB automatisk håndterer simpel typekonvertering.

Syntaktisk foregår eksplicit casting heller ikke helt på samme måde som det fremgår af følgende eksempel.

C#
string s = (string)hash("Hans");

VB
Dim s As String = DirectCast(hash("Hans"), String)

Alternativt kan man i VB også bruge funktionerne CType der ligeledes kan bruges til casting eller en række specifikke funktioner som CInt, CDbl osv.

Sprogspecifikke features
C# kan en større ting som ikke er muligt i VB og det er at afvikle unsafe kode. Derudover findes stiller Visual Studio nogle flere værktøjer til rådighed i forbindelse med udvikling. Der findes er menupunkt i VS som hjælper med refactoring af kode, og codesnippet delen er bygget samme med autocompletion i større grad end den er til VB.

VB tilgengæld har nogle sproglige ting der er med til at gøre koden mere læsevenlig og så er flere funktioner tilgængelige enten direkte eller via namespacet my. Jeg vil ikke gå nærmere ind i at liste disse funktioner men kan nævnet at f.eks matematiske udtryk kan bruges direkte som f.eks Rnd istedet for Math.Round.

With nøgleordet giver mulighed for at sætte flere attributter på samme objekt uden at gentage handle navnet på følgende måde.

C#
kunde.Navn = "Per Petersen";
kunde.Adresse = "Odensevej 321";
kunde.Telefon = "12345678";

VB
With kunde
.Navn = "Per Petersen"
.Adresse = "Odensevej 321"
.Telefon = "12345678"
End With


Event håndtering
Som en afsluttende detalje vil jeg nævne eventhåndtering, som kan gøres på samme måde - hvis man ser bort fra syntaks. VB giver dog mulighed for at man kan erklære at en metode skal håndtere et bestemt event frem for at man skal skrive det i kode. Først lad os se et basalt eksempel på eventhåndtering.

C#
public delegate void AlarmEventHandler(object sender, AlarmEventArgs e);
public event AlarmEventHandler Alarm;
...
if (chocolateInStock <>
VB
Public Delegate Sub AlarmEventHandler(sender As Object, e As AlarmEventArgs)
Public Event Alarm As AlarmEventHandler
...
If (chocolateInStock <>

Som det fremgår virker tilføjelsen af en event handler meget ens på de to sprog. VB tillader imidlertid at man gør følgende som ikke er muligt i C#.

Private WithEvents chokoManager As ChokoladeManager
Sub Handler1(e As AlarmEventArgs) Handles chokoManager.Alarm
'*** handler method implementation
End Sub

Alternativet som ses her er dog muligt i begge sprog.

C#
clock.Alarm += new AlarmEventHandler(OnAlarmRang);

VB
AddHandler clock.Alarm, AddressOf OnAlarmRang


Konklusion
Bevæbnet til tænderne med denne artikel og med google klar i baghånden skulle det være en form sag at komme igang med at skifte imellem C# og VB. Det håber jeg ihvertfald da jeg snart selv skal til og igang med det for alvor.

Jeg vil lade helt værd med at gå ind i en diskussion om hvilket sprog der er "bedst" for det vil altid være enormt subjektivt, og i sidste ende er det også irrelevant. Det interessante er bare at se hvad de to sprog tilbyder og så glæder jeg mig personligt til at stå i en situation hvor jeg kan hoppe imellem de to sprog uden nærmere omtanke.

Upload med Progress Bar

Alle der har prøvet at lave upload af fil i ASP.NET har opdaget at det er umuligt at lave en Progress Bar. Problemet er, at man i sin kode først bliver spurgt om noget når filen er helt uploadet. Derfor kan man ikke sende signaler til brugeren undervejs om hvor meget af filen der er uploadet.

En Google-søgning i emnet, giver 2 forskellige typer resultater:

- Dyre komponenter
- Et tip om at man skal bruge et HttpModule.

Det er korrekt at man skal bruge et HttpModule. Sagen er den, at der er et HttpModule indbygget i .NET som ikke giver dig adgang til oplysninger om hvor meget af en fil der er blevet uploadet. Derfor skal der benyttes et andet HttpModule end det indbyggede. Et som giver adgang til disse oplysninger.

Svaret er ... Brettle's NeatUpload. Det er gratis, men send ham en donation hvis du bruger det. Det har han fortjent - det virker rigtig godt. Installationen foregår nogenlunde sådan:

1. Hent NeatUpload og læg filerne i en mappe i din web-applikation.
2. Indsæt dit og dat i Web.config.
3. Deklarer to NeatUpload-controls: InputFile og ProgressBar i din aspx. Tilgå førstnævnte i din CodeBehind for at få fat i filen.

Behøver det være sværere? Så let var det for mig da jeg udviklede UploadBAG. Man kan komme ud for lidt ekstra krumspring, afhængigt af hvad man er ved at lave. F.eks. hvis man skal uploade mere end én fil ad gangen. Men det hele er beskrevet i en udførlig manual.