Before you start your own framework

အခုတလော ရုံးမှာ framework ပြဿနာ တော်တော်လေး ရှုပ်သွားတယ်။ အဲဒီတော့ ကိုယ်ပိုင် framework တစ်ခု တည်ဆောက်ခြင်းရဲ့ ကောင်းခြင်း မကောင်းခြင်းတွေတော့ သဘောပေါက်သွားတာပေါ့။ framework တစ်ခု တည်ဆောက်တော့မယ်ဆိုရင် အခုနောက်ပိုင်းကတော့ MVC pattern နဲ့ ပဲ တည်ဆောက်ကြပါတယ်။ MVC Pattern အတွက် တစ်ယောက်နဲ့ တစ်ယောက် approve မတူကြဘူးဗျ။ ကျွန်တော်ကတော့ Symfony နဲ့ CI ပဲ သုံးဖူးတော့ သူတို့ ၂ ခု မတူညီတာကို သိတယ်။ ROR ကတော့ မေ့သွားပြီလို့ ဆိုလို့ရမယ်။ ROR ကို ခဏလောက်ပဲ လုပ်ဖူးတယ်။ နောက်ပိုင်း စာအုပ်က version နဲ့ ထွက်တဲ့ version မတူတာနဲ့ ရှေ့မဆက်ဖြစ်တော့တာ အခုထက်ထိပဲ။ အဲ… လွဲကုန်အုံးမယ်

Framework လုပ်တော့မယ်ဆိုရင်တော့ MVC အပြင် SEO user friendly ဖြစ်ဖို့အတွက်လည်း စဉ်းစားဖို့လိုပါတယ်။ ကျွန်တော်ကတော့ CI ရဲ့ approve ကို သဘောကျပါတယ်။

http://www.domain.com/index.php/controller/action

အဲဒီ ပုံစံနဲ့သွားပါတယ်။ index.php နောက်က controller လာတယ်။ ပြီးတော့ action လာတယ်ပေါ့။ Symfony မှာဆိုရင်တော့

http://domain.com/controller.php/action

သူကတော့ index.php နဲ့ မဟုတ်တော့ဘူး။ သို့ပေမယ့် အတူတူပါပဲ။ Controller လာတယ်။ action လာတယ်ပေါ့။

ပုံမှန် သမာရိုးကျ MVC pattern တွေက Model ကနေ ဖြစ်စေ Controller က ဖြစ်စေ View ကို ခေါ်ကြပါတယ်။ နောက်ပြီး View က View ပါ။ Designer တစ်ယောက်အတွက် လွယ်လွယ်ကူကူ ပြုပြင်နိုင်ရပါမယ်။ အချို့ framework စတင်ဆောက်တဲ့ သူတွေဟာ View ကို OO တွေနဲ့ တည်ဆောက်ပြီး ခေါ်ယူသုံးစွဲရတာလေးတွေ ဖြစ်တတ်ပါတယ်။ CI ကော Symfony မှာကော View က View အနေနဲ့ပဲ တည်ရှိတာပါ။ View တစ်ခုကို ဆောက်ဖို့ ဘာမှထွေထွေထူးထူးမလိုပါ။ အချို့ framework တွေကတော့ template system တွေကို သုံးကြပါတယ်။

View ကို OO နဲ့ ရောတယ်ဆိုတာက view ဆိုတာကြီးက class ဖြစ်ပြီး function တွေနဲ့ Model တို့ Controller တို့လို ဖြစ်ကုန်တာပါ။ ဥပမာ header ခေါ်မယ်ဆိုရင် ViewClass::header(); ဆိုပြီး ဖြစ်ကုန်တာမျိုးပေါ့။ CI မှာဆိုရင်တော့ view ကို class အနေနဲ့ တည်ရှိတာမဟုတ်ပဲ လွယ်လွယ်ကူကူ ခေါ်လို့ရပါတယ်။ $this->load->view(“view_file.php”,$data_array); ဆိုပြီး ခေါ်လိုက်ပါတယ်။ တနည်းပြောရင် view က file အနေနဲ့ပဲ တည်ရှိတယ်။ သူက သီးသန့် ဖန်တီးဖို့ လိုတဲ့ class ကြီးမဟုတ်ဘူးပေါ့ဗျာ။ ဘာလို့လည်းဆိုတော့ designer က view အပိုင်းမှာ ပြင်မှာတွေ ထည့်တာတွေ လုပ်မှာမို့ပါ။ တကယ်လို့ Class ကြီးသာ ဖြစ်နေရင် Designer အနေနဲ့ ပြင်ရခက်ပြီလေ။ သူက coding တွေ looping တွေကို အဲလောက်ထိ သိတဲ့ သူတွေမှ မဟုတ်တာ။ Web Design ကိုသာ professional တတ်ကျွမ်းကြတာလေ။

ကျွန်တော်တို့ Framework ဆောက်မယ်ဆိုရင် .htaccess ကို စဉ်းစားဖို့လိုပါတယ်။ ကျွန်တော့် API work မှာကတော့ အောက်ကလို .htaccess ကို သုံးပါတယ်။
[lang name=”shell”]
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?r=$1 [L,QSA]
[/lang]

အဲဒီမှာ ကျွန်တော်ရေးထားတာက ရောက်လာတဲ့ URL က လက်ရှိ ရှိနေတဲ့ file မဟုတ်ခဲ့ရင် ဒါမှမဟုတ် လက်ရှိ ရှိနေတဲ့ directory မဟုတ်ခဲ့ရင် index.php?r= ဆိုပြီး လွှဲလိုက်တာပေါ့။

ဥပမာ။။

http://www.mydomain.com/sample/test

ဆိုရင်

မြင်ရတော့ http://www.mydomain.com/sample/test ဖြစ်ပေမယ့် လက်တွေ့ အလုပ်လုပ်သွားတာကတော့ http://www.mydomain.com/index.php?rt=sample/text ပါ။ ဒါကြောင့် index.php ကနေ $_GET[‘r’] နဲ့ လှမ်းဖတ်။ ပြီးတော့ / နဲ့ ပိုင်းပြီး ပထမဆုံးက controller , ဒုတိယက action ဆိုပြီး ခွဲလိုက်လို့ရပါတယ်။ အဲဒါက  apache မှာ mod_rewrite ရှိနေလို့ပါ။ apache မှာ mod_rewrite မရှိဘူး သို့မဟုတ် IIS server မှာဆို ဘယ်လိုလုပ်မလဲ။ ကိုယ့် framework က IIS server နဲ့ ဆိုသုံးမရတော့ဘူးလား ဆိုပြီး စဉ်းစားဖို့ ဖြစ်လာပါတယ်။ ရပါတယ်။ idea လေးကို နည်းနည်းလေး ပြောင်းလိုက်တာပေါ့။

http://www.mydomain.com/index.php/sample/test

ဆိုပြီး ကျွန်တော်တို့တွေ url ကို ပြောင်းလိုက်တယ်။ PHP နဲ့ $_SERVER[‘REQUEST_URI’] ကနေ address ကို လှမ်းဖတ်ပြီး index.php နောက်က ဟာတွေကို ဆွဲထုတ်လိုက်ပါတယ်။ ပြီးတော့ ထုံးစံအတိုင်း controller နဲ့ action ကို ခွဲလိုက်တာပေါ့။

တကယ်တန်းတော့ htaccess file တစ်ခုတည်းနဲ့ url ကို ပြောင်းလို့ရပေမယ့် အချို့တွေက .htacces file မှာ url တစ်ခုခြင်းဆီ ထည့်တာတွေ ရှိတတ်ပါတယ်။ ဘယ်လိုမျိုးလဲဆိုတော့ ဒီ url လာရင် ဒီ file ကိုသွားဆိုပြီးတော့။ SEO URL friendly တော့ ဖြစ်ပေမယ့် ရေရှည်အတွက်ကတော့ မကောင်းဘူးပေါ့။ နောက်ပြီး url ကနေ controller နဲ့ action ကို ရပြီးတဲ့နောက်မှာ ဘာပြဿနာလဲဆိုတော့ controller နဲ့ action ကို ခေါ်တဲ့ ပြဿနာပါ။ ပုံမှန်အားဖြင့် PHP မှာ class ကို variable နဲ့ ခေါ်လို့ရပါတယ်။ အဲဒါကို မသိတဲ့အခါမှာ controller တွေ action ကို switch case နဲ့ စစ်ပြီး တစ်ခုခြင်းဆီ ခေါ်ပါတယ်။ အဲဒီတော့ ခုနက htaccess file လို ပြဿနာပဲ ထပ်ကြုံရမှာပေါ့။

ဟုတ်ပြီ။ htaccess ကတော့ ရပြီ။ အဲဒီမှာ နောက်ထပ် ပြဿနာတစ်ခု ထပ်ကြုံရမယ်။ ဒါပေမယ့် တော်တော်များများ ဂရုမထားမိကြဘူး။

[lang name=”shell”]RewriteCond %{REQUEST_FILENAME} !-d[/lang]

ဆိုတဲ့ အကြောင်းကြောင့်ပါ။ အဲဒါက directory မဟုတ်ခဲ့ရင်လို့ပြောထားတာပါ။ ဥပမာ။ web_folder ဆိုတဲ့ folder အောက်က file တွေကို www.domain.com/web_folder/default.css ဆိုပြီး ခေါ်လို့ရအောင်ပေါ့။ အဲဒါ ဘာပြဿနာ ဖြစ်လဲလို့ မေးစရာ ဖြစ်လာတယ်။ ဟုတ် ပြဿနာပါ။ framework တည်ဆောက်တဲ့အခါမှာ file တွေ အများကြီးအပြင် folder တွေပါ များလာတယ်။ include , system, library, application စသည်ဖြင့် folder တွေ များလာတယ်။ အဲဒီ folder တွေ အားလုံးက www.domain.com အောက်မှာပဲ ရှိတယ်။ ဒီတော့ www.domain.com/include/ ဆိုပြီး ခေါ်လို့ရပါတယ်။ အဲဒီတော့ ဘာဖြစ်လဲ။ index.html နဲ့ ထည့်ပြီး ပိတ်ထားမှာပေါ့လို့ပြော ပါလိမ့်မယ်။ ဟုတ်ပါတယ်။ index.html ထည့်ရပါမယ်။ သို့ပေမယ့် အဲလို folder တွေ များသွားတော့ သင့် Controller က အကန့်အသတ် တွေဖြစ်သွားလိမ့်မယ်။

ကိုယ့် framework က www.domain.com/include/myaction ဆိုပြီးခေါ်လို့မရတော့ဘူး။ ဘာလို့လည်း include ဆိုတဲ့ folder ရှိနေတယ်လေ။ အဲဒီလို ပြဿနာကို ဖြေရှင်းဖို့အတွက် CI နည်းက တော်တော်ကောင်းပါတယ်။ framework နဲ့ ဆိုင်တာ အကုန်လုံးကို system ဆိုတဲ့ folder အောက်မှာ ထည့်လိုက်တယ်။ အဲဒီတော့ index.php နဲ့ system folder ပဲ domain.com အောက်မှာ ရှိတော့တယ်လေ။ system ဆိုတဲ့ controller name ကလွဲလို့ ကြိုက်တဲ့ controller နာမည်ပေးလို့ရပြီလေ။

PHP မှာ လူသုံးနည်းပြီး ကောင်းတဲ့ feature တစ်ခုက variable က data ကို action အနေနဲ့ ခေါ်လို့ရတာပဲ။ အောက်က code လေးကို ကြည့်ုလိုက်ပါ။

[lang name=”php”]

$controller=”sampleController”;

$action = “action”;

$c=new $controller();

$c->$action();

[/lang]

အဲဒီ code ကို ကြည့်လိုက်ပါ။ ကျွန်တော် class နဲ့ action ကို variable နဲ့ dynamic ခေါ်ထားတာပါ။ အများအားဖြင့် အဲလို dynamic ခေါ်လို့ရတယ်ဆိုတာ သိပ်မသိကြဘူး။ အဲဒီအတွက်ကြောင့် framework ရေးတဲ့အခါမှာ controller  နဲ့ action ကို condition တွေနဲ့ စစ်ပြီး သီးသန့်စီ ခေါ်ထုတ်တာတွေ ဖြစ်ကုန်ပါတယ်။ ကျွန်တော်လည်း ကိုယ်ပိုင် framework ရေးရင်း ပြုပြင်ရင်း နဲ့ ဒီလို အကြောင်းအရာလေးတွေ ကို သိလာတာပါ။ CI သို့မဟုတ် အခြား framework တစ်ခုခုကို လေ့လာပြီးပြီ။ သုံးလည်း သုံးတတ်နေပြီ။ ကိုယ်ပိုင် framework စရေးတော့မယ်ဆိုရင် မစခင် အဲဒါလေးတွေ သိထားခြင်းအားဖြင့် ကိုယ်ပိုင် framework ရေးတဲ့ အခါမှာ အထောက်အကူဖြစ်မယ်လို့ထင်ပါတယ်။ ဒီ post ကတော့ ကျွန်တော့် အတွေ့အကြုံအရ ရေးထားတာပါ။ အခြားလူတွေနဲ့ idea တူချင်မှ တူပါလိမ့်မယ်။ ကျွန်တော်က CI သမားဖြစ်တော့ idea တွေက CI ကနေ ဆင်းသက်လာတယ်ဆိုတာ မငြင်းပါဘူး။ အခြား idea များကို ဆွေးနွေးချင်တယ်ဆိုရင်လည်း comment မှာ ဝင်ပြီးဆွေးနွေးလို့ရပါတယ်ဗျာ။

5 Comments

  1. Zack says:

    Cool! I also don’t know it.

    $controller=”sampleController”;
    $action = “action”;
    $c=new $controller();
    $c->$action();

    1. saturngod says:

      yes, I also didn’t know. I read from CI framework :P

  2. ahkeno says:

    မှတ်သားစရာပါပဲ။ အမကတော့ CI ကိုပဲလေ့လာပြီး CI နဲပဲစမ်းရေးကြည့်နေတဲ့အတွက် တခြားဟာတွေနဲ့တော့ မနှိုင်းရှင်တော့ပါဘူး။ CI ကြီး သီးသန့်အနေနဲ့ပြောရမယ်ဆိုရင် တည်ဆောက်ပုံစနစ်ကျတယ်။ View ဆိုတာနဲ့ User Interface အပိုင်း Controller ဆိုတာနဲ့ events တွေအပိုင်း Model ဆိုတာနဲ့ Database connect အပိုင်းမှန်းရှင်းရှင်းလင်းလင်းသိနိုင်လို့ error တခုတတ်တာနဲ့ ဘယ်အပိုင်းကိုပြင်ရမလဲပါ သိနိုင်တယ်။ နောက်ပြီး CI ကိုJquery/Ajax တိုနဲ့တွဲပြီး အသုံးပြုလို့ရတာကိုလည်း သဘောကျတယ်။ ရိုးရိုးရှင်းရှင်းနဲ့ view မှာပဲသွားတန်းရေးနိုင်တယ်။ Wp/Joomla တို့မှာ ရေးလို့ရမရတော့ အမလည်းမသိဘူး။ဒါပေမဲ့ သူတို့က Framework မဟုတ်တဲ့အတွက် သူ့ပေးထားတဲ့ဘောင်ထဲကနေပဲအသုံးပြုနိုင်မှာပါ။ဘာပဲပြောပြော ခုထိတော့ CI ကိုချစ်တုန်း သေချာပိုင်နိုင်တဲ့တနေ့ကျရင် ကိုယ်ပိုင် framework တခုလောက်တော့ဆောက်ကြည့်မယ်။

    1. Zack says:

      CI က Joomla ထက် MVC pattern ရေ့ရတာ လွယ်ကူတာ လက်ခံတယ်။
      ဒီနေရာလေးကိုပြောချင်ပါတယ်။ တကယ်တမ်း ပြောမယ်ဆို Joomla လည်း Framework
      တွေလိုပဲ အသင့်သုံး library တွေ၊ helper တွေ၊ template engine တွေပါ
      ပါတယ်။ Joomla Framework လိုတောင် ပြောလို့ ရနိုင်ပါတယ်။ ဒါကြောင့် CMS
      ဘောင်ကိုကျော်လွန်းပြီး လုပ်ထားတဲ့ social network extension, sopping-cart
      extension, facebook extension စတဲ့တဲ့ extension တွေကို အဲဒီ library
      တွေ၊ helper တွေပေါ်မှာ တည်ဆောက်ခဲ့တာပါ။ ဒါကြောင့် သူလည်း Framework
      တွေကဲသို့ စွမ်းဆောင်ရည် ရှိတယ်လို့ ပြောချင်ပါတယ်။ ဒါဆို ပြောစရာတစ်ခု ရှိတယ်ဗျ။
      ဒါလိုဘာလို့ Framework တွေကို သုံးလဲ ဆိုတာပေါ့။ ဒါကတော့ အမျိုးမျိုးတော့
      technical point of view တွေရှိနေပါတယ်။ တစ်ခုကတော့ လူတွေရဲ့ psycho ပဲပေါ့ဗျာ။ ကြက်သားဟင်း စားကောင်းလို့ တစ်သက်လုံးစားနေသူက မရှိဘူးလေ။ လုပ်ငန်းလိုအပ်ချက်ပေါ် မူတည်ပြီး သုံးကြရတာလည်း
      ရှိတာပေါ့။ :)

  3. wayne says:

    Good jyoot byoot

    နားတော့မလယ်ဘူးဝင်ဖတ်သွားတယ်

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.