Adnane Kadri

يمكنك تخصيص نوع البيانات في البارمتر الممرر في الراوت عن طريق التابع where , الذي يقبل البارمترز على الترتيب : 
param : معبرة عن اسم البارمتر الذي تقوم بتمريره .
regex : تعبر عن Regular Expression تخص المقبول في هذا البارمتر فقط .
و يتم تعريف التابع where التابع للinstance الذي اسمه Route في مثالك عن طريق : 
<? Route::get('news/edit/{id}', 'YourController@your_method')->where('id', '$[0-9]+^'); غير أن هاته الطريقة لن تحقق الغرض و سيتم رمي Exception Not Found 404 في حالة ما كان البارمتر id لا يماثل العبارة [0-9]+ , أي أنه ليس integer .
أما في حالة ما أردت عمل Redirect لصفحة تريدها من داخل الController فيمكنك عمل validation بسيط للـ ID الممرر بهذا الشكل : 
<?php use Illuminate\Support\Facades\Validator; // لا تنسى تضمين الواجهات الللازمة class MyController extends Controller{ public function myMethod(Request $request){ $validator = Validator::make($request->all() , ['id' => 'integer']); if($validator->fails()){ // قم باعادة التوجيه } } }  

الان و بعد الإنتهاء من جانب الباك اند يتطلب عليك التحقق إن كان الرد من الـ API يحمل أخطاء بأكواد حالات معينة ومن ثم التصرف بناء عليه , كأن تقوم بتعطيل عملية التسجيل أو مواصلة العملية بعد تسجيل التوكن و اعادة التوجيه .
و هذا طبعا يخضع لأكواد الحالات بالـ API الذي تقوم بجلب منه البيانات و يخضع أيضا لتعريفك للـ errors .
فعلى سبيل المثال يكون الكود كالتالي : 
// قم باستدعاء الدالة من المكان الصحيح login() async{ var response = await http.post('/your-end-point',auth_data); if(response.statusCode == 422){ print(jsonDecode(response.body['errors'])) // طباعة الاخطاء في حالة وجودها } else{ // اكمال عملية تسجيل الدخول و عمل اعادة التوجيه بعد تسجيل التوكن وحفظه } } ومن المفضل في الباك اند في اللارافل استعمال الواجهة : 
<?php use Illuminate\Support\Facades\Validator; .. عوضا عن الميثود validate ضمن الـ instance الذي اسمه Request : 
<?php class myController extends Controller{ public function myMethod(Request $request){ $request->validate($rules); } } حتى تتحصل على حرية أكبر ولا تترك الـ Laravel Exceptions يتولى إعادة التوجيه و تسجيل الأخطاء بالجلسة التي هي من المفروض خارج العملية فيما يخص بناء الAPI و باقي العملية.

للأسف سرفرات هيروكو تمتلك تخزين " سريع الزوال " , أي انك تستطيع اضافة الملفات والصور الى القرص غير أن هاته الملفات لن تكون حاضرة في حالة رفع جديد أو اعادة تشغيل التطبيق وهذا خلال 24 ساعة 
فحل المشكلة هو اما بـ : 
1 . استعمال التخزين العام بداخل مجلد الpublic مباشرة , وهذا بالتعديل على ملف config/filesystems.php :
<?php 'heroku_public' => [ 'driver' => 'local', 'root' => public_path() . '/uploads', ],  ومن ثم استعمال نمط التخزين على هذا النحو :
<?php use Illuminate\Support\Facades\Storage; ... Storage::disk('heroku_public')->put($your_path, $your_file_content)  
غير أن هذا لن يحل المشكلة ككل و ستبقى الملفات عامة و ظاهرة و هذا لن يكون في الصالح في حال ما أردت حماية خصوصية المستخدمين . 
فالحل النهائي هو باستخدام تخزين خارجي تماما . مثل : cloudinary , aws s3 . وخصوصا مع الكثير من  الأشياء التي يجعل لارافل العملية بها سهلة . 

و اقترح بقوة استعمال cloudinary cloud storage فسرفرات هيروكو تتوفر على اضافة add-ons تسهل ذلك باسم cloudinary . و من جانب اللارافل موجود على الgithub باكج مفتوحة المصدر تسهل ربط التطبيق بتخزين الكلاود الخاص بك على كلاوديناري باسم laravel-cloudinary .