نشر تطبيق كبوابة
الهدف
خذ تطبيقًا رسمته من قبل وامنحه عنوان ويب خاصًا به، ليتمكن من هم خارج مؤسستك — العملاء والمتقدّمون والجمهور — من فتحه دون تسجيل دخول إلى المنصّة إطلاقًا.
قبل أن تبدأ
تحتاج إلى أمرين، ولن تُحفظ البوابة بدون الأول:
- تطبيق استوديو. البوابة تنشر رسمًا ولا تحتويه. انظر إنشاء تطبيق استوديو.
- واجهة API مخصّصة لكل ما تقرؤه البوابة. لا تق رأ البوابة من جدول مباشرة — السبب في ماذا تستطيع البوابة أن تقرأ أدناه. إن كانت بوابتك تعرض نصًا وصورًا فقط فتجاوز هذه الخطوة.
الخطوات
- افتح حلّك واختر البوابات.
- اضغط جديد.
- اعطها اسمًا. هذا ما ستسمّيه أنت وزملاؤك؛ وليس ما يراه الزائر، لأن كل ما يراه الزائر مرسوم.
- اختر التطبيق المنشور من القائمة. تظهر تطبيقات هذه البيئة وحدها.
- اكتب عنوان ويب. الجزء الأول فقط —
acme-supportوليس العنوان كاملًا. بقية العنوان ملك لنشر بارسوير لديك، والتلميح أسفل الحقل يبيّن شكل العنوان النهائي. - اختر من يمكنه فتحها. الجميع يعني أن العنوان يفتح على تطبيقك مباشرة؛ ومن يسجّل الدخول يضع نموذج تسجيل دخول أمامه — انظر اطلب من الزوّار تسجيل الدخول.
- اختر ما الذي تقرؤه — واجهات API المخصّصة المسموح لهذه البوابة باستدعائها.
- اختر يعمل الزوار بصفة — أدوار الأمان التي يحملها كل زائر لهذه البوابة. انظر أيّ الجداول تصل إليها البوابة.
- اترك منشورة بلا تفعيل ما دمت تعمل عليها، وفعّلها حين تريد أن يبدأ العنوان بالاستجابة.
- اضغط حفظ.
ماذا تستطيع البوابة أن تقرأ
تقرأ البوابة عبر واجهات API المخصّصة التي تدرجها، ولا شيء سواها. لا تستطيع القراءة من جدول مباشرة، ولا يوجد إعداد يسمح بذلك.
هذا مقصود. يجب ألا يتحوّل رسم شاشة إلى طريقة لوضع جدول على الإنترنت العامّ من غير قصد. واجهة API المخصّصة شيء كتبه أحدهم عن عمد: تقرّر ما يراه الغريب، في نصّ برمجي يمكنك قراءته. أما الجدول فهو جدول فحسب.
فإن احتاجت شاشة على بوابتك إلى بيانات، فالترتيب هو: عرّف واجهة API المخصّصة، ثم أشّر عليها في قائمة البوابة، ثم اجعل شاشتك تقرأ عبرها.
تسمية الواجهة في شاشتك
تسمّي شاشة البوابة العقد الذي تقرأ عبره، لا الجدول:
loadRecords("api:par_articles@1", "articles", { top: 20, orderBy: "par_name" })
api: تقول إن هذه واجهة API مخصّصة؛ وpar_articles اسمها المنطقي؛ و@1 إصدارها، لأن إصدارين من
واجهة واحدة عقدان مختلفان. والشكل نفسه يصلح لـ getRecord وcreateRecord وupdateRecord
وdeleteRecord — وأيّها استدعيت هو ما يقرّر ما تفعله المنصّة، وعلى فعل الواجهة نفسها أن يكون قادرًا
على الإجابة. فـ createRecord موجّهة إلى واجهة لا تفعل إلا القراءة ستفشل عند تشغيل الشاشة.
في قائمة التطبيقات تقرأ الشاشة المرسومة جداولها مباشرة — وهذا ما يفعله تطبيق شخص مسجَّل الدخول،
ولهذا فيه ترقيم صفحات وتصفية. أما على البوابة فلا باب كهذا. لذلك الشاشة التي تسمّي api: تُفتح على
البوابة وتُرفض في الواجهة الرئيسية، وتقول ذلك بدل أن تعرض قائمة فارغة.
وإن أردت رسمًا واحدًا في المكانين فهو يحتاج شاشتين. تلك مقايضة اختارتها المنصّة عن عمد: بوابتك تقرأ عبر عقد كتبته أنت، والعقد هو ما يقرّر ما يراه الغريب.
ينبغي أن تجيب واجهتك بـ { "rows": [...], "total": 12 } للقائمة. وإن أجابت بشكل آخر، تعرض الشاشة
قائمة فارغة بدل خطأ — فلا يُفسد خطأ في واجهة واحدة البوابة كلّها.
القائمة إذن، لا خريطة. التأشير على واجهة يعني أن لهذه البوابة أن تستدعيها؛ لا أكثر. أما متى فتقرّره شاشتك بتسميتها. والواجهة التي لم تؤشّر عليها تُرفض ولو طلبتها شاشة، وهذا ما يمنع خطأً في الرسم من أن يصير بابًا.
الكتابة تحتاج زوّارًا يسجّلون الدخول — أو اختبارًا. الواجهة التي تجيب POST أو PATCH أو PUT أو DELETE لا تُستدعى إلا بعد ضبط من يستطيع فتحها على «من يسجّلون الدخول»، فالبوابة المفتوحة لا أحد لديها لتنسب إليه التغيير. والطريق الوحيد لتجاوز ذلك هو القسم التالي.
اسأل من يدير تثبيت بارسوير لديكم إن كان مضيف البوابات قد مُنح نطاق الصلاحية الذي تطلبه واجهتك. كل واجهة API مخصّصة تسمّي نطاقًا، ومضيف البوابات هو من يحمله نيابة عن زوّارك — وبدونه تُرفض كل قراءة ولا تعرض الصفحة شيئًا.
أي الجداول تصل إليها البوابة
واجهات API المخصّصة التي تختارها تحدّد أيّ العقود يمكن للصفحة أن تستدعيها. ويعمل الزوار بصفة تحدّد أيّ الجداول يمكن لتلك العقود بعدئذ أن تقرأها وتكتب فيها — أدوار الأمان نفسها التي تمنحها لزملائك، بالصلاحيات نفسها.
امنح البوابة دورًا خاصًا بها يمنح بالضبط ما تحتاجه واجهاتها — القراءة والإنشاء على «الحالات» مثلًا — لا دورًا يستخدمه موظفوك. كل زائر للبوابة يحمله، سجّل الدخول أم لا.
إن لم تختر أي دور فلن تصل البوابة إلى شيء. تبقى قوائمها فارغة ويقول كل حفظ تعذّر الحفظ. هذا هو الاتجاه الآمن، وهو أول ما تتحقق منه حين لا تعرض بوابةٌ شيئًا في صفحة تبدو سليمة.
في بوابة تطلب تسجيل الدخول، الدور ليس نهاية الأمر. إن كان للجدول قاعدة تقول أيّ الصفوف لمن — انظر حدّد سجلات من يراها الزائر — يُضيَّق كل زائر إلى صفوف شركته بعد أن يسمح له الدور بالدخول.
لا يُعرض دور مسؤول المنصة هنا أبدًا. فالزائر الذي يحمله يحمل البيئة كلها.
اسمح لأي شخص بأن يرسل إليك شيئًا
أشّر على اسمح لأي شخص بإرسال شيء إليك — ولا يظهر هذا الخيار إلا حين يكون من يستطيع فتحها مضبوطًا على «أي شخص» — فيصير بإمكان زائر بلا حساب أن يكتب، شريطة أن يقضي متصفحه أولًا لحظة على أحجية تثبت أنه ليس برنامجًا.
هذا ما يجعل نموذج التواصل ممكنًا. بدونه، البوابة التي يستطيع أي شخص فتحها تقرأ ولا تكتب، أي أن عليك أن تطلب ممن يريد مراسلتك أن ينشئ حسابًا أولًا — وذلك ليس نموذج تواصل.
لا شيء تَرسمه ولا شيء يُطلب من الزائر. لا مربّع تؤشّر عليه، ولا كلمة ملتوية تقرؤها، ولا صور إشارات مرور. تعطي المنصّة المتصفح حسابًا صغيرًا؛ يفرغ منه حاسوب محمول قبل أن تنتبه، ويأخذ هاتف قديم لحظة ويكتب تحت الزر «نتحقق من أنك إنسان…». لا يُجمَع شيء عن الزائر، ولا يأتي شيء في الصفحة من خادم شركة أخرى.
ما يمنعه وما لا يمنعه. يجعل الإرسال بالجملة مكلفًا: البرنامج الذي كان يرسل ألف نموذج في الساعة صار يدفع عملًا حقيقيًا عن كل واحد، فيرسل أربعين. لكنه لا يوقف من كان مصمّمًا ومستعدًا لتشغيل متصفحات حقيقية — ولا يفعل ذلك أي خيار من هذا النوع في أي مكان، مهما كان اسمه. اعتبره مرشّحًا قويًا للرسائل المزعجة لا قفلًا.
ثلاثة أشياء لا يغيّرها:
- ما الذي يُستدعى. فقط واجهات API المخصّصة التي أشّرت عليها أعلاه، تمامًا كما كان.
- ما الذي يُكتب. يظلّ مخطّط الطلب الخاص بالواجهة هو ما يقرّر أي الحقول يجوز للزائر ضبطها.
- من يكون الزائر. لم يسجّل أحد الدخول، فلم يُتحقَّق من شيء. إن كانت واجهتك تخزّن عنوان بريد كتبه الزائر، فهو عنوان كتبه أحدهم لا أكثر. وحيث يهمّ ذلك، اطلب من الزوّار تسجيل الدخول بدلًا من هذا.
في هي هذا بالضبط: بوابة مفتوحة، وكتابة واحدة، وملف مرفق بها، وصفحة داخل الموقع نفسه تشرح ما ينبغي النظر إليه.
فتحها
متى صار للبوابة عنوان، عرضته القائمة رابطًا، وفتحه فتح البوابة في شريط الأوامر في تبويب جديد. وإذا فتحت البوابة للتحرير ظهر العنوان نفسه تحت حقل عنوان الويب ومعه زرّان صغيران: أحدهما يفتح البوابة حين تريد النظر إليها، والآخر ينسخ العنوان حين توشك أن ترسله إلى غيرك. ولا يحمل أيّهما كلمة — فالعنوان طويل، والتسميات بجانبه تدفع الزرّ الثاني إلى سطر وحده — فمرِّر المؤشر فوق أيّهما يقل لك أيّهما هو.
لا يظهر العنوان إلا بعد الحفظ. وما دمت تكتب التسمية، فالتلميح تحت الحقل يبيّن شكل العنوان النهائي؛ ورابط يُبنى من شيء لم يُحفظ بعد يشير إلى بوابة ليست هناك.
وإذا كان تثبيتكم لا يخدم بوابات فلا عنوان يُفتح، ويبقى التلميح مكان الرابط. اسأل من يدير تثبيت بارسوير لديكم.
هذه الجملة ليست عن بوابتك قطّ — بل هي المنصّة تقول إنها لم تستطع الجواب، ورسمك وعنوانك ومفتاح منشورة كلّها خارج الأمر. وهي أحد شيئين، وكلاهما لمن يدير تثبيتكم: الخدمات متوقّفة، أو مضيف البوابات لا يستطيع الحصول على اعتماد من بارسوير. أمّا العنوان الخاطئ فيقول ش يئًا آخر تمامًا («لا شيء منشور هنا»)، فتُميّز بينهما من الصفحة نفسها.
ما يراه الزائر
شيئان في صفحة البوابة للمنصّة لا لك، ومعرفتهما قبل أن يسألك أحد عنهما جديرة بالعناء.
البوابة تُفتح في الوضع الداكن. تطبيقاتك الخاصة في بارسوير تُفتح فاتحة، لأنّك تجلس إليها يوم عمل كاملاً؛ أمّا البوابة فموضع يصله غريب من رابط في رسالة، على هاتف في الغالب، والداكن أرفق انطباع أوّل. وهناك زرّ صغير فاتح/داكن يطفو في زاوية كلّ صفحة بوابة — يميناً في الإنجليزية، ويساراً في العربية والفارسية — وأوّل مرّة يضغطه فيها الزائر يصير ذلك اختياره من بعد: المتصفّح يحفظه، ولا يعود الوضع الداكن يجادل من أجاب السؤال مرّة.
ويبقى لك أن ترسم مفتاحك أنت. فـ setTheme("light") و setTheme("dark") متاحان لأيّ معالج على
شاشة مرسومة، والزرّ الذي ترسمه والزرّ الذي في الزاوية يعملان على الإعداد نفسه. زرّ الزاوية
هو الحدّ الأدنى، حتّى تكون البوابة مقروءة قبل أن يخطر لأحد أن يرسم واحداً.
والرسم يتكيّف مع النافذة. تُرسم الشاشة بمقاس ما، لكنّها لا تُعرض به: فالكتل التي تمتدّ عرض الصفحة تحفظ مسافتها إلى كلّ هامش وتدع الوسط يتمدّد، والأشياء المرسومة جنباً إلى جنب تحفظ حصّتها من العرض. فالبوابة تتّسع للنافذة التي تُفتح فيها، عند أيّ عرض، ولا يخرج شيء عن الصفحة.
وما لا يستطيعه هذا التكيّف هو إعادة الترتيب. عمودان رُسما جنباً إلى جنب يبقيان كذلك — على الهاتف عمودان ضيّقان، لا عمود واحد والثاني تحته. فإن كانت البوابة تهمّ على الهواتف، فارسم شاشة للهاتف: ولهذا وُجدت النماذج الثلاثة بوابة على سطح المكتب / اللوحي / الهاتف.
عن العنوان
عنوان واحد يستجيب لبوابة واحدة، على مستوى التثبيت كلّه. لا واحد لكل بيئة — بل واحد إجمالًا. أمام كل البيئات باب أمامي واحد، وهو يقرّر إلى أين تذهب الطلبات بالنظر إلى العنوان.
لهذا نتيجة واحدة ستلقاها أول مرة ترقّي فيها حلًّا:
استورد الحلّ نفسه إلى الاختبار أو الإنتاج، فتجد أن العنوان المطلوب يستجيب بالفعل للبيئة التي بنيتها فيها. لذلك تصل البوابة بلا عنوان ومطفأة، وتظهر في هذه القائمة بوسم يحتاج عنوانًا.
هذا ليس خطأ ولم يُصب حلّك بسوء. فبوابة التطوير وبوابة الإنتاج كانتا ستحتاجان عنوانين مختلفين على أي حال. افتح البوابة في البيئة الجديدة، وامنحها العنوان الذي تريده هناك، وفعّل منشورة.
التشغيل والإطفاء
منشورة هو مربّع الاختيار الوحيد في بوابة الصانع الذي يعني تفعيله أن كل من يعرف العنوان في العالم يستطيع رؤية هذا. لذلك:
- يبدأ مطفأً، ويبقى كذلك حتى تشغّله بنفسك.
- لا يُشغّل ما دامت البوابة بلا عنوان — إذ لا مكان تستجيب فيه. ولا يُعدّ نطاقك الخاص عنوانًا إلا بعد التحقق منه، للسبب نفسه: لا شيء يجيب على نطاق غي ر مُتحقَّق منه.
- إطفاؤه يوقف استجابة العنوان فورًا. أما التطبيق الذي كانت تنشره فلا يُمسّ.
حذف بوابة
حذف البوابة يوقف استجابة العنوان ويحرّره لشيء آخر. ولا يحذف التطبيق — يبقى الرسم تطبيقًا يفتحه موظفوك في الغلاف، وهذا هو سبب فصل النشر عن الرسم أصلًا.