বহু অ্যাপ্লিকেশন

কখনও কখনও একটি প্রকল্প বিভিন্ন উপ-প্রকল্পে বিভক্ত হতে পারে, যেমন একটি মার্কেটপ্লেস তিনটি উপ-প্রকল্পে বিভক্ত হতে পারে: মার্কেটপ্লেস প্রধান প্রকল্প, মার্কেটপ্লেস API ইন্টারফেস এবং মার্কেটপ্লেস প্রশাসনিক ব্যাকএন্ড, সকলেই একই ডাটাবেস কনফিগারেশনের ব্যবহার করে।

webman আপনাকে এইভাবে অ্যাপ ডিরেক্টরি পরিকল্পনা করতে দেয়:

app
├── shop
│   ├── controller
│   ├── model
│   └── view
├── api
│   ├── controller
│   └── model
└── admin
    ├── controller
    ├── model
    └── view

যখন আপনি যে ঠিকানায় অ্যাক্সেস করছেন http://127.0.0.1:8787/shop/{কন্ট্রোলার}/{পদ্ধতি} তখন এটি app/shop/controller এর অধীনে কন্ট্রোলার এবং পদ্ধতি অ্যাক্সেস করে।

যখন আপনি যে ঠিকানায় অ্যাক্সেস করছেন http://127.0.0.1:8787/api/{কন্ট্রোলার}/{পদ্ধতি} তখন এটি app/api/controller এর অধীনে কন্ট্রোলার এবং পদ্ধতি অ্যাক্সেস করে।

যখন আপনি যে ঠিকানায় অ্যাক্সেস করছেন http://127.0.0.1:8787/admin/{কন্ট্রোলার}/{পদ্ধতি} তখন এটি app/admin/controller এর অধীনে কন্ট্রোলার এবং পদ্ধতি অ্যাক্সেস করে।

webman-এ, আপনি এমনভাবেও অ্যাপ ডিরেক্টরি পরিকল্পনা করতে পারেন।

app
├── controller
├── model
├── view
│
├── api
│   ├── controller
│   └── model
└── admin
    ├── controller
    ├── model
    └── view

এভাবে যখন ঠিকানাটি http://127.0.0.1:8787/{কন্ট্রোলার}/{পদ্ধতি} অ্যাক্সেস করা হয়, তখন এটি app/controller এর অধীনে কন্ট্রোলার এবং পদ্ধতি অ্যাক্সেস করে। যখন পথটি api অথবা admin দিয়ে শুরু হয়, তখন এটি সংশ্লিষ্ট ডিরেক্টরির অধীনে কন্ট্রোলার এবং পদ্ধতি অ্যাক্সেস করে।

বহু অ্যাপ্লিকেশনের জন্য ক্লাসের নামকরণ স্থানীয়তা psr4 মেনে চলা উচিত, যেমন app/api/controller/FooController.php ফাইল কাছাকাছি কিছু হতে পারে:

<?php
namespace app\api\controller;

use support\Request;

class FooController
{

}

বহু অ্যাপ্লিকেশন মিডলওয়্যার কনফিগারেশন

কখনও কখনও আপনি বিভিন্ন অ্যাপ্লিকেশনের জন্য বিভিন্ন মিডলওয়্যার কনফিগার করতে চান, যেমন api অ্যাপ্লিকেশন একটি ক্রস-ডোমেইন মিডলওয়্যার প্রয়োজন হতে পারে, admin একটি অ্যাডমিন লগইন চেক করার মিডলওয়্যার প্রয়োজন, তাহলে config/midlleware.php কনফিগারেশন দেখতে যেমন হতে পারে:

return [
    // গ্লোবাল মিডলওয়্যার
    '' => [
        support\middleware\AuthCheck::class,
    ],
    // api অ্যাপ্লিকেশনের মিডলওয়্যার
    'api' => [
         support\middleware\AccessControl::class,
     ],
    // admin অ্যাপ্লিকেশনের মিডলওয়্যার
    'admin' => [
         support\middleware\AdminAuthCheck::class,
         support\middleware\SomeOtherClass::class,
    ],
];

উপরের মিডলওয়্যার সমস্তই বিদ্যমান নাও হতে পারে, এটি কেবল বিভিন্ন অ্যাপ্লিকেশনের জন্য মিডলওয়্যার কনফিগার করার নির্দেশনার উদাহরণ।

মিডলওয়্যার কার্যকর করার ক্রম হলো গ্লোবাল মিডলওয়্যার->অ্যাপ্লিকেশন মিডলওয়্যার।

মিডলওয়্যার বিকাশের জন্য দেখুন মিডলওয়্যার অধ্যায়

বহু অ্যাপ্লিকেশন ত্রুটি হ্যান্ডলিং কনফিগারেশন

একইভাবে, আপনি বিভিন্ন অ্যাপ্লিকেশনগুলির জন্য ভিন্ন ভিন্ন ত্রুটি হ্যান্ডলিং ক্লাস কনফিগার করতে চান, যেমন shop অ্যাপ্লিকেশনে ত্রুটি ঘটলে আপনি একটি বন্ধুত্বপূর্ণ সতর্কতা পৃষ্ঠা প্রদান করতে চান; api অ্যাপ্লিকেশনে ত্রুটি ঘটলে আপনি একটি পৃষ্ঠা নয় বরং একটি json স্ট্রিং ফেরত দিতে চান। বিভিন্ন অ্যাপ্লিকেশনের জন্য ভিন্ন ভিন্ন ত্রুটি হ্যান্ডলিং ক্লাসের কনফিগারেশন ফাইলটি config/exception.php এর মতো হতে পারে:

return [
    'shop' => support\exception\Handler::class,
    'api' => support\exception\ApiHandler::class,
];

মিডলওয়্যার থেকে ভিন্ন, প্রতিটি অ্যাপ্লিকেশনের জন্য কেবল একটিমাত্র ত্রুটি হ্যান্ডলিং ক্লাস কনফিগার করা যাবে।

উপরের ত্রুটি হ্যান্ডলিং ক্লাসগুলি প্রাসঙ্গিক নাও হতে পারে, এটি কেবল বিভিন্ন অ্যাপ্লিকেশনের জন্য ত্রুটি হ্যান্ডলিং কনফিগার করার উদাহরণ।

ত্রুটি হ্যান্ডলিং বিকাশের জন্য দেখুন ত্রুটি হ্যান্ডলিং অধ্যায়