مواد
مجھ سے پوچھیں کہ کون سا فریم ورک استعمال کرنا ہے اور میرے پاس لمحہ فکریہ بوڑھی عورت ہوگی اور آپ کو بتاؤں کہ سارے فریم ورک ایک دوسرے کی طرح خراب ہیں۔ جس کا مطلب بولوں میں یہ نہیں کہ وہ سب خراب ہیں ، بالکل ، لیکن پی ایچ پی میں ہمارے پاس ناقابل تصور بڑی تعداد میں فریم ورک (عام طور پر N + 1 کے حوالے سے بتایا جاتا ہے ، جہاں N دنیا میں پی ایچ پی ڈویلپرز کی تعداد ہے) ، اور ان سب کو شاید سمجھ میں آگیا اس شخص کو جس نے ایجاد کیا ہے۔
فریم ورک کا انتخاب کرنا صرف ایک فریم ورک کو استعمال کرنے کی کوشش سے کہیں بہتر ہے ، قطع نظر اس سے قطع نظر کہ آپ جو کچھ بھی تعمیر کرنے کی کوشش کر رہے ہیں ، کیوں کہ یہ ’بہترین‘ ایک ہے (جس طرح سے بھی ’’ بہترین ‘‘ ہے)۔ فریم ورک کی پیش کشوں کے اس انتخاب کا مطلب یہ ہے کہ آپ اس منصوبے کی ضروریات کو پورا کرنے والی کوئی چیز چن سکتے ہیں اور اس کی دستاویزات بھی کی جاسکتی ہیں۔ کسی بھی پلیٹ فارم کے فریم ورکس واقعی ڈھانچے ، دوبارہ استعمال کے قابل ماڈیولز اور لائبریریوں کی فراہمی کے لئے موجود ہیں ، اور عام طور پر تمام بورنگ اور تکرار کرنے والے کاموں سے اجتناب کرتے ہیں جن سے بار بار کام کرنا ہوتا ہے۔ مثال کے طور پر جب CMSes تعمیر کرتے ہو تو ، کچھ میرے لئے فارم فیلڈز پر کارروائی اور توثیق کرے۔ اگر میرے اپنے آلات پر چھوڑ دیا جاتا ہے تو میں شاید کسی اہم چیز سے محروم ہوجاتا ہوں اور میں اس کے بجائے ہر پروجیکٹ کے عناصر کو کرنا چاہتا ہوں مختلف، بجائے ان کے جو ہر وقت ایک جیسے ہوتے ہیں!
مکمل اسٹیک فریم ورک
پورے اسٹیک فریم ورک ، جیسے زینڈ فریم ورک ، بہت زیادہ فن تعمیر کے تجربے کے بغیر کسی ڈویلپر کے لئے شروع کرنے کے لئے ایک اچھی جگہ ہوسکتی ہے۔ یہ نئی ایپلی کیشن کو معلق کرنے کے ل good اچھی ڈھانچہ فراہم کرتا ہے ، اور اس کے آس پاس ایک اچھا ’ماحولیاتی نظام‘ ہے - کافی تعداد میں کتابیں ، سبق آموز دستاویزات ، اور کچھ معقول دستاویزات بھی۔ اگر آپ ایک بڑی ایپلی کیشن بنانے کی کوشش کر رہے ہیں جو بہت سارے لوگوں کے ذریعہ برقرار رہے گا ، تو پھر ممکن ہے کہ ایک مشہور ، جامع فریم ورک ایک اچھا انتخاب ہوگا کیونکہ یہ بہت سارے ڈھانچے کو تحویل دے گا اور معروف اور سمجھا جائے گا۔
علیحدگی میں مدد کے لئے ڈھانچہ ہونا ہمیشہ اچھا ہے؛ اپنے کیریئر کے شروع میں ہی میں نے کچھ کے ساتھ کام کیا بہت جونیئر ڈویلپرز اور انہیں ایم وی سی (ماڈل ویو کنٹرولر) پیٹرن سکھانے کی کوشش کی ، جو اس وقت نسبتا new نیا تھا۔ ہم نے اسمارٹی کو ویو لیئر میں استعمال کرنے کا فیصلہ کیا۔ جزوی طور پر تاکہ ڈیزائنرز ٹیمپلیٹس کے ساتھ زیادہ آسانی سے کام کرسکیں ، اور جزوی طور پر تاکہ جب کوئی میری میز پر آئے اور کہا کہ "میں اسمارٹی کے ساتھ ایکس کیسے کروں؟" میں "نقطہ نظر میں X ایسا نہ کرو!" کہہ سکتا ہوں۔ (10 میں سے نو بار ، اس کا جواب تھا)۔ فریم ورک رکھنے سے ہماری درخواست کے دوسرے حصوں میں بھی یہی علیحدگی تلاش کرنے میں مدد ملتی ہے۔ ان میں سے بہت سے اسمارٹی ، یا میرا نیا پسندیدہ ، ٹوئیگ جیسی فصاحت بخش پرت کے خلاف یکجا ہونے کی حمایت کرتے ہیں ، لہذا آپ ان اوزاروں کو اپنے ساتھ جو بھی فریم ورک منتخب کرتے ہیں ، لے جا سکتے ہیں۔
بوجھ ہلکا کریں
زینڈ فریم ورک سے کہیں زیادہ لائٹر فریم ورک موجود ہیں ، مثال کے طور پر میں CodeIgniter کے ساتھ تھوڑا سا کام کرتا ہوں۔ کیا یہ اتنا ہی جامع اور مضبوط ہے جتنا زینڈ فریم ورک؟ نہیں ، ایسا نہیں ہے۔ لیکن ایک مددگار فریم ورک کی حیثیت سے کسی درخواست کو تیزی سے تعمیر کرنے کے قابل بنانا ، یہ کارآمد ہے۔ عام طور پر ، کم ’مددگار‘ کی فعالیت کے حامل فریم ورکس کو اپنے آس پاس کا راستہ تلاش کرنا آسان ہوسکتا ہے کیونکہ یہ زیادہ واضح ہوتا ہے کہ ٹکڑے ٹکڑے کیسے اکٹھے ہوتے ہیں۔ کسی مانوس فریم ورک میں (میرے نزدیک ، یہ سب کچھ بہت زیادہ ہے) ، یہ وہ آٹومیجیکل بٹس ہے جس کے ساتھ کام کرنا اور ڈیبگ کرنا مشکل بنا دیتا ہے۔
"نئے فریم ورک میں کھو جانے" کا یہ احساس ناگزیر اور سراسر مایوس کن ہے۔ حتی کہ ایک تجربہ کار ڈویلپر بھی نوبائ کی طرح محسوس ہوتا ہے جب وہ نہیں جانتے ہیں کہ کچھ بھی کیسے کام کرتا ہے۔ اگر آپ واقعی بدقسمت ہیں تو ، آپ نے ایک ایسا فریم ورک چن لیا ہے جس کا IRC چینل آپ کو بتائے گا کہ آپ بھی بیوقوف ہیں! یہ ایک بہت ہی منفی ابتدائی تجربہ ہے جس نے بہت سارے لوگوں کو ایک نئے فریم ورک کا استعمال کرتے ہوئے یا کسی کو پہلے مقام پر اپنانے سے روک دیا ہے ، اور ابتدائی رکاوٹوں سے بہت کم فریم ورک نئے صارفین کی مدد کرنے کا ایک اچھا کام کرتے ہیں۔
پی ایچ پی میں ہمارے پاس بھی کچھ فریم ورک ہوتے ہیں جو واقعی فریم ورک نہیں ہوتے ہیں جس طرح میں عام طور پر لفظ استعمال کرتا ہوں۔ ہمارے پاس کچھ خوبصورت جزو فریم ورک ہیں۔ لائبریریوں کے مجموعے جو مرضی استعمال ہونے کے لئے بنائے گئے ہیں اور اچھی طرح سے مل کر کھیلنے کے ل، ، جیسے زیٹا اجزاء (پہلے ای زیڈ اجزاء) اور سیمفونی اجزاء (کیا آپ نے ان کی سائٹ دیکھی ہے؟ وہ بہترین آرٹ ورک کا ایوارڈ جیت چکے ہیں!)۔ ان میں سب سے عمدہ اور سب سے اہم انکشاف یقینا PH پی ایچ پی کی اپنی پیئر اور پی ای سی ایل کی پیش کش ہے - کسی طرح یہ فریم ورک کی اس بہادر نئی دنیا میں بھول جاتی ہے۔
مائکرو فریم ورکس
مائیکرو فریم ورک پی ایچ پی میں ایک ابھرتا ہوا رجحان ہے۔ یہ انتہائی ہلکے وزن کی پیش کش ہیں جو چیزوں کو زیادہ تیزی سے چپکنے میں آپ کی مدد کرتی ہیں۔ اس کی ایک عمدہ مثال سلم ہے ، جو استعمال کرنے میں بہت تیز اور آسان ہے ، اور آرام دہ تصورات کو سمجھتی ہے۔ یہ ’راستوں‘ کے خیال کے گرد مبنی ہے ، جو یو آر ایل کے نمونے ہیں۔ آپ کوئی راستہ اندراج کرتے ہیں اور ایک کال بیک دیتے ہیں جس میں جب یو آر ایل کی درخواست کی جاتی ہے تو اس کو طلب کرنا چاہئے۔
زیادہ تر پی ایچ پی ڈویلپرز ایک فریم ورک اپناتے ہیں اور اس کے ساتھ قائم رہتے ہیں ، یا پھر وہ اپنے شوق یا اوپن سورس پروجیکٹس کے لئے ایک کام پر اور دوسرا استعمال کرسکتے ہیں۔ استعمال کرنے کے لئے "بہترین" فریم ورک کے بارے میں تھوڑا سا اتفاق رائے نہیں ہے لہذا ہر شخص اپنی جانکاری پر قائم رہتا ہے اور اس کا نتیجہ فریم ورک کی بڑی تعداد میں متوازی ترقی کا ہوتا ہے! مجھے انتخاب کرنے کا انتخاب کرنا پسند ہے ، لیکن کیا میں نے یہ بتایا کہ وہ سب ایک دوسرے کی طرح خراب ہیں۔
اگر آپ زینڈ فریم ورک کو جانتے ہیں تو آپ اپنے آپ کو زینڈ فریم ورک ڈویلپر کے طور پر بیان کرنا ختم کردیتے ہیں۔ آپ کو دوسرے فریم ورک میں لکھنے میں آسانی نہیں ہوگی جب تک کہ آپ کو اس سے گرفت حاصل کرنے کا موقع نہ مل جائے ، اور اگر آپ انھیں اکثر استعمال نہیں کرتے ہیں تو شاید آپ کو چیزوں کے لئے بہت سے خام پی ایچ پی کی افادیت یاد نہیں ہوگی۔ یہ خیال کہ ہم فریم ورک کے لحاظ سے مخصوص ڈویلپر بن چکے ہیں ، صرف خلاصہ کی پرتوں کے اوپر کام کررہے ہیں ، پی ایچ پی کے لئے قدرے عجیب ہے۔ بہرحال ، یہ "ویب مسئلے کو حل کرنے کی زبان" ہے۔ یہ C میں لکھا ہوا ہے اور یہ خود میں ایک تیز ، ہلکی زبان ہے ... بشرطیکہ آپ کسی بڑے فریم ورک کے بوٹسٹریپ عمل کو چلانے کا انتظار نہ کریں۔ اسی تناظر میں مائکرو پی ایچ پی کا منشور سامنے آیا ، جسے ایک شخص نے لکھا تھا جسے ہم فنکاترون کہتے ہیں (حالانکہ اس کا نام واقعتا Ed ایڈ فنکلر ہے)۔ یہ بیانات کا ایک سلسلہ ہے جس میں کہا گیا ہے کہ بہت سارے چھوٹے چھوٹے ماڈیولز بنانا ٹھیک ہے ، یہ زیادہ بہتر نہیں ہے ، اور یہ حقیقت ہے کہ ، جاوا کے لئے زندگی بہت مختصر ہے - چاہے یہ پی ایچ پی میں لکھا ہوا ہو۔
