En av de många fantastiska funktionerna i ramverk som Blazor och ASP.NET ( som den körs på) är möjligheten att servera dynamiskt innehåll oavsett vilken slutpunkt din applikation behöver. Om du vill skicka nedladdningar av genererade filer är det enkelt att göra med en liten konfiguration.
Varför servera dynamiska filer ?
I grund och botten har du två alternativ som webbserver: svara på en begäran med statiskt innehåll, som en HTML-sida eller JPG-fil, eller skapa ett anpassat svar som ska skickas till användaren. Blazor körs på ASP.NET, så den inbyggda HTTP-servern stöder ett brett utbud av alternativ och möjliggör stor flexibilitet.
Du kanske till exempel vill vara värd för en JSON-fil på/images/pathname. json. Det här behöver inte vara en bokstavlig fil på disken; servern kan tolka denna begäran och svara med alla typer av innehåll, inklusive något oväntat som en PNG-fil. Du kan svara på denna begäran genom att hämta några resultat från ett API, skapa ett svar och skicka tillbaka strängen till användaren.
Eller kanske vill du skapa den faktiska filen i farten. Det finns till exempel många grafikbibliotek som används för att rita anpassade bilder. Du kan använda en av dessa för att skapa en bild och svara på användarförfrågan med data, allt i minnet.
I det senare fallet kan det vara vettigt att cache-svaret genom att spara det på disk och svara med en riktig fil för det mesta. Detta kan vara användbart för resurskrävande filgenerationer som inte ändrar så ofta.
Ställa in det
Att servera filer som detta är inbyggt och ganska enkelt att göra. Du måste skapa en ny Razor-sida, vilket är vad Blazor kör på. Du kan göra detta genom att högerklicka i Visual Studio och välja Lägg till & gt; Razor Page.
Annons
Genom att göra detta skapas två filer som är länkade med varandra i hierarkin: Namn.cshtml, som hanterar HTML-sidan av saker och Namn.cshtml.cs, som hanterar modellen och den faktiska koden. Eftersom detta inte kommer att bli en verklig webbsida, bara en fil, kan du ignorera den första för det mesta.
Du måste dock ställa in attributet @page så att det matchar var du vill att den här filen ska vara värd. Du vill antagligen inkludera några jokertecken som du gör med parenteser.
I filen Name.cshtml.cs ser du någon faktisk kod som utökar PageModel. Huvudfunktionen här är OnGet (), som du förmodligen vill ändra till OnGetAsync () om du gör någon asynkron bearbetning.
Du har tre huvudalternativ från denna funktion. För det första är det att returnera en PhysicalFile, som bokstavligen läser en fil på disken med en sökväg och skickar den till användaren med en typ, eventuellt med ett separat nedladdningsnamn än den faktiska sökvägen.
Medan du förmodligen är här för att generera något dynamiskt kan det vara mycket användbart för cachning. Om du har din bearbetningsfunktion att spara resultatet i en fil kan du kontrollera om filen finns innan du bearbetar den igen, och om den gör det, returnerar du bara det cachade svaret. //www.cloudsavvyit.com/pagespeed_static/1.JiBnMqyl6S.gif “/>
Annons
Nästa alternativ är att returnera en virtuell fil med en byte-array. Det här är vad du vill använda för de flesta applikationer, eftersom det fungerar helt i minnet och borde vara mycket snabbt.
Beroende på vilken kodning du försöker använda, kanske du vill att konvertera en sträng till en byte-array med hjälp av klassen Kodningshjälp.
Kodning.UTF8.GetBytes (sträng);
Slutligen kan du returnera en innehållssträng direkt, vilket är vad du borde använd om du vill visa innehållet för användaren istället för att utlösa en nedladdning i deras webbläsare.
Det finns andra alternativ än dessa tre, men resten handlar om att svara med statuskoder, omdirigera , obehöriga svar och rendering av själva sidan.
Visar filer baserat på rutter & amp; Parametrar
Naturligtvis är inget av detta användbart om du inte kan svara på förfrågningar baserat på användarinmatning. De två inmatningsformerna finns båda i URL: en: routningsparametrar och URL-parametrar. Routningsparametrar är vad du angav med jokertecken på själva sidan och är den faktiska sökvägen till filen. URL-parametrar är valfria.
Att räkna ut det här kan vara lite ont, men lyckligtvis har du en felsökare vid din sida, så du kan ställa in en brytpunkt i OnGetAsync () och visa hela det lokala variabelträdet .
Annons
Du hittar under denna.PageContext.RouteData, det finns en RouteValueDictionary & lt; sträng, objekt & gt; som lagrar alla rutter. Observera att detta inkluderar själva sidvägen, så om du använde/Ladda ner/{param} som rutt kommer parametern att vara det andra alternativet.
Det bästa sättet att hämta parametrarna är att slå upp dem med nyckel:
På samma sätt är frågeparametrarna också tillgängliga , dock från ett annat objekt. Du måste komma åt HttpContext.Request.Query, som är en QueryValueDictionary som innehåller URL-parametrarna och fungerar på ungefär samma sätt som rutten.
Du kan då använda dessa parametrar för att utföra sökningar eller påverka logiken. Om du cachelagrar svar vill du dock se till att dina cacheförhållanden och uppslag påverkas av dessa parametrar, eller så kan du stöta på problem med oväntat cachningsbeteende.