Blazor Server ו-WebAssembly
הרינדור הוא בצד השרת בכל מקרה. ב-Server הקריאה היא ישירה; ב-WebAssembly אתה חושף את קריאת הפתיחה כנקודת קצה של API מינימלית ומעביר את הטוקן שהוחזר לווידג'ט. שניהם דורשים כמה שורות קוד בלבד.
Blazor
צופה מסמכים המתנהג בתוך Blazor
Blazor מספק לך מודל רכיבים ולולאת רינדור שאינה מתחשבת הרבה בקוד JavaScript של צד שלישי. Doconut עובד עם זה ולא נגדו: הרינדור מתבצע בצד השרת בתהליך שלך, והווידג'ט מותקן אל אלמנט פשוט שאתה שולט בו דרך מחזור החיים הרגיל של האינטרופ.
- 75
- סיומות קבצים, ללא ניתוח בצד הלקוח
- 2
- מודלי אירוח נתמכים
- 0
- מטען WASM לרינדור
הבעיה
למה הגישות הרגילות פוגעות ב-Blazor
הנתיב בצד הלקוח משמעותו שליחת מנוע רינדור לדפדפן. ב-Blazor WebAssembly זה משפיע ישירות על גודל ההורדה, והוא תומך רק ב-PDF — ברגע שמישהו מעלה DOCX או XLSX אתה חוזר לריבוע הראשון.
הנתיב iframe-ל-Office משמעותו שהמסמכים שלך עוברים דרך תשתית של מישהו אחר, וזה שיחה עם צוות האבטחה שלך שאולי לא תרצה לנהל פעמיים.
Doconut בוחר בדרך השלישית. הקובץ ממופה לתמונות עמודים על ידי השרת שלך, ו-Blazor צריך רק לארח div. עץ הרכיבים שלך לעולם לא מרנדר מחדש צופה שאינו שלו, ומנוע ההבדלים אין מה להילחם בו.
יכולות
מה שאתה מקבל באפליקציית Blazor
מתקין דרך OnAfterRenderAsync
אתחל את הווידג'ט פעם אחת, אחרי הרינדור הראשון, דרך ה-hook הסטנדרטי של אינטרופ JS. מכיוון ש-Blazor לעולם לא מחזיק ב-DOM הפנימי של הצופה, רינדורים נוספים משאירים אותו ללא שינוי.
עובד עם מצב הרינדור שבחרת
Interactive Server, Interactive WebAssembly, או Auto. הצופה מופעל על ידי טוקן אטום במקום מצב רכיב, ולכן שינוי מצב הרינדור אינו משנה את האינטגרציה.
אין פערי פורמט
אותו רכיב פותח PDF, DOCX, XLSX, PPTX, DWG, MSG ושאר הקטלוג. אתה כותב דף צופה אחד, ולא אחד לכל סוג קובץ.
תמונות ממוזערות, חיפוש והדפסה
ממשק ניווט מגיע עם הווידג'ט. אתה מחבר צופה, לא בונה אחד מקנבס וקלט מספר עמודים.
המסמכים נשארים על השרת שלך
שום דבר אינו מוזרם לדפדפן פרט לתמונות העמודים המרות, דבר החשוב יותר ב-WebAssembly ממה שמצופה — הלקוח, אחרי הכל, ניתן לבחינה מלאה.
אינטגרציה
Program.cs ודף Blazor
doconutHost.mount הוא כמה שורות של JavaScript משלך שקוראות $('#div_ctlDoc').docViewer({ ... }) ולאחר מכן .View(token). שמירתו מחוץ ל-Blazor היא מכוונת — ה-DOM של הווידג'ט לא צריך להיות משהו שהרנדרר מנסה להתאים.
פלטפורמות נתמכות
Blazor ServerBlazor WebAssembly.NET 8.NET 6WindowsDocker
csharp
// Program.cs — order matters
builder.Services.AddDoconut(options =>
{
options.LicensePath = "Doconut.Viewer.lic";
});
builder.Services.AddSession();
app.UseSession(); // before UseDoconut()
app.UseDoconutResources(); // before UseDoconut()
app.UseDoconut();
// Viewer.razor — open server-side, hand the token to the widget
@inject Doconut.Viewer Viewer
@inject IJSRuntime JS
<div id="divDocViewer"><div id="div_ctlDoc"></div></div>
@code {
protected override async Task OnAfterRenderAsync(bool firstRender)
{
if (!firstRender) return;
// Authorize first — the viewer renders whatever you hand it.
string token = await Viewer.OpenDocumentAsync("wwwroot/files/Sample.pdf");
await JS.InvokeVoidAsync("doconutHost.mount", token);
}
}פרטים
חשוב לדעת לפני שאתה מתחיל
- הווידג'ט הוא תוסף jQuery, ולכן jQuery צריך להיטען לפני סקריפטי הצופה.
- UseSession() ו-UseDoconutResources() חייבים להיות רשומים לפני UseDoconut().
- ב-WebAssembly קריאת הפתיחה שייכת לשרת — חשוף אותה כנקודת קצה של API מינימלית והחזר רק את הטוקן.
- הטוקן הוא אטום. אל תכניס אותו למחרוזת שאילתא שאתה מתעד, ואל תאגר אותו במצב הרכיב יותר זמן מחיי הדף.
שאלות נפוצות
האם זה עובד ב-Blazor WebAssembly, או רק ב-Server?
שניהם. הרינדור תמיד מתבצע בצד השרת, ולכן ב-WebAssembly מוסיפים נקודת קצה אחת שקוראת OpenDocumentAsync ומחזירה את הטוקן. הלקוח לעולם לא מנתח מסמך, וזה בדיוק הסיבה שהמטען של WASM נשאר ללא שינוי.
האם הרנדרר של Blazor יילחם עם ה-DOM של הצופה?
לא, בתנאי שאתה מתקין אל אלמנט ש-Blazor מתייחס אליו כעלה. רנדר div ריק ותן לווידג'ט למלא אותו דרך אינטרופ — למנוע ההבדלים אין ילדים לתאם.
האם אני צריך דף צופה נפרד לכל סוג קובץ?
לא. דף אחד מטפל בכל הקטלוג. הפורמט מזוהה מהמסמך שאתה פותח, ולא נבחר מראש על ידיך.
נסה זאת עם המסמכים שלך
רשיון זמני לוקח כמה דקות לבקשה ופועל לחלוטין במחשב שלך. הקבצים החשובים הם אלו שכבר מפריעים לצופה הנוכחי שלך.