پرش به مطلب اصلی

بگذارید بازدیدکنندگان تغییرات را ذخیره کنند

هدف​

بگذارید کسی در درگاه شما درخواستی ثبت کند، تغییرش دهد یا حذفش کند — نه فقط بخواند.

پیش از شروع​

  • درگاهی که چه کسی می‌تواند باز کند در آن روی کسانی که وارد می‌شوند است. نوشتن در درگاهی که هر کسی بازش می‌کند رد می‌شود: کسی نیست که تغییر به او نسبت داده شود. ببینید از بازدیدکنندگان بخواهید وارد شوند.
  • یک Custom API برای هر کاری که می‌توانند بکنند. APIای که می‌خواند همان APIای نیست که می‌نویسد، و پلتفرم با آن مثل هر دو رفتار نمی‌کند.

گام‌ها​

۱. Custom API را بنویسید. برای ساختن، فعل آن را POST بگذارید؛ برای تغییر، PATCH؛ برای حذف، DELETE. برایش یک طرح درخواست بنویسید: نخستین چیزی است که میان بازدیدکننده و ستونی که نباید تنظیم کند می‌ایستد. بدون آن، بدنهٔ بازدیدکننده فقط فیلدهایی را می‌تواند داشته باشد که اسکریپت شما با getInput می‌خواند، و هر چیز دیگری رد می‌شود. ۲. راه‌حل خود را باز کنید، درگاه‌ها را انتخاب کنید و درگاه را باز کنید. ۳. زیر چه چیزی را می‌خواند، افزودن چیزی برای خواندن را بزنید و انتخاب کنید:

  • جدولی که صفحه‌تان در createRecord / updateRecord / deleteRecord نام می‌برد،
  • عملیات — ساختن یک رکورد، تغییر یک رکورد یا حذف یک رکورد،
  • APIای که پاسخ می‌دهد. ۴. ذخیره را بزنید.

هر یک از پنج کاری که یک صفحه می‌تواند بکند ردیف خودش را می‌خواهد. درگاهی که می‌تواند درخواست‌ها را فهرست کند تا ردیف ساختن را هم اضافه نکنید نمی‌تواند یکی بسازد — این دو قرارداد جدا هستند، و صفحه فقط می‌تواند نام جدول را بگوید.

صفحهٔ شما چه می‌کند​

هیچ چیز تازه‌ای. همان کنش‌هایی که برای برنامه‌ای درون پلتفرم می‌کشیدید:

createRecord("par_request", {
  par_name: getState("subject"),
  par_detail: getState("detail")
}, "saved");

در درگاه، این به فراخوانی APIای تبدیل می‌شود که برای par_request / ساختن مجاز کرده‌اید. نقشه تغییر نمی‌کند — و این تمام هدف منتشرکردن یک برنامه در دو جاست.

API چه باید بکند​

تصمیم بگیرد چه کسی اجازه دارد، و آنچه را بازدیدکننده نباید تعیین کند خودش پر کند.

var me = portalEmail();
if (me == '') {
  throwValidationError('پیش از ثبت درخواست وارد شوید.');
} else {
  var subject = getInput('par_name');
  if (subject == '') {
    throwValidationError('لطفاً برای درخواست‌تان یک عنوان بگذارید.');
  } else {
    // **بازدیدکننده تعیین نمی‌کند چه کسی آن را ثبت کرده است.** هر چه صفحه برای این ستون فرستاده
    // نادیده گرفته می‌شود؛ نشانی از نشست واردشدهٔ خودش می‌آید.
    var id = createRecord('par_request', {
      par_name: subject,
      par_detail: getInput('par_detail'),
      par_raised_by_email: me,
      par_status: 'New'
    });
    setOutput('record', getRecord('par_request', id));
  }
}

دورنگه‌داشتن بازدیدکننده از ستون‌هایی که نباید تعیین کند​

درگاه بدنه را دقیقاً همان‌طور که صفحه فرستاده رد می‌کند، و جز این نمی‌تواند: اینکه بازدیدکننده کدام فیلدها را می‌تواند تعیین کند پرسشی دربارهٔ جدول شماست، و فقط قرارداد شما پاسخش را می‌داند.

دو چیز پاسخش می‌دهند، و هر دو را می‌خواهید.

شمای درخواست‌تان، که فیلدی را که قول نداده‌اید رد می‌کند. "additionalProperties": false را بگذارید و فقط آنچه بازدیدکننده می‌تواند بفرستد را فهرست کنید:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["par_name"],
  "properties": {
    "par_name": { "type": "string", "minLength": 1, "maxLength": 200 }
  }
}

حالا بدنه‌ای که par_raised_by_email دارد، پیش از اجرای اسکریپت‌تان رد می‌شود.

خواندن هر فیلد با نام، همان‌طور که اسکریپت بالا می‌کند. getInput('par_name') آنچه را خواسته‌اید می‌گیرد و نه چیز دیگر.

هرگز بدنه را یکجا رد نکنید

اسکریپتی که کل بدنه را به createRecord می‌دهد، به بازدیدکننده اجازه می‌دهد هر ستونی را که نامش را حدس بزند تعیین کند — از جمله ستونی که می‌گوید رکورد مال کیست. شما آن را دشوار می‌کند؛ خواندن با نام ناممکنش می‌کند.

بازدیدکننده هنگام شکست چه می‌بیند​

  • ردی که خودتان نوشته‌اید — throwValidationError('لطفاً برای درخواست‌تان یک عنوان بگذارید.') — کنار دکمه‌ای که فشرده‌اند ظاهر می‌شود.
  • هر چیز دیگر یک پیام کلی «ذخیره نشد» نشان می‌دهد و دلیل واقعی به گزارش میزبان درگاه می‌رود.

این تفکیک عمدی است: جملهٔ شما دربارهٔ خودِ اوست و می‌تواند بر اساسش کاری بکند، در حالی که خطای درونی هیچ‌کدام نیست.

پیام‌های اعتبارسنجی شما را غریبه‌ها می‌خوانند

چون نوع اول نمایش داده می‌شود، آن جمله‌ها را برای عموم بنویسید. نام ستون، جدول یا قاعدهٔ درونی نیاورید — «لطفاً برای درخواست‌تان یک عنوان بگذارید» به‌جای «par_name قید NOT NULL را نقض کرد».

پلتفرم چه چیزی را بررسی نمی‌کند​

اینکه بازدیدکننده بتواند آنچه را تازه نوشته دوباره بخواند. اگر API ساختن شما رکوردی را ذخیره کند که API خواندن‌تان فیلترش می‌کند، رکورد وجود دارد و فهرست نشانش نمی‌دهد. هیچ هشداری نیست: این دو اسکریپت قرارداد جدا هستند، و پلتفرم دربارهٔ جفتی که شما عمداً نوشته‌اید دوباره قضاوت نمی‌کند.

اگر صفحه‌ای چیزی ذخیره کرد و بعد فهرست خالی نشان داد، معمولاً همین است — فیلتر API خواندن را با آنچه API نوشتن ذخیره کرده مقایسه کنید.

خاموش‌کردنش​

ردیف را از چه چیزی را می‌خواند بردارید، یا چه کسی می‌تواند باز کند را به همه برگردانید. هر کدام بی‌درنگ نوشتن درگاه را متوقف می‌کند. دومی حتی با اینکه ردیف‌ها هنوز فهرست شده‌اند، از لحظهٔ ذخیره متوقفش می‌کند — درگاهِ باز خواندن‌هایش را می‌دهد و هیچ‌یک از نوشتن‌هایش را.

مرتبط​