JSF Framework မှာ Request တစ်ခုဟာ Front End Controller ဖြစ်တဲ့ FacesController ဆီကို ရောက်ရှိလာပြီဆိုတာနဲ့ အဆင့်ဆင့် လုပ်ဆောင်သွားကြပါတယ်။ JSF Runtime ရဲ့ အလုပ်လုပ်ပုံဟာ View အမျိုးအစားအလိုက် အလုပ်လုပ်ပုံမတူညီကြပါဘူး။
JSF Runtime ဟာ Form ပါတဲ့ View တွေကို Restore လုပ်ဖို့လိုတဲ့ View လို့သတ်မှတ်ပြီး Form မပါရင်တော့ Restore လုပ်စရာမလိုဘူးလို့သတ်မှတ်ပါတယ်။ Restore လုပ်စရာမလိုတဲ့ View တွေနဲ့ Form ပါတဲ့ View ရဲ့ First Request တွေရောက်လာခဲ့ရင် JSF Runtime ဟာ View ထဲမှာပါတဲ့ UI Component တွေအလိုက် View Graph ကို တည်ဆောက်ပြီး Render Response Phase ကို ရောက်ရှိစေပါတယ်။
လက်ရှိ ပြနေတဲ့ Form ပါတဲ့ View ကနေ Command Button, Command Link ကနေ Action Method ကို အသုံးပြုပြီး Request ရောက်လာပြီဆိုရင်တော့ Restore View Phase ကနေ စတင်စေမှာ ဖြစ်ပါတယ်။
ဒီအဆင့်မှာတော့ Server ဒါမှမဟုတ် Client ဘက်မှာ သိမ်းထားတဲ့ View State ကို အသုံးပြုပြီး View Object ကို ပြန်လည်တည်ဆောက်မှာ ဖြစ်ပါတယ်။
Facelet View မှာ ရေးသားထားတဲ့အတိုင်း UI Component တွေနဲ့အတူ၊ သတ်မှတ်ရေးသားထားတဲ့ Converters, Validators နဲ့အတူ Event Handler တွေအားလုံးကို တည်ဆောက်ပြီး JSF Request Lifecycle တလျောက်မှာအသုံးပြုမည့် FecesContext Object ထဲမှာ သိမ်းသွားပေးပါတယ်။
View State တွေကို ဘယ်မှာ သိမ်းမလဲဆိုတာကို web.xml ရဲ့ context-param မှာ javax.faces.STATE_SAVING_METHOD နဲ့ သတ်မှတ်နိုင်ပါတယ်။
<context-param> <param-name>javax.faces.STATE_SAVING_METHOD</param-name> <param-value>client</param-value> </context-param>
အထက်ပါအတိုင်း Context Param Value ကို Client လို့ရေးသားထားရင်တော့ View State ကို HTML form ရဲ့ Hidden Parameter အနေနဲ့ Client Browser ပေါ်မှာ သိမ်းပေးသွားမှာ ဖြစ်ပါတယ်။
Server Side မှာ View State ကို သိမ်းဆည်းထားလိုပါက “server” လို့ သတ်မှတ်ရန်လိုပြီး၊ Server ပေါ်က HttpSession ပေါ်မှာ သိမ်းဆည်းသွားမှာ ဖြစ်ပါတယ်။ View State ရဲ့ Session ID ကိုတော့ HTML form ရဲ့ Hidden Parameter အနေနဲ့ Client Browser ပေါ်မှာ သိမ်းပေးသွားမှာ ဖြစ်ပါတယ်။
ViewHandler Class ရဲ့ restoreView() Method ဖြင့် အထက်ပါ လုပ်ဆောင်မှုတွေကို ဆောင်ရွက်သွားမှာ ဖြစ်ပါတယ်။
ဒီအဆင့်မှာတော့ User Input Value တွေကို အသုံးပြုပြီး View Graph ထဲမှာရှိတဲ့ သက်ဆိုင်ရာ UI Component တွေရဲ့ တန်ဖိုးကို Set လုပ်ပေးမှာ ဖြစ်ပါတယ်။ UIComponentBase Class ရဲ့ processDecodes() Method နဲ့ အထက်ပါလုပ်ဆောင်ချက်တွေကို လုပ်ဆောင်ပေးသွားမှာ ဖြစ်ပါတယ်။ UIComponent ရဲ့ Local Value တန်ဖိုးကို Request Parameter Value နဲ့ သတ်မှတ်ပေးမှာ ဖြစ်ပါတယ်။ ပုံမှန်အားဖြင့်တော့ Decode လုပ်ပြီးတာနဲ့ Process Validation Phase ကို ရောက်ရှိသွားမှာ ဖြစ်ပါတယ်။
တကယ်လို CommandButton တွေ၊ CommandLink တွေရဲ့ immediate တန်ဖိုးကို true လို့ သတ်မှတ်ထားရင်တော့ Event ကို Apply Request Value Phase မှာပဲ ဆောင်ရွက်သွားစေမှာ ဖြစ်ပါတယ်။ ဒီလိုအခါမျိုးတွေမှာ တစ်ခြား Phase တွေအားလုံးကို Skip လုပ်ပြီး Render Response Phase ကို ရောက်ရှိသွားစေမှာ ဖြစ်ပါတယ်။
User Input တွေကို မယူလိုပဲ လုပ်ဆောင်ချက်တွေကို ချက်ချင်းဆောင်ရွက်လိုတဲ့ အခါမျိုးတွေမှာ Immediate တန်ဖိုးကို True လို့သတ်မှတ်သင့်ပါတယ်။
ဒီအဆင့်မှာတော့ UI Input Component တွေရဲ့ Input Value တွေကို Validate လုပ်ပါတယ်။
Validate မလုပ်ခင် Model Value နဲ့ ကိုက်ညီအောင် အရင်ဆုံး Convert လုပ်ပါတယ်။ UI Input Component မှာသတ်မှတ်ထားတဲ့ Converter ဒါမှမဟုတ် Default Converter ကို အသုံးပြုပြီး Convert လုပ်ပါတယ်။ ပြီးမှ UI Input Component တွေမှာသတ်မှတ်ရေးသားထားတဲ့ Validator ကို အသုံးပြုပြီး Validate လုပ်ပါတယ်။
Convert လုပ်ရင်း Error တက်ခဲ့ရင် ဒါမှမဟုတ် Validation Rule နဲ့ စစ်ဆေးပြီး မှားနေခဲ့ရင် FacesMessage Object ကို တည်ဆောက်ပြီး FacesContext Object ထဲမှာ သိမ်းထားပါတယ်။ အကြောင်းတစ်ခုခုကြောင့် Error ရှိနေခဲ့ရင် Render Response Phase ကို ရောက်ရှိသွားပြီး၊ မှန်ကန်တယ်ဆိုရင်တော့ Update Model Phase ကို ရောက်ရှိသွားမှာ ဖြစ်ပါတယ်။
ဒီအဆင့်မှာတော့ UI Input Component တွေရဲ့ New Value တွေကို သူတို့နဲ့ Bind လုပ်ထားတဲ့ Model ရဲ့ setter Method တွေကို Invoke လုပ်ပြီး Set လုပ်မှာ ဖြစ်ပါတယ်။ JSF Runtime က View Graph ထဲမှာရှိတဲ့ UI Input Component တွေရဲ့ updateModel() Method ကို Invoke လုပ်ပြီးလုပ်ဆောင်စေမှာ ဖြစ်ပါတယ်။
ဒီအဆင့်ပြီးရင် Model ဖြစ်တဲ့ Backing Beans တွေရဲ့ တန်ဖိုးတွေဟာ User Input တန်ဖိုးတွေနဲ့ သတ်မှတ်ပြီးဖြစ်ပြီး၊ Invoke Application Phase ကို ရောက်ရှိသွားမှာ ဖြစ်ပါတယ်။
ဒီအဆင့်မှာတော့ Command Button, Command Link အစရှိတဲ့ UI Component တွေရဲ့ action attribute မှာ ရေးသားထားတဲ့ Backing Bean ရဲ့ Action Method ကို Invoke လုပ်မှာ ဖြစ်ပါတယ်။ Invoke Application Phase ကို ရောက်ပြီဆိုရင် Backing Bean ထဲမှာရှိတဲ့ Instance Variable တွေဟာလဲ User Input Value တွေနဲ့ Update လုပ်ပြီးဖြစ်နေပါပြီ။
တကယ်လို့ UI Command Component တွေမှာ ActionListener တွေကို သတ်မှတ်ရေးသားထားတယ် ဆိုရင် ActionListener တွေက အရင်အလုပ်လုပ်ပြီးမှ Action Method တွေကို အလုပ်လုပ်စေမှာ ဖြစ်ပါတယ်။
ActionListener တွေကိုတော့ Main Business Action မစခင် အကူအနေနဲ့ တစ်ခုခုလုပ်ဆောင်စေလိုတဲ့ အခါတွေမှာ အသုံးပြုရမှာဖြစ်ပြီး၊ Action Method တွေကိုတော့ Main Business Action တွေကို လုပ်ဆောင်စေလိုတဲ့အခါမှာ ရေးသားရမှာ ဖြစ်ပြီး Business Logic အလိုက် Database Operation တွေကိုလဲ လိုအပ်သလို လုပ်ဆောင်စေနိုင်မှာ ဖြစ်ပါတယ်။ EJB တွေကို Delegate လုပ်ပြီး Business Logic တွေကိုလဲ လုပ်ဆောင်နိုင်မှာ ဖြစ်ပါတယ်။
Action Method ကိုလုပ်ဆောင်နေရင်း Logical View Name ကို Return ပြန်တာပဲဖြစ်ဖြစ်၊ FacesConfig File ထဲမှာ ရေးသားထားတဲ့ Navigation တန်ဖိုးကို Return ပြန်တာပဲဖြစ်ဖြစ်၊ FacesContext ကနေ ExternalContext ကနေ redirect လုပ်လိုက်တဲ့ အခါမျိုးတွေမှာ Navigation ကို ဖြစ်ပေါ်စေနိုင်ပါတယ်။
Navigation ဖြစ်ပေါ်စေတဲ့အခါ ဒါမှမဟုတ် Action Method ရဲ့ လုပ်ဆောင်မှုတွေပြီးဆုံးတဲ့ အခါတွေမှာ Invoke Application Phase ကို ပြီးဆုံးစေပြီး Lifecycle ရဲ့ နောက်ဆုံးအဆင့်ဖြစ်တဲ့ Render Response Phase ကို ရောက်ရှိသွားမှာ ဖြစ်ပါတယ်။
JSF Lifecycle ရဲ့ နောက်ဆုံးအဆင့်ဖြစ်ပြီး View Object ကနေ HTML Response အဖြစ် ပြန်ပြောင်းပြီး Browser ဆီကို Response ပြန်ပေးရပါမယ်။
Entrance to This Phase
Render Response Phase ကို ရောက်ရှိလာနိုင်တဲ့ အခြေအနေ အမျိုးမျိုးရှိကြပါတယ်။
First Request
JSF View တွေမှာ Restore လုပ်ဖို့လိုတဲ့ View နဲ့ Restore လုပ်စရာမလိုတဲ့ View ဆိုပြီးရှိကြပါတယ်။ h:form Component တွေပါဝင်တဲ့ View တွေဟာ Restore လုပ်စရာလိုတဲ့ View တွေဖြစ်ပါတယ်။ Restore လုပ်စရာမလိုတဲ့ View တွေနဲ့ Form ပါတဲ့ View တွေရဲ့ ပထမဆုံးစပြတဲ့ Request တွေဆိုရင် JSF Runtime က View Graph အတိုင်း View Object တွေကိုတည်ဆောက်ပါတယ်။ UI Component မှာ Data Binding နဲ့ Model ထဲက တန်ဖိုးတွေနဲ့ Bind ထားတယ်ဆိုရင် Model Object ကိုလဲ သက်ဆိုင်ရာ Scope ထဲကနေ ရယူပြီး Reference လုပ်ထားပေးပါတယ်။ ပြီးတာနဲ့ ချက်ချင်း Render Response Phase ကို ရောက်ရှိစေပါတယ်။
Immediate Action
Command Button ဒါမှမဟုတ် Command Link တွေရဲ့ immediate attribute တန်ဖိုးမှာ true လို့ ပေးထားခဲ့ရင်လဲ Apply Request Values Phase မှာ ActionListener တွေ၊ Action Method တွေကို လုပ်ဆောင်စေပြီး၊ Render Response Phase ကို ရောက်ရှိလာမှာ ဖြစ်ပါတယ်။
Error Events
Restore View ကနေ Invoke Application အထိလုပ်ဆောင်ရာမှာ အကြောင်းတစ်ခုခုကြောင့် Error ဖြစ်ပြီး FacesMessage Object ကို FacesContext ထဲကို Queue လုပ်ခဲ့တယ်ဆိုရင်လဲ နောက်က Phase တွေကို ဆက်မလုပ်တော့ပဲ Render Response Phase ကို ရောက်ရှိစေပါတယ်။
Navigation in Action Method
Navigation ကိုဖြစ်ပေါ်စေတဲ့ အခါမှာလဲ Render Response Phase ကို ရောက်ရှိလာတတ်ပါတယ်။ ဒါပေမဲ့ Navigation လို့ပြောတဲ့ နေရာမှာ အနေအထားနှစ်မျိုးရှိနိုင်ပါတယ်။ ပထမတစ်မျိုးကတော့ Action Method ထဲမှာ Logical View Name ဒါမှမဟုတ် FacesConfig ထဲမှာ ရေးသားထားတဲ့ Navigation Name တစ်ခုခုကို Return ပြန်မိတဲ့ အခါမျိုးဖြစ်ပါတယ်။ ဒါကတော့ Request Scope တစ်ခုထဲမှာပဲ ရှိနေမှာ ဖြစ်ပါတယ်။ နောက်တစ်မျိုးကတော့ Redirect လုပ်မိတဲ့ အခါဖြစ်ပါတယ်။ အဲ့ဒါကတော့ Action Method ရဲ့ Return Value ရဲ့ နောက်မှာ “send-redirect=true” လို့ ရေးမိတဲ့အခါမှာလဲ ဖြစ်နိုင်သလို၊ FacesContext ရဲ့ ExternalContext ရဲ့ redirect() Method ကို Invoke လုပ်ပြီးလဲ Navigation ကို ဖြစ်ပေါ်စေနိုင်ပါတယ်။ Redirect လုပ်တဲ့အခါမှာ Browser ဆီကို Response ပြန်သွားပြီးမှ ချက်ချင်းပဲ သတ်မှတ်ထားတဲ့ View အတွက် နောက်ထပ် Request အသစ်တစ်ခုအနေနဲ့ ရောက်ရှိလာမှာ ဖြစ်ပါတယ်။ Navigation ကြောင့် Render Response Phase ကို ရောက်လာတဲ့ အခါမှာ Navigate လုပ်ရမည့် View Object အတွက် Lifecycle တစ်ခုကို စတင်စေပါတယ်။
End of Phases
Invoke Application Phase ရဲ့ Action Method ကို ခေါ်ဆိုပြီး Navigation တွေမဖြစ်တဲ့ အခါမှာလဲ Render Response Phase ကို ရောက်ရှိလာမှာဖြစ်ပါတယ်။
Encoding
ဘယ်လိုနည်းနဲ့ပဲဖြစ်ဖြစ် Render Response Phase ကို ရောက်လာပြီဆိုရင်တော့ Response ပြန်ဖို့အတွက် View Object ဟာရှိပြီးဖြစ်နေသလို အသုံးပြုနေတဲ့ Model Object တွေဟာလဲ တည်ဆောက်ပြီး ဖြစ်နေပါတယ်။ အဲ့ဒီ View Object ကို အသုံးပြုပြီး Response ပြန်ရမည့် HTML ကို တည်ဆောက်ရပါတယ်။ View Object ကနေ HTML Response ကို တည်ဆောက်တာကို Encoding လုပ်တယ်လို့ ခေါ်ဆိုပြီး View Root ရဲ့ View Graph ကနေ ရှိသမျှ UI Component တွေရဲ့ encode() Method ကို Invoke လုပ်ပြီး လုပ်ဆောင်ပေးမှာ ဖြစ်ပါတယ်။ ဒီနေရာမှာလဲ UI Component တွေမှာ Converter တွေရှိသလား၊ ဒါမှမဟုတ် Convert လုပ်ဖို့လိုသလားဆိုတာကို ကြည့်ပြီး အလုပ်လုပ်ပါတယ်။ Converter တွေ သတ်မှတ်ထားတယ်ဆိုရင်တော့ Converter ရဲ့ getAsString() Method ကို အသုံးပြုပြီး Encode လုပ်မှာ ဖြစ်ပြီး၊ Converter မရှိရင်တော့ Object ရဲ့ toString() Method ကို အသုံးပြုပြီး Encode လုပ်သွားမှာ ဖြစ်ပါတယ်။
Saving View States
Render Response Phase ဟာ JSF Request Lifecycle ထဲမှာ နောက်ဆုံးအဆင့်ဖြစ်ပါတယ်။ တကယ်လို့ ရောက်လာတဲ့ View Object ဟာ Restore လုပ်ဖို့လိုအပ်တဲ့ View ဆိုရင်တော့ ဒီနေရာမှာ View State ကို သိမ်းသွားမှာဖြစ်ပါတယ်။ View State တွေကို ဘယ်မှာ သိမ်းမလဲ ဆိုတာကတော့ Web XML ရဲ့ Context Parameter ထဲမှာ သတ်မှတ်ထားတဲ့ အတိုင်း သိမ်းပေးသွားမှာ ဖြစ်ပါတယ်။ တကယ်လို့ သတ်မှတ်ထားခြင်း မရှိရင်တော့ Server Side မှာပဲ HTTP Session ကို အသုံးပြုပြီး သိမ်းပေးသွားမှာ ဖြစ်ပါတယ်။
No comments:
Post a Comment