เอาล่ะครับ หลังจากลองเล่น CI 2.0 ดู ที่เปลี่ยนแปลงไปมากๆ หน่อยก็น่าจะมี

1. Database

ส่วนนี้มี Drivers เพิ่มมาพอสมควรครับ แต่ว่ายังขาด PDO อยู่ แล้วก็มีเรื่อง DB Force เข้ามา ไว้จัดการพวก Database Table โดยตรง เรื่องนี้จริงๆ แล้วผมแค่อ่านจาก Class แล้วก็ Manual ไม่ได้ลองเข้าไปเทสจริงๆ จังๆ เพราะโดยส่วนตัวแล้ว ผมว่า Zend DB ทำงานได้ดีกว่านี้เยอะอยู่โขทีเดียว

2. Caching

ส่วนนี้ก็มีเพิ่ม Drivers เข้ามาเหมือนกัน โดยสามารถทำ Cache ผ่าน APC กับ Memcached ได้แล้ว แต่ว่ายังทำงานได้ไม่ละเอียดพอ ถ้าไปเทียบกับ Zend Cache ที่ีมีทั้งเรื่อง Tags เรื่อง Two Levels แล้วก็ driver ที่ค่อนข้างครบกว่า เรื่องนี้ผมเองก็คงไม่ได้เทส แค่มองผ่านก็คิดว่า ยังดึงดูดความสนใจได้ไม่มากพอ

3. JavaScript

ตอนนี้มี Class เพิ่มเข้ามาโดยทำการผูกกับ jQuery ซึ่งเขียนให้มองเป็น Drivers ตัวนึง ซึ่งดูจากโครงสร้างโคดที่เขียนไว้ น่าจะเปิดโอกาสให้กับ Developers มาพัฒนา Driver อื่นๆ เข้าไปได้ด้วย โดยผ่านการ extends class Javascript อีกทีนึง แล้วก้ยังมีการ เขียน Method ซึ่งเอาไว้ช่วยทำพวก tablesort, rounded corner อะไรพวกนี้ด้วย (แต่ต้องไป DL plugin มาลงเอง) เท่าที่ดูก็ Basic มาก เรียกว่า เขียนเองดีกว่า

หลังจากที่ CodeIgniter ทำการ update version ใหม่จริงๆจังซะที่กับ v2.0.0 โดยออกมาในวันที่ 28 มกรา ที่ผ่านมา ซึ่งเท่าที่อ่านดูจาก Change Log จะเห็นได้ว่ามีการปรับปรุงขนานใหญ่กันเลยทีเดียว โดยสาระสำคัญๆ น่าจะเป็นในส่วนของ Database Drivers แล้วก็ สามารถสร้าง Config ย่อยออกมาในลักษณะ Third Party ก็หมายความว่าเราจะสามารถทำ Application ย่อยโดยใช้ Core เดียวกัน แต่อาจจะมี Config, helpers, libraries ต่างกันในบางส่วนได้นั่นเอง แล้วก็ยังมีการ Bug Fixes อีกชุดใหญ่ๆ ฉลองตรุษจีนกันไปเลย

โดยในเนื้อหาวิธีใช้งานผมยังไม่ขอ Review นะครับ เพราะบอกตามตรง ไอ้ส่วนที่มัน Update ผมหนีไปใช้ Zend ทำงานแทนหมดแล้ว อาทิเช่น เรื่อง Database, Cache ที่เพิ่ม Driver มา ผมไม่ได้ใช้ของ CI เลย แต่คิดว่า คุณภาพคงจะไม่ต่างจากของ Zend มากนัก

แต่จะมาขอพูดถึงเรื่องวิธีการอัพเดท ดีกว่า ซึ่งผมใช้เวลาราวๆ 30 นาทีในการ upgrade application ของ OSCOOL เอง ซึ่งถึงตอนนี้ก็ยังไม่พบ Error อะไร (ผมอัพเดทจาก 1.7.2)

ซึ่งวิธีการเริ่มต้นของผมก็เริ่มมาจากนี่เลย พวก Core Class ของ CI v2.0.0 นั้นถูกโยกออกไปหมดแล้ว เค้าให้เหตุผลว่า เพื่อให้มันเหมาะสม เป็นสัดเป็นส่วน โดย folder ที่ย้ายมาใส่ไว้จะชื่อว่า core

เอาล่ะครับ มาต่อกันจากปีที่แล้ว 555+

ช่วงนี้ผมไปวุ่นๆ กับไอ้ Blogs ตัวนี้ จนไม่ได้มาอัพเดทอะไรเลย แต่วันนี้พอจะมีเวลาเหลือสักหน่อยหลังจากทำเรื่อง Order เสร็จก็จะมาเล่าให้ฟังถึงวิธีการทำ Controller ให้สมบูรณ์ยิ่งขึ้น นั่นก็คือ Controller ที่ใช้ใน Engine นี้แหละ

ก่อนอื่นต้องมาทำความเข้าใขกับตัว C ใน MVC เสียก่อน ตัวมันเองนั้นถือว่าเป็นหหัวใจเลย เพราะมันเป็นทั้งตัวเชื่อมต่อ models กับ views เข้าหากัน และยังเป็นตัวทำงาน Login สำคัญๆ เช่น validation ก่อน สั่งให้ไปหน้านู้น หน้านี้ ถือว่าเป็นแกนหลัก ใน MVC เลยทีเดียว

ตัว Controller ของ CI นั้นจริงๆแล้วก็พอจะมีความสามารถอยู่ในระดับนึง ทำงานค่อนข้างเร็วและมีประสิทธิภาพ แต่ที่ขาดไป และเป็นหัวใจเลยนั่นก็คือ ACL (Access Controller List) แล้ว CI ก็ไม่ได้เตรียม lib ในส่วนนี้มาให้เราเสียด้วย เราก็เลยต้องมาเหนื่อยหน่อย แต่ทำทีเดียวจบครับ....

เอาล่ะครับ ทิ้งช่วงให้รอมาพักนึง ต้องขอโทษด้วย พอดีเป็นคน ธุระ ทั้ง ราชทั้งหลวง เยอะจัด 555+

ตอนแรกที่จะนำเสนอเกี่ยวกับ Long Story ที่ตั้งชื่อตอนซะเก๋ชื่อ "Beauty Your CI" เป็นการสร้าง Model (M) ที่มีความสามารถมากกว่าเดิมอย่างเห็นได้ชัด ...

เอ่อแล้วก่อนที่จะเริ่มอ่านบทความนี้ขอให้กลับไปอ่าน มาใช้ "Zend Framework ใน CI กันเถอะ" แล้วทำให้ได้ตามตัวอย่างซะก่อน เพราะถ้าทำไม่ได้ บทความนี้ และต่อๆไปก็จะไร้ความหมายไปในทันที เพราะผมใช้ Zend เยอะมากๆ ...

จุดประสงค์หลักของ Beauty your CI ก็คือการสร้างโคด เอนกประสงค์ที่มีคุณสมบัติรองรับ เว็บแอพลิเคชั่น ทุกชนิด โดยออกแบบให้ง่าย และรีดประสิทธิภาพสูงสุด และที่สำคัญและท้าทายที่สุดก็คือ เราจะต้องไม่แตะต้อง โคดอะไรที่อยู่ใน system ทั้งสิ้น ไม่ว่าจะยังไงก็ตาม เพื่อใก้อณาคตเราสามารถอัพเดท Version ได้อย่างไม่เป็นปัญหา

หายไปนานโครตๆ เลย ยังไม่ได้ตายไปกับหวัด 2009 นะครับ แต่ช่วงนี้มันมีนู่นมีนี่ตลอดเลย ตอนนี้ก็ยังไม่เสร็จ แต่กลัวจะโดนลืมไปซะก่อน เลยขอแวะมาอัพเดท กันสั่งบทความ วันนี้ขอเป็นเรื่อง CI แล้วกันนะครับ

ไม่รู้คนอื่นจะเคยเจอปัญหาแบบเดียวกับผมรึเปล่า คือว่า ผมอยากจะ validate file ก่อน แล้วค่อย submit ไม่ใช่ submit แล้วค่อยมานั่งตรวจทาน กัน แบบนี้มันไม่ประทับใจ ผมก็เลยลองหาวิธีที่คอื่นเค้าใช้แก้กัน ก็ได้มา 2-3 วิธี แต่ลองๆไปแล้ว มันก็ยังไม่ใช่ที่อยากได้อยู่ดี เลยเอาไอ้ที่หาๆ มา ยำๆ กันจนได้เป็นวิธีของตัวเองซึ่งผมคิดว่า Work More เลยเอามาให้ลองกันดูนี่แหละ

ไม่ได้มาอัพซะนาน จนเกือบจะลืมไปละ ชื่อเว็บ ตัวเองสะกดยังไง 555+

พักนี้ไปทำตัวไร้สาระ ซะจนเบื่อ พอละ เลยมา อัพเดทซะหน่อยกลัวจะลืม กัน อิอิ

เรื่องที่จะพูดวันนี้ไม่ใช้ jQuery นะครับ แต่เป็น session library ใน CI ซึ่งตัวเองก็เพิ่ง มีโอกาสได้ลองใช้ ที่ไม่ได้ลองไม่ใช่เพราะมันไม่ดีนะครับ แต่ตอนนั้น ผมมีปัญหาว่า session ใน CI มันไม่ยอม สลาย หลังจาก ปิด Browser ซึ่ง บางโอกาส มันก็ไม่เหมาะกับงานของผม ก็เลย เขียน session lib ใหม่ ซึ่งเป็น native ใช้งาน เอง (session lib ของ CI จะทำงานด้วย Cookie) แต่ตอนนี้ อยากมาลองดูบ้าง เพราะเห็นมันบอกว่า "offering more flexibility for developers" จะดูซิว่าจริงรึเปล่า?

ก็เลย จับมาเทส โดยเอามาโม นิดนึง ให้มัน ทำลายตัวเองได้หลังจากปิด browser โดยการ extends lib มันมาแก้ นิดเดียว (เดี๋ยวจะบอกวิธีแก้ตอนท้ายของบทความ) แล้วก็เลยได้รู้ว่า " ของเค้าดีจริง "

โดยปกติ ผมไม่ชอบใช้งาน session อยู่แล้ว ด้วยเหตุผลหลาย อย่าง เช่น ต้องมา config ถ้าใช้งาน ผ่าน load balancer, session ค้างไม่ยอมลบ ออกจากระบบ File System ทำให้ Node เต็ม เป็นต้น

เอาล่ะครับ ในที่สุดก็มาเขียนต่อกันซะทีสำหรับ CI ตอนสุดท้ายที่จะเขียน สาเหตุก็เพราะ ผมขี้เกียจอธิบาย เอง อิอิ เพิ่งรู้ว่า เวลาเขียนอธิบาย Server Side Script มันลำบากกว่า Client Side Script เอามากๆ เลย เพราะมันต้องอธิบาย ลงไปถึง Environment อื่นๆ ของมันอีกด้วย ไม่ใช่แบบ หยิบจับมา บอกเล่าได้เลย รวมไปถึงตอนนี้ สะสมเทคนิคใหม่ๆ ของ jQuery ไว้เพียบ และยังไม่ได้มาพูดถึงกัน

ก็เลยตั้งใจไว้ว่า ตอนนี้ จะเป็นตอนสุดท้ายแล้วล่ะครับ ที่ผมจะเขียนถึง CI

เรื่องที่จะมาพูดกันไว้นี้ ก็คือเรื่อง Web Service ครับ แต่ไม่ได้พูดถึงการติดต่อกับ API ของเว็บไซต์ เจ้าดังๆ เจ้าไหน แต่จะมาพูดถึงการสร้าง ต่างหาก

สำหรับคนที่ศึกษาเรื่อง API มาบ้าง คงจะพอเข้าใจว่ามันมี Protocol ที่เป็นที่นิยมหลักๆ ก็คือ SOAP, REST, XML-RPC สำหรับ API ของ Client Script ที่นิยอีกตัวก็คือ JSONP

สวัสดีมาต่อเรื่อง CI กันแล้วครับ ตอนนี้ผมตัดสินใจละ ว่าจะเขียนถึง Day 10 เท่านั้นแล้วก็จะกลับเข้ามาสู่ ภาคของ jQuery ต่อ เพราะว่าตั้งแต่ jQuery ออก V.1.3 ผมก็ไม่ได้อัพเดท อะไรเลย ทั้งๆ ที่มีของเล่นใหม่ๆ เพิ่มมาพอสมควร และที่สำคัญ ผมขี้เกียจเขียนเรื่อง CI ละ มันต้องอธิบาย กันลึกเกิน ไปซึ่งผม ก็เขียนอธิบาย ไม่ค่อยเก่งเสียด้วย แต่ถ้ามีอะไรก็ถามกันเข้ามาได้ครับ

เออ ช่วงนี้เห็นหลายคนขอ M ผมเข้ามาเยอะเหลือเกิน ยังไงผมก็จะให้ไว้ในกระทู้นี้ละกัน d n a b o a r d @ g m a i l . c o m ยังไงแวะเวียนมาแลกเปลี่ยนความรู้กันได้เลย

วันนี้เรื่องที่จะมาเล่า คือเรื่องการทำ Caching ของ CI ครับ แน่นอนครับ ทำเวบสมัยนี้ มันไม่เหมือนเมื่อก่อนแล้ว มันมีเทคนิคที่ พัฒนาไปมาก ในการทำเวบ เรื่องที่ผมใส่ใจมากเป็นพิเศษ นอกเหนือจาก Structure แล้วก็คือ Performance นี่ล่ะครับ และสิ่งที่ Developer ทำกันมากที่สุด ในการ Tuning Performance นั่นก็คือ การทำ Caching ครับ ผมยกตัวอย่างเช่น Facebook.com

รู้มั้ยครับ facebook เองเขียนด้วย PHP ส่วน DB ก็ยังใช้ MySQL นี่ล่ะ แต่ทำไม มันถึงรองรับ คนได้มากเหลือเกิน ซึ่งจะว่ากันไปจริงๆ แล้วมันมีหลายเรื่องทั้ง Load Balance, Reverse Proxy แล้วก็ องค์ประกอบของ Hardware แต่เรื่องที่ น่าสนใจคือ FB มีการ Access DB น้อยมาก ซึ่งเราเองรู้กันดีอยู่แล้วว่า MySQL เนี่ย มันไม่ค่อยจะดีนัก ต่อเวบที่มี คนเยอะๆ มันอ่อนแอเหลือเกิน

เอาล่ะ มาต่อกันเลยกับการ Hack Route Core ของ Codeigniter เพื่อที่จะได้ url อย่างที่เราต้องการจริงๆ วิธีการไม่ยากเลยครับ แต่ก่อนอื่น ต้องสร้างพื้นฐานในการ Create Core Class ก่อน

โดยครั้งนี้เราจะมา extends ตัว Core ของ Route เพื่อทำการแก้ไขในส่วน url กัน โดยเป้าหมายเราจะสร้าง page ที่ user สามารถเข้าถึงได้ 2 แบบคือ

user.domain.com และ domain.com/user

โดยทั้ง 2 รูปแบบจะไปใช้ code ณ จุดเดียวกัน คุ้นๆ มั้ยครับมันเหมือนกับการ setup WP MU ที่ให้ user สามารถเลือก ลักษณะ ของ url ได้นั่นเอง

ซึ่งในการ เทส localhost นั้น ผมแนะนำให้ทดสอบโดยการ set host file ไว้ โดยไปที่

หายไปนานเหมือนกันเลยรอบนี้ เนื่องจากปัญหาทางด้านสุขภาพนิดหน่อย ช่วงนี้เป็นหวัดงอมเลยครับ พอหลังจากปีใหม่ก็ โทรมมายาวเลย แต่กลัวเนื้อหามันจะขาดช่วงไป ยังไงวันนี้ก็ฝืนสังขาร มาอัพเดทกันซะหน่อยแล้วกัน

ก่อนอื่นผมขออธิบาย เรื่อง Route ของ Framework กันซะก่อน ไม่เพียงแต่เฉพาะ CI โดยหลักแล้วการแสดงผล URL ที่แท้จริงของ Framework นั้นจะเป็นในลักษณะนี้ครับ

http://www.domain.com/index.php/controller/method/argv1/argv2