15 svar · 524 visningar · startad av Dino
Undrar om man överhuvudtaget skall använda scripttaggarna eller köra den koden i code-behind och endast ha <html>...</html> i .aspx filen. Har fler frågor om strukturen, men tar det senare.
<script runat="server">
Sub Page_Load(sender As Object, e As EventArgs)
...
End Sub
</script>
<html>
<head>
<title>Untitled Document</title>
</head>
<body>
<asp:label id="lbLabel" runat="server"></asp:label>
</body>
</html>
Ja, blanda inte... kör du code behind finns det definitivt inte någon anledning att ha kod i ditt aspx-dokument om det var det du menade. :)
Vad är egentligen meningen med code-behind filer? Kan man återvinna kod i dem? Ska de ersätta ett riktigt komponent-lager?
Precis vad jag menade NETwork, tack. :)
Finns väl massa fördelar Erik. Den största är väl kanske separering av kod och "layout".
Jo, att ha olika lager är bra. Men knappast något unikt. Och jag förstår inte varför det skulle vara bättre att ha affärslagret som en vanlig scriptfil istället för en kompilerad komponent. :)
Vissa saker i .NET gör med lite konfunderad. Som att språket försöker agera som ett klientspråk när det är ett serverspråk.
Erik Juhlin skrev:
Jo, att ha olika lager är bra. Men knappast något unikt. Och jag förstår inte varför det skulle vara bättre att ha affärslagret som en vanlig scriptfil istället för en kompilerad komponent. :)
Nej, det är inte något unikt men likväl trevligt. :) Att dela upp presentationslagret och affärslaget underlättar arbetet och det gör det betydligt mer strukturerat, inte minst om du har många utvecklare och designers men även om du knåpar allt själv hemma.
Även om du inte använder code behind så blandar du naturligtvis ändå aldrig kod och html i asp.net som tidigare - asp-loopar och en massa html-kod blandat i varandra kommer du aldrig att behöva se igen. De flesta som programmerat gammal ASP har förmodligen råkat ut för att sidorna snabbt blir en enda stor röra om man inte använder COM vilket inte är helt enkelt alla gånger. Med riktig objektorienterad programmering tillsammans med cb får du ett helt annat flyt när du programmerar, du kan bygga upp din applikation på ett helt annat sätt och enkelt dela kompnenter/klasser mellan olika applikationer.
Erik Juhlin skrev:
Vissa saker i .NET gör med lite konfunderad. Som att språket försöker agera som ett klientspråk när det är ett serverspråk.
Nejdå, det är ett serverspråk och försöker inte vara något annat. Däremot finns det asp.net-kontroller som genererar klientscript av olika slag (och du kan göra egna som genererar vad-du-nu-vill-generera).
Även om du inte använder code behind så blandar du naturligtvis ändå aldrig kod och html i asp.net som tidigare - asp-loopar och en massa html-kod blandat i varandra kommer du aldrig att behöva se igen. De flesta som programmerat gammal ASP har förmodligen råkat ut för att sidorna snabbt blir en enda stor röra om man inte använder COM vilket inte är helt enkelt alla gånger. Med riktig objektorienterad programmering tillsammans med cb får du ett helt annat flyt när du programmerar, du kan bygga upp din applikation på ett helt annat sätt och enkelt dela kompnenter/klasser mellan olika applikationer.
Så om man använder riktiga komponenter så är code-behind onödigt..?
Nejdå, det är ett serverspråk och försöker inte vara något annat. Däremot finns det asp.net-kontroller som genererar klientscript av olika slag (och du kan göra egna som genererar vad-du-nu-vill-generera).
Jo, men den försöker lite låtsas som att det är den själv som är ett klientspråk när den egentligen bara spottar ut JavaScript. Klientspråket vill jag själv ha full kontroll på och inte en mellanhand på servern.
Använd inte sådana funktioner då? En enkel grej som jag gillar är RequiredFieldValidator - dvs du slipper att i koden kolla igenom om man fyllt alla delar i formuläret. Enkelt och bra!
Är bara intresserad av vad för något i .NET som kan vara användbart och vad som man kan hoppa över. :)
Hur fungerar RequiredFieldValidator?
Du väljer vilken kontroll tex textbox du ska koppla till den och meddelande som ska skrivas ut om man inte har fyllt i den, och en mängd andra inställningar. Sen så skapar den ett javascript som kollar kontrollen och lägger det på sidan, ungefär!
Okej, och så berättar man för den vad för värden som är tillåtna. T.ex. nummer, datum, organisationsnummer..?
Skulle ju i.o.f.s. inte vara så svårt att bygga en egen sån om man kände att man skulle ha stor nytta av det.
Orka bygga en egen?
Så finns det väl massa funktioner till dem också samt att det finns:
CompareValidator
RangeValidator
RegularExpressionValidator
CustomValidator
Låter vettigt. :)
Spottar dina kontroller ut en massa javascript är det för att DU vill att den ska göra det. Du HAR full kontroll på klientkoden, vill du inte autogenerera en massa html/javascript/vad-som-helst så använder använder du de kontroller där du själv bestämmer varenda bokstav som genereras. Är du ändå inte nöjd kan du göra egna kontroller eller kasta ut egen kod på andra sätt... Att du sedan kommer att inse att det är riktigt smidigt att låta asp.net-kontrollerna i många sammanhang generera kod åt dig är en annan sak... :)
Så om man använder riktiga komponenter så är code-behind onödigt..?
Nej, du missförstod mig. Tänk OO! Precis som du kan programmera direkt mot en kontroll kan du bygga klasser med funktioner som returnerar värden som i sin tur används i andra funktioner som sedan fyller en kontroll med data (eller gör nåt helt annat som inte har något med asp.net att göra överhuvudtaget). Du kompilerar din kod till assemblys (motsvarande COM) med den skillnaden att du ALLTID gör så och att det är mycket lättare.
Med andra ord, man kan väl säga att code behind (eller .net äverlag) handlar om komponentprogrammering. Rätta mig om jag har fel...
