AppML မှတ်တမ်း

1999 ခုနှစ်တွင် Refsnes Data သည် AppML ၏ ပထမဆုံးဗားရှင်းကို တီထွင်ခဲ့သည်။

ထို့နောက်တွင်၊ AppML သည် ဝဘ်ဖောက်သည်နှင့် ဝဘ်ဆာဗာကြား HTTP တောင်းဆိုချက် ဆက်သွယ်မှုအပေါ် အခြေခံထားသည်။ နောက်ပိုင်းတွင် ဤနည်းလမ်းကို AJAX ဟုခေါ်သည်။

2000 ခုနှစ် စက်တင်ဘာလတွင် နော်ဝေဖောက်သည်ကြီးများအတွက် ဖွံ့ဖြိုးတိုးတက်ရေး ပရောဂျက်တစ်ခုကို စတင်ခဲ့သည်။ ပရောဂျက်၏ရည်ရွယ်ချက်မှာ ကြီးမားသောသတင်းအချက်အလက်စနစ် (အက်ပ်လီကေးရှင်း ၃၀၀ ခန့်) ကို Windows desktop အပလီကေးရှင်းမှ AppML ကိုသာအသုံးပြု၍ ခေတ်မီအင်တာနက်အပလီကေးရှင်းတစ်ခုသို့ပြောင်းလဲရန်ဖြစ်သည်။

AppML-based စနစ်သည် ကမ္ဘာ့ပထမဆုံး စီးပွားဖြစ် AJAX အပလီကေးရှင်းအဖြစ် သတ်မှတ်ချိန်မတိုင်မီ လအတော်ကြာ 2001 ခုနှစ်တွင် စတင်ခဲ့သည်။ ပရောဂျက်သည် သာမာန်ဝဘ်ဖွံ့ဖြိုးတိုးတက်မှုနှင့် နှိုင်းယှဉ်ပါက ဖွံ့ဖြိုးတိုးတက်မှုအချိန် 75% လျှော့ချခြင်းဖြင့် ကြီးမားသောအောင်မြင်မှုတစ်ခုဖြစ်သည်။ ထိုအချိန်မှစ၍၊ အပလီကေးရှင်းအသစ်များကို ထည့်သွင်းခဲ့ပြီး ယခုအခါ စနစ်သည် လည်ပတ်နေသော အက်ပ်ပေါင်း ၁၀၀၀ ကျော်ကို လွှမ်းခြုံထားသည်။

2015 ခုနှစ် ဖေဖော်ဝါရီလတွင်၊ W3Schools သည် အများပြည်သူအတွက် ဖွင့်ထားသော ထုတ်ကုန်အသစ်အဖြစ် AppML ကို ပြန်လည်စတင်ခဲ့သည်။

AppML ဒီဇိုင်းပန်းတိုင်များ

• AppML အပလီကေးရှင်းများသည် အင်တာနက်ပေါ်တွင် အလုပ်လုပ်ရပါမည်။
• AppML အပလီကေးရှင်းများသည် ပလပ်ဖောင်း သီးခြားဖြစ်ရမည်။
• AppML အပလီကေးရှင်းများသည် အင်တာနက်စံနှုန်းများကိုသာ အသုံးပြုရမည် (HTML၊ CSS၊ JavaScript)
• AppML အက်ပ်လီကေးရှင်းများသည် လျှောက်လွှာလိုအပ်ချက်အမျိုးမျိုးကို ပံ့ပိုးပေးရပါမည်။
• AppML အပလီကေးရှင်းများသည် ကိုယ်တိုင်ဖော်ပြရပါမည်။
• AppML အပလီကေးရှင်းများသည် ဖွံ့ဖြိုးတိုးတက်ရန်၊ ထိန်းသိမ်းရန်နှင့် ပြောင်းလဲရန် လွယ်ကူရပါမည်။
• AppML အပလီကေးရှင်းများသည် အနာဂတ် အထောက်အထားဖြစ်ရပါမည်။

အောက်ဖော်ပြပါစာပိုဒ်များသည် အနာဂတ်ဝဘ်အပလီကေးရှင်းများအကြောင်း Refsnes Data ၏မူလအမြင်များ (1999) ကိုဖော်ပြသည်။

အကောင်ထည်ဖော်နိုင်သူများ သေဆုံးလိမ့်မည်၊ JavaScript ရှင်သန်လိမ့်မည်။

Compiled executables (C သို့မဟုတ် Java ကဲ့သို့သော ဘာသာစကားများမှ စုစည်းထားသည်) သည် မတူညီသော ဟာ့ဒ်ဝဲပေါ်တွင် လုပ်ဆောင်၍မရပါ။

အကောင်ထည်ဖော်နိုင်သော အရာများ (EXE ဖိုင်များ၊ ActiveX နှင့် COM အရာဝတ္ထုများ၊ DLL-files) များသည် အင်တာနက်ပေါ်တွင် လည်ပတ်နိုင်သော အပလီကေးရှင်းများ ဖွံ့ဖြိုးတိုးတက်မှုကို ဟန့်တားသော အစိတ်အပိုင်းများဖြစ်သည်။

အနာဂတ်အပလီကေးရှင်းသည် ကလိုင်းယင့်၏ကွန်ပြူတာတွင် ထည့်သွင်းထားသော executables သို့မဟုတ် အခြားအစိတ်အပိုင်းများကို အသုံးပြုမည် သို့မဟုတ် အားကိုးမည်မဟုတ်ပါ။

ကျွန်ုပ်တို့၏အကြံပြုချက်များ-

HTML၊ CSS နှင့် JavaScript တို့ကိုသာ အသုံးပြု၍ သင်၏ အနာဂတ် အပလီကေးရှင်းများကို ရေးပါ။

သင်၏အနာဂတ်အက်ပ်လီကေးရှင်းများကို မည်သည့်ဝဘ်ဘရောက်ဇာတွင်မဆို လုပ်ဆောင်ကြောင်း သေချာပါစေ။

ဝဘ်အက်ပလီကေးရှင်းများသည် အင်တာနက်ဝန်ဆောင်မှုများ ဖြစ်လိမ့်မည်။

သမိုင်းသည် ကြီးမားသော၊ ရည်ရွယ်ချက်ဖြင့် တည်ဆောက်ထားသော အသုံးချမှုများနှင့် ပြည့်နေသည်။ ၎င်းတို့ထဲမှ အများအပြားသည် အလွန်လျင်မြန်စွာ သေဆုံးသွားကြပြီး လိုအပ်ချက်များ အပြောင်းအလဲများကို မရှင်သန်နိုင်ကြသောကြောင့် ဖြစ်သည်။

အပလီကေးရှင်းများသည် ပြောင်းလွယ်ပြင်လွယ်၊ ယေဘူယျအားဖြင့် ပြိုလဲခြင်း သို့မဟုတ် ပျက်စီးခြင်းမရှိဘဲ ပြောင်းလဲမှုများကို ချောမွေ့စွာ ချိန်ညှိသင့်သည်။

အပလီကေးရှင်းများသည် တစ်ရက်လျှင် တောင်းဆိုချက်အချို့ကို ပံ့ပိုးမှုမှ သန်းပေါင်းများစွာအထိ အတိုင်းအတာအထိ ဆောင်ရွက်နိုင်သင့်သည်။

အပလီကေးရှင်းများသည် ဆာဗာတစ်ခုမှ အများအပြားသို့ ပျံ့နှံ့နိုင်သည်၊ သို့မဟုတ် အပလီကေးရှင်းကို မချိုးဖျက်ဘဲ ဆာဗာများအကြား ရွှေ့ပြောင်းနိုင်သင့်သည်။

Application များသည် အခြားသော application များနှင့် ပူးပေါင်းဆောင်ရွက်နိုင်ရမည်။

အပလီကေးရှင်းများတွင် ကုဒ်အမြောက်အမြား မပါဝင်သင့်ပါ။

အပလီကေးရှင်းများကို ဖန်တီးရလွယ်ကူပြီး ထိန်းသိမ်းရလွယ်ကူသော ဝန်ဆောင်မှုငယ်များအဖြစ် ခွဲထုတ်သင့်သည်။

အပလီကေးရှင်းများသည် တင်သွင်းထားသော အင်တာနက်တောင်းဆိုမှုများထံ ဒေတာပြန်ပေးနိုင်သည့် အင်တာနက်ဝန်ဆောင်မှုအစုတစ်ခု ဖြစ်သင့်သည်။

အပလီကေးရှင်းများသည် ဆာဗာသို့ အမြဲတမ်းချိတ်ဆက်မှုမထိန်းသိမ်းဘဲ ပုံမှန်အင်တာနက်ပရိုတိုကောများမှတစ်ဆင့် ဝန်ဆောင်မှုများကို တောင်းဆိုသင့်သည်။ 

ကျွန်ုပ်တို့၏အကြံပြုချက်များ-

အင်တာနက်အခြေခံ SOA (Service Oriented Architecture) ကို အသုံးပြု၍ သင်၏အနာဂတ်အပလီကေးရှင်းများကို ရေးသားပါ။

သင်၏ အပလီကေးရှင်းဝန်ဆောင်မှုများကို ယေဘူယျနှင့် လိုက်လျောညီထွေဖြစ်စေပြီး မတူညီသော တောင်းဆိုမှုများကို ဆောင်ရွက်ပေးရန် အသင့်ဖြစ်ပါစေ။

အနာဂတ်အပလီကေးရှင်းများသည် ဖန်တီးရန်နှင့် တည်းဖြတ်ရန် လွယ်ကူပါလိမ့်မည်။

ဖောက်သည်များနှင့် ဆာဗာများသည် ဒေတာကို နားလည်လွယ်သောနည်းဖြင့် ဖလှယ်ကြမည်ဖြစ်သည်။

ရှောင်ရှားနိုင်လျှင် အပလီကေးရှင်းများကို ကုဒ်နံပါတ်တပ်မည်မဟုတ်ပါ။

အပလီကေးရှင်းများကို ကုဒ်တည်းဖြတ်ခြင်းဖြင့်မဟုတ်ဘဲ မော်ဒယ်များကို တည်းဖြတ်ခြင်းဖြင့် ဖန်တီးပြီး ပြုပြင်မည်ဖြစ်သည်။

အပလီကေးရှင်းဖော်ပြချက်များကို လူသားများက ဖတ်နိုင်မည်ဖြစ်သည်။

အပလီကေးရှင်းဖော်ပြချက်များသည် ကိုယ်တိုင်ဖော်ပြပါမည်။

အပလီကေးရှင်းများကို ပရိုဂရမ်မာများမဟုတ်ဘဲ အသုံးပြုသူများမှ ရေးသားမည်ဖြစ်သည်။

ကျွန်ုပ်တို့၏အကြံပြုချက်များ-

ဝန်ဆောင်မှုများကို ဖော်ပြရန်အတွက် လူသားဖတ်နိုင်သော စာသားဖိုင်များကို အသုံးပြုပြီး ဤဖော်ပြချက်များကို လုပ်ဆောင်ခြင်းဖြင့် ဝန်ဆောင်မှုများကို ပေးဆောင်ပါ။

အပလီကေးရှင်းများကိုဖော်ပြရန် စာသားဖိုင်များ (JSON ဖိုင်များကဲ့သို့) ကိုသုံးပါ။

ဒေတာဖလှယ်ရန် စာသားဖိုင်များ (JSON ဖိုင်များကဲ့သို့) ကို အသုံးပြုပါ။

အပလီကေးရှင်းများကိုလုပ်ဆောင်ရန် HTML၊ CSS နှင့် JavaScript ကိုသုံးပါ။

Web Developer သုံးယောက်...

တစ်ချိန်က ဝဘ်ဆိုဒ်အသစ်တစ်ခုကို တီထွင်ဖန်တီးသူ သုံးဦးရှိခဲ့သည်။

1. ပထမဆုံး ဝဘ်တီထွင်သူသည် AppML ကို အသုံးပြုခဲ့သည်။

2. ဒုတိယဝဘ်ဆော့ဖ်ဝဲရေးသားသူသည် ၎င်း၏အကြိုက်ဆုံး ဆာဗာပရိုဂရမ်းမင်းဘာသာစကားကို အသုံးပြုနေပါသည်။

3. တတိယအချက်မှာ ပရော်ဖက်ရှင်နယ် လုပ်ငန်းဝဘ်ဖွံ့ဖြိုးတိုးတက်မှု မူဘောင်ကို အသုံးပြုခြင်းဖြစ်သည်။

ပထမဆုံး ဝဘ်ဆော့ဖ်ဝဲရေးသားသူသည် နှစ်ရက်အတွင်း သရုပ်ပြမှုကို စတင်လုပ်ဆောင်ခဲ့သည်။ အသုံးပြုသူများနှင့် ပူးပေါင်းပြီးနောက် တစ်ပတ်အတွင်း ထွက်သည့် နမူနာပုံစံကို အဆင်သင့်ဖြစ်နေပါပြီ။ နှစ်ပတ်ကြာ စမ်းသပ်ပြီးနောက်၊ ဉာဏ်ရည်ထက်မြက်ပြီး အသုံးပြုရလွယ်ကူသော ဝဘ်ဆိုက်ကို ထုတ်ဝေရန် အဆင်သင့်ဖြစ်နေပါပြီ။

ဒုတိယဝဘ် developer သည် 6 လအကြာတွင်သူ၏ဝဘ်ဆိုက်အဆင်သင့်ဖြစ်ခဲ့သည်။ သို့သော် WWW သည် ၎င်း၏လိုအပ်ချက်များကို ပြောင်းလဲခဲ့ပြီး မကျေနပ်ခဲ့ပါ။ ဝဘ်ဆော့ဖ်ဝဲရေးသားသူသည် ၎င်း၏ပရောဂျက်အတွက် ကုဒ်များစွာပါရှိသောကြောင့် ကြီးကြီးမားမားပြောင်းလဲမှုများ မပြုလုပ်နိုင်ခဲ့ပါ။ ထို့ကြောင့် သူက ဗားရှင်း 2 ကို စတင်တီထွင်ခဲ့သည်။

တတိယဝဘ်ဆော့ဖ်ဝဲရေးသားသူသည် သူ့အလုပ်ကို ဘယ်သောအခါမှ ပြီးအောင်မစွမ်းဆောင်နိုင်ခဲ့ပါ။ ပရော်ဖက်ရှင်နယ် ဝဘ်ဖွံ့ဖြိုးတိုးတက်မှုမူဘောင်သည် အသုံးပြုရအလွန်ခက်ခဲသည်၊ နားလည်ရအလွန်ခက်ခဲပြီး စမ်းသပ်ရန်မဖြစ်နိုင်ပေ။

ပထမဆုံး developer က ဘယ်လို လုပ်ခဲ့တာလဲဆိုတာ ကြည့်ပါ ။