وب مدرن، رابط کاربری و تجربه‌ی وب · فصل ۱ — مرورگر، سرور، رندر و معماری صفحه · 30
صفحه‌ی ثابت و صفحه‌ی پویا چیست و کدام برای چه چیزی مناسب است؟
_Locale: fa-IR · Lesson: WEBF-003 · Public order: 30_
_Locale: fa-IR · Lesson: WEBF-003 · Public order: 30_
خروجی و artifact کاری
این درس برای ساختن دفتر تصمیم Static/Dynamic نسخه ۱ است: یک artifact تصمیم که مشاهده، فرض، محدودیت و evidence موردنیاز را از هم جدا می‌کند. هدف حفظ یک مدل قابل‌انتقال است، نه حفظ‌کردن نام ابزارها.
For a bounded page requirement, identify what can remain pre-produced, what must vary, where variation can occur, and what evidence would justify the decision.
مدل مرزی
Static و Dynamic درباره محل و زمان ایجاد variation هستند؛ نه معادل ساده‌ی «بدون JavaScript/با JavaScript» یا «بدون database/با database». یک صفحه می‌تواند از قبل تولید شده باشد و در مرورگر رفتار تعاملی غنی داشته باشد. یک response نیز می‌تواند در زمان request تولید شود، حتی اگر هیچ databaseای نخواند. تصمیم درست از منبع variation آغاز می‌شود.
در هر بخش سه برچسب نگه دارید: «مشاهده‌شده»، «استنباط محدود» و «نیازمند بررسی». اگر evidence در دسترس نیست، نتیجه را unknown ثبت کنید؛ نام ابزار یا pass شدن یک happy path جای evidence را نمی‌گیرد.
1. response را توصیف کنید، نه نام ابزار را
بپرسید representation تحویل‌شده از قبل آماده بوده یا برای همین request تولید شده است. نام framework فقط سرنخ پیاده‌سازی است، نه خود classification.
2. تولید server را از update سمت client جدا کنید
HTML ازپیش‌تولیدشده می‌تواند JavaScript داشته باشد و theme، filter یا داده بعدی را تغییر دهد. این رفتار، response اولیه server را request-generated نمی‌کند.
3. database الزامی نیست
خروجی زمان request می‌تواند به header، زمان، محاسبه، service بالادستی یا configuration وابسته باشد. در جهت مقابل، build می‌تواند database را بخواند و file ثابت بسازد.
4. بخش‌ها را classify کنید، نه کل صفحه را با شعار
یک صفحه ممکن است shell ازپیش‌تولیدشده، status زمان request و personalization سمت client را هم‌زمان داشته باشد. یک label کلی معماری واقعی را پنهان می‌کند.
5. تصمیم را به نرخ تغییر و evidence وصل کنید
ثبت کنید چه کسی اطلاعات را تغییر می‌دهد، تغییر با چه تأخیری باید دیده شود، آیا user-specific است، failure قابل قبول چیست و cache invalidation چگونه کنترل می‌شود.
روش پنج‌مرحله‌ای
- صفحه را به regionهایی تقسیم کنید که مستقل از هم تغییر می‌کنند.
- برای هر region منبع variation را تعیین کنید: نویسنده محتوا، deployment، context درخواست، state کاربر یا داده زنده.
- زمان تولید را انتخاب کنید: build time، request time یا browser runtime.
- cache scope، trigger ابطال، fallback شکست، مرز privacy و اثر accessibility را ثبت کنید.
- اگر معماری ترکیبی است، classification ترکیبی بنویسید و یک label را به همه بخش‌ها تحمیل نکنید.
مثال حل‌شده
صفحه documentation به‌صورت HTML ازپیش‌ساخته تحویل می‌شود. preference مربوط به theme در browser خوانده و classها بدون request جدید تغییر می‌کنند. badge وضعیت service از endpoint و در زمان request گرفته می‌شود. ledger قابل دفاع، بدنه را pre-produced، theme را client-dynamic و badge را request-dependent ثبت می‌کند و برای هرکدام cache و failure rule جدا دارد. label کلی dynamic این مرزها را از بین می‌برد.
ماتریس تصمیم و evidence
| موضوع | مرز/مالک | evidence | تصمیم یا محدودیت |
|---|---|---|---|
| بدنه مقاله | build time | HTML مشترک ازپیش‌تولیدشده | ابطال هنگام publish محتوا |
| theme | browser runtime | preference هر device | default خوانا بدون script |
| badge وضعیت | fetch زمان request/runtime | status مشترک کوتاه‌عمر | نمایش unknown زمان‌دار هنگام شکست |
| پنل account | request یا client fetch | داده private هر کاربر | هرگز در public cache قرار نگیرد |
خطاهای محتمل و روش اصلاح
- برابرگرفتن Static با نبود JavaScript
- برابرگرفتن Dynamic با وجود database
- ادعای اینکه Static همیشه سریع‌تر یا امن‌تر است
برای هر مورد، ادعا را محدود کنید، یک counterexample بسازید و بنویسید کدام مشاهده می‌تواند آن را تأیید یا رد کند.
تمرین انتقال
سناریو را طوری تغییر دهید که یکی از فرض‌های مثال دیگر برقرار نباشد. بدون کپی‌کردن تصمیم قبلی، دفتر تصمیم Static/Dynamic نسخه ۱ را دوباره بسازید؛ سپس تفاوت decision rule و تفاوت دادهٔ ورودی را توضیح دهید.
این درس چه چیزی را ثابت نمی‌کند
این درس certification، تضمین production یا پوشش همه implementationها را ادعا نمی‌کند. نتیجه فقط در مرز سناریو، sourceهای تاریخ‌دار و observationهای ثبت‌شده معتبر است.
خودسنجی
- [ ] آیا مسئولیت‌ها را از نام framework یا tool جدا کرده‌ام؟
- [ ] آیا دست‌کم یک failure probe و نتیجه موردانتظار آن را نوشته‌ام؟
- [ ] آیا fact، inference و design choice از هم مشخص‌اند؟
- [ ] آیا non-claim و evidence گمشده را ثبت کرده‌ام؟
- [ ] آیا transfer را روی context تغییرکرده و بدون پاسخ آماده انجام داده‌ام؟
منابع و مرز تازگی
sourceها در 2026-09-19 طبق Bible منجمدشده مرور شده‌اند. تاریخ review_due یک trigger برای بازبینی نسخه‌ای است؛ هیچ بسته‌ای نباید درجا و بدون نسخه جدید تغییر کند.
- S-MDN-CS — Static and dynamic server response model. (https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview; review: 2026-12-31)
- S-MDN-JS — Client-side and server-side dynamic behavior distinction. (https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/What_is_JavaScript; review: 2026-12-31)
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
WEBF-003-SUM1 retrieval
WEBF-003-SUM2 application
WEBF-003-SUM3 diagnosis
WEBF-003-SUM4 decision
WEBF-003-SUM5 transfer
ملاک‌های ارزیابی (rubric)
| Dimension | Critical | Sufficient evidence |
|---|---|---|
| boundary_accuracy | yes | Responsibilities in static versus dynamic delivery decisions are placed at the correct bounded layer/time/location and adjacent lessons are not absorbed. |
| evidence_and_uncertainty | yes | Current factual claims are source-bounded; conditional paths and unknowns are stated rather than guessed. |
| decision_quality | yes | The decision recorded in Static/Dynamic Response Decision Record v1 follows from the scenario constraints and states what would invalidate it. |
| transfer | no | The learner applies the same reasoning in a changed scenario without copying a fixed stack answer. |
A submission passes only when every critical dimension is sufficient and the learner states missing evidence honestly. AI suggestions are not observed evidence; the learner remains accountable for the final bounded judgment.
منابع و تازگی
مطالعهٔ موارد (case studies)
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)