لقد واجهت نفس النوع من التعطل، لكنني سلكت مسارًا مختلفًا. بدلاً من استهلاك نقاط نهاية واجهة برمجة تطبيقات التقويم مباشرةً، يقوم المستورد الخاص بي بإنشاء BBCode [event] وينشره في Discourse، مما يسمح للمكون الإضافي بتحليله كما لو أن مستخدمًا من الموظفين قد أنشأ الحدث يدويًا. بهذه الطريقة أتجنب الاعتماد على معلمات الاستعلام العابرة مثل include_expired، وأحصل على عقد أكثر استقرارًا - من غير المرجح أن تتغير المشاركات و BBCode العادية دون إشعار.\n\n\n[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]\nMeet to discuss Discourse RESTful API\n[/event]\n\n\nالمقايضة هي المزيد من العمل من جانبي: اضطررت إلى كتابة منسق يحول بيانات ICS إلى علامات [event] مهربة بشكل صحيح، ويتعامل مع الأحداث التي تستمر طوال اليوم مقابل الأحداث المحددة بوقت، وما إلى ذلك. ولكن في الممارسة العملية، كان هذا النهج أكثر مرونة بكثير عبر الترقيات. إنه لا يزيل الحاجة إلى إشعارات الإهمال الأولية (لا يزال بإمكاني أن تفشل واجهات برمجة التطبيقات بسرعة أو على الأقل تحذر عند إزالة الخيارات)، ولكنه قلل من خطر تعطل نصوصي البرمجية بصمت.
4 إعجابات