Hoffman Framework เอา Smarty ออกจาก Components หลักแล้ว

ช่วงนี้ไม่ได้บอกถึงความเปลี่ยนแปลงของ Framework ตัวนี้เลยเกือบ ๆ เดือน เพราะว่าผมเปลี่ยนงานใหม่ครับ เลยต้องนั่งเคลียร์งานที่ค้างกับบริษัทเก่า เลยแทบไม่ได้จับเลย แต่ก็หาเวลาว่ามานั่งไล่ดูระบบภาพรวมโดยทั้งหมด สิ่งที่ผมเปลี่ยนแปลงตัวระบบ runtime มากที่สุดครั้งหนึ่งในการทำ Framework ตัวนี้คือเอา Smarty ออกไป (แต่ถ้าอยากเอากลับมาก็ทำได้ไม่ยาก เดี่ยวจะเขียนวิธีการอีกทีนึงสำหรับคนที่อยากเอา Smarty หรือ Template-engine ตัวอื่น ๆ มาใส่) ซึ่งตัวโครงสร้าง RenderView นี่ไม่ได้เปลี่ยนแปลงอะไรมาก นอกจากเอา Smarty ออกไป และสร้าง method ที่ render ของตัวเองมาอีก 2-3 ตัวเท่านั้นเอง เลยเอากลับมาใส่ได้ไม่ยากครับ

เหตุผลที่เอาออกไปเนื่องจากมันไปหยุดวิธีการทำงานของแนวคิด php เดิม ๆ ไปไว้ฝั่ง designer และทำให้ learning curve ของทั้งฝั่ง developer และ designer เพิ่มมากขึ้น เพราะ Smarty มี syntax เป็นของตัวเอง และสิ่งที่ทำให้ผมรู้สึกว่าต้องเอาออกจริง ๆ นั้นคือการสร้าง Helpers ของ RenderView ที่ยากกว่าปกติมาก ๆ -_-‘ การ register function/class/object/class->method เข้าไปเป็น function/modifier ต่าง ๆ พวกนี้ทำได้ยาก และงงสุด ๆ ซึ่งจริง ๆ มันก็ไม่ยากหรอกครับ แต่ว่ามันเสียเวลามากกว่าปกติเวลาต้องคิดพวก Helpers เพราะมี guide-line ของมันเอง ซึ่งทำให้มึน ๆ งง ๆ ได้ง่าย ๆ เลย จริง ๆ 9Aum ก็บอกแบบนี้เหมือนกัน ผมก็ว่าจริง ;P

โดยที่ผมเอาออกไป ก็ไปนั่งแกะเจ้า Smarty และ Template-engine ของค่ายอื่น ๆ บ้าง รวมถึง CodeIgniter ด้วย เพื่อเขียนเองซะเลย พบว่าใช้ output-buffer แทนแล้วกัน แต่คาดว่าผมต้อง manage ตัว buffer นี้ด้วย ไม่งั้นมีปัญหาแน่ ๆ ซึ่งจริง ๆ Template-engine ทุกตัวก็ใช้แนวคิดไม่ต่างกันอยู่แล้วครับ คือทำ runtime ให้เสร็จแล้วเอาผลของการทำงานออกมาทีเดียวเลยเพื่อแยกระหว่าง process กับ presentation ออกจากกันอย่างชัดเจน โดยแนวคิดหลัก ๆ เอามาจาก PHPTemplate ของ Drupal ครับ

ต่อมาก็ทำ Acl เสร็จแล้วรวมถึง Authen ด้วย (เพราะทั้งส่วนนี้ต้องทำคู่กันครับไม่งั้น ไม่มีประโยชน์แน่นอน) กำลังปรับแต่งให้ config ง่ายที่สุด และรองรับทั้ง file-base และ db-base ครับ

ส่วน Error Handle และ Logs นั้นเพิ่มและใช้ได้ดี ในระหว่างทำ demo-app และ production-app ครับ (ตอนนี้ผมทำ production-app อยู่ 2-3 ตัวครับผม) โดย Logs จะช่วยได้เยอะมาก ๆ ในเรื่องการ track-error ครับ และ Error Handle มี 2 mode คือ production และ developer ครับ ถ้า environment เป็น production พวก error ต่าง ๆ จะไม่โชว์ออกมาเลย แต่จะ redirect ไปหน้าหลักอย่างเดียว (หรือ control ไปหน้าอื่น ๆ ก็ได้ แต่อันนี้เดี่ยวใส่เพิ่มอีกที)  แต่พวก error พวกนี้จะบันทุกอยู่ใน logs ตลอดครับ ทั้ง 2 mode เลย ทำให้ถ้ามี error ใน production mode จะไม่โดน hack จากการเกิด error ได้ง่ายครับ

ส่วนของ Third Party Components นี่กำลังใส่ทำ Baseclass-Components  อยู่ครับ จะได้สะดวก ๆ หน่อยน่ะครับ ;)

เดี่ยวจะมาเล่าพวกการ config อีกทีครับว่ามีส่วนไหนบ้างครับผม ;)

image

The First Drupal Community in Thailand Started !!!

เริ่มแล้วสำหรับเว็บ Drupal Community ของไทย อย่างเป็นทางการ เข้าได้จาก drupal.in.th นั้นเอง

ซึ่งเดี่ยวผมคงเข้าไปแจมที่นั้นด้วย เพราะตัวเองก็เป็น Drupal Modifier/Developer คนนึงเหมือนกัน ;)

จาก

เมื่อ jQuery อยู่ร่วมโลกกับ Prototype/Mootools ไม่ได้ (โดยเฉพาะใน Drupal)

ถ้าใครใช้ jQuery, Prototype และ Mootools นั้นจะรู้ว่ามี namespace ตัวนึงคือ $ ซึ่งจะเป็นตัวอ้างอิงเสมือนเวลาอ้างอิงการทำงานใด ๆ ใน ถ้าอ่านในเว็บ jQuery ก็จะบอกไว้เลยว่า

By default, jQuery uses “$” as a shortcut for “jQuery”

ปัญหาก็คือ …..

มันดันใช้วิธีที่ไปเหมือนกับ Prototype, MooTools และ YUI นั้นดิ

ทำให้เวลาเอามาใช้ร่วมกันมันจะตีกันสนุกสนานเลยหล่ะ วิธีแก้ไขก็คือให้ jQuery หลีกทางให้กับตัวอื่น ๆ ซะ

จาก

  1. <script type="text/javascript" src="prototype.js" />
  2. <script type="text/javascript" src="mootools.js" />
  3. <script type="text/javascript" src="jquery.js" />
  4. <script type="text/javascript">
  5. // ต้องใช้ jQuery
  6. $(document).ready(function(){ $("div").hide(); });
  7. // ต้องใช้ Prototype/Mootools
  8. $('someid').style.display = 'none';
  9. </script>

ถ้าเป็นแบบนี้มันจะใช้งานไม่ได้ ครับ จะเกิดการตีกันระหว่างทั้ง 3 ตัวครับ เราต้องเปลี่ยนมาเป็น

  1. <script type="text/javascript" src="prototype.js" />
  2. <script type="text/javascript" src="mootools.js" />
  3. <script type="text/javascript" src="jquery.js" />
  4. <script type="text/javascript">
  5. // เพิ่มบรรทัดนี้ลงไป
  6. jQuery.noConflict();
  7. // แล้วใช้ jQuery จาก $ เป็น jQuery(...) แทน
  8. jQuery(document).ready(function(){jQuery("div").hide();});
  9. // ส่วน Prototype/Mootools ใช้ $(...) ได้ตามปกติ
  10. $('someid').style.display = 'none';
  11. </script>

แนวทางการแก้ปัญหาก็ ok นะ แต่ …..

ใน Drupal หล่ะ ถ้าเราเอามาใช้เนี่ยทำไง

โดยตัว Drupal 5.2 แล้วมี jQuery 1.0.1 ใส่มาด้วย แต่ปัญหาคือมันดันไม่มี noConflict มาให้ ตอนนั่งแก้ปัญหา นั่งงงไปพักนึง เลยไปนั่งไล่แกะ จนรู้ว่าต้องมา upgrade เป็น jQuery 1.2 เสียก่อน เลยจัดการเอามาใส่ทับลงไปใน /misc แทนตัวเก่า

แล้วทำการแก้ไขไฟล์ต่าง ๆ ที่ Drupal นั้นใช้ jQuery ซึ่งได้แก่

  • misc/autocomplete.js
  • misc/collapse.js
  • misc/drupal.js
  • misc/progress.js
  • misc/tableselect.js
  • misc/textarea.js
  • misc/upload.js
  • misc/update.js
  • misc/farbtastic/farbtastic.js

โดยทำการ replace ‘$(‘ เป็น ‘jQuery(‘ แล้วทำการใส่ JavaScript ตัวนึงลงไปคือ

  1. jQuery.noConflict();

โดยเอาไปใส่ไว้ด้านล่าง Durpal $scripts ที่ Theme ของเรา ตามด้วยการใส่ mootools.js ไปก่อนหน้า Drupal $head

เฮ้อ ….. เล่นซะมึนไปครึ่งวัน

การมีมาตรฐานและเอามาใช้ร่วมกันนี่ยากเหมือนกันนะเนี่ย ยิ่ง JavaScript ที่มี Prototype หลายค่ายเหลือเกินยิ่งแล้วใหญ่ ความเข้ากันได้ยิ่งยากเข้าไปอีก แถมแต่ละตัวก็ ok ในเรื่องการใช้งาน แต่ว่าบางตัวมีข้อดีแต่ต่างกัน บางตัวใช้งานบางอย่างได้ดี และง่าย บางตัวทำแบบอีกตัวก็ได้ แต่ง่ายกว่ามาก เลยต้องหาจุดลงตัวของมันไป ทำให้ต้องมาปวดหัวกันไป แต่ก็นะเอามาใส่ลงไปในงานของเรา เพื่องานที่ออกมาดีที่สุด และง่ายที่สุดด้วย (ก็มีให้ใช้นิ)

อ้างอิงจาก