Sự thật về cái gọi là tách biệt phần design với code php của Smarty

[bapnon]

Kinh nghiệm của tôi ở nhiều công ty cho thấy là đó là thái độ trốn việc. Khi tôi yêu cầu một số người page designer dùng CSS, họ cũng nói: ôi kinh quá chẳng hiểu cái gì, table đơn giản hơn. Khi yêu cầu dùng SCM, họ nói: ôi kinh quá, FTP đơn giản hơn. Không thể nương tay với thái độ đó. Sub-standard.

Bạn dựa vào đâu mà nói là thái độ trốn việc?

Cũng tùy người chớ, bao giờ cũng có một số phần trăm người này người kia. Mấy người giỏi graphics lại không có khả năng về programming! Mình nhớ lúc mình mới đi làm trong team của mình mấy người làm graphics họ rất giỏi về graphics lúc đó chỉ có photoshop 5.5 và dreamweaver 4 và flash 4, adobe premier 6, studio Max 2.5 nên mấy người làm về graphics họ chuyên về các software đó. Mấy người giỏi về graphics hình như thuộc loại gay và lesbian
hơi nhiều thì phải, con trai cũng đeo bông tai và nhuộc tóc đủ màu. Trong team mình toàn người Tây làm về graphics nhưng mấy thành viên thuộc dân Á châu thì lại làm coder. Mỗi lần sửa cái gì đó có programming là mấy người làm graphics họ sợ! thấy php mà mixing vào HTML là họ sợ! nhưng làm về graphics và ghép nối film thì họ rất giỏi, thiết kế rất giỏi nên boss phải sắm cho họ máy computer với 2 CPU để họ làm về graphics.

Hinh như ông trời cho người này có khả năng này lại kém cái khác vì vậy dân graphics họ sợ programming nhưng đâu phải họ có thái độ trốn việc! Khi boss cần làm presentation gấp họ ở lại làm qua đêm cho xong, đâu có phải là trốn việc đâu!

[fotech_nd]

Tớ đang tự hỏi thứ mà Smarty compile ra là gì?

Thế cậu tưởng PHP nó hiểu được mấy cái syntax của Smarty chắc. Nó phải compile ra mã PHP để PHP có thể execute được chứ, hay là cậu tưởng nó phải compile ra mã máy cho cậu?

[Hanaziki]

@pcdinh em có góp ý thế này: Đúng là nó dùng cả tấn abc như bác nói, bởi vì nó là compile engine - mà đã là compile engine thì bác có thấy trình biên dịch của ngôn ngữ nào mà ko dùng nhiều regular expression không, bác có thấy trình biên dịch nào mà ko phức tạp không? Mà cũng ko cần quá bận tâm tới nó có cả tấn abc hay chục tấn abc phức tạp gì đó, bởi vì nó cũng chỉ call khi compile thôi. miễn sao khi execute nó vẫn chạy nhanh là được.

Đúng là sự phát triển của các PHP framework mới là tín hiệu rất đáng mừng cho PHP, tuy nhiên dù có thế nào đi chăng nữa cũng ko nên miệt thị Smarty nhé các PHPer . Dù có phát triển thế nào đi chăng nữa - khi ở trong một trường hợp cụ thể nào đó Smarty vẫn có những điểm tích cực không thể chối cãi đâu (cái này em cũng ko chắc lắm ).

Em hoàn toàn đồng ý với bác ...

[jiSh@n]

Thế cậu tưởng PHP nó hiểu được mấy cái syntax của Smarty chắc. Nó phải compile ra mã PHP để PHP có thể execute được chứ, hay là cậu tưởng nó phải compile ra mã máy cho cậu?

Thế cuối cùng cũng là PHP vậy tại sao ngay từ đầu ko là PHP phức cho nó rảnh nợ?

[fotech_nd]

Thế cuối cùng cũng là PHP vậy tại sao ngay từ đầu ko là PHP phức cho nó rảnh nợ?

Tại sao trong các app người ta lại dùng xml, ini, ... để làm file config, vừa tốn công hệ thống phải parsing file, vừa phải sinh ra một đống chuẩn, một đống qui tắc, một đống tài liệu,... cho chúng, trong khi những setting đó hoàn toàn có thể làm bằng ngôn ngữ của ứng dụng?

Chỉ cần JS là đã đủ để xử lý hết các Actions (phía client) rồi, thế mà tại sao người ta lại viết thêm những Prototype, Mootool, Dojo, Rico, Extjs, YUI, jQuery, ... kèm theo đó là cả đống manuals, documents cho mỗi thằng.

Khi Rasmus Lerdorf viết những tập lệnh đầu tiên của PHP - ko biết ông ấy có hỏi tại sao lại phải làm phức tạp như thế không, trong khi có thể dùng trực tiếp Perl (sau đó có thêm C) để giải quyết bài toán của ông ta?

Bạn trả lời xem tại sao con người ta lại fức tạp thế?

[superthin]

Những ông hay bắt đầu với TOPIC mang tiêu đề "Sự thật..." toàn là những ông rất mù mờ về vấn đề mình nói. Cho nên sự thật của mấy ông đó toàn là sự đi hỏi người khác hoặc đúng hơn là sự dối trá trong tâm hồn mấy ổng

[pcdinh]

Tại sao trong các app người ta lại dùng xml, ini, ... để làm file config, vừa tốn công hệ thống phải parsing file, vừa phải sinh ra một đống chuẩn, một đống qui tắc, một đống tài liệu,... cho chúng, trong khi những setting đó hoàn toàn có thể làm bằng ngôn ngữ của ứng dụng?

Vấn đề bạn đang nêu chủ yếu liên quan đến system integration và portability của hệ thống. Vì các hệ thống khác nhau dẫn đến cấu trúc dữ liệu khác nhau, cách vận hành chúng khác nhau cho nên cần có các chuẩn dựa trên text (human readable) để tìm ra tiếng nói chung. Các ngôn ngữ như PHP, Ruby, Python có thể dựa hoàn toàn trên text nên có thể dùng chúng làm ngôn ngữ cấu hình được. Với các hình thức cấu hình khác mà tính chất của chúng ít thay đổi và có thì có đội kĩ thuật, bạn cũng có thể hard-coded vào một file cấu hình. Nếu thay đổi thì dịch lại và thay thế cũng không sao

Chỉ cần JS là đã đủ để xử lý hết các Actions (phía client) rồi, thế mà tại sao người ta lại viết thêm những Prototype, Mootool, Dojo, Rico, Extjs, YUI, jQuery, ... kèm theo đó là cả đống manuals, documents cho mỗi thằng.

Phần này lại liên quan đến tính accessibility và portability của công nghệ. DOM và browser compatibility là rất phức tạp nên việc tạo ra một abstraction layer nhằm xóa mờ low level detail là một cách để các lập trình dễ tiếp cận công nghệ hơn và làm việc năng suất hơn.

Khi Rasmus Lerdorf viết những tập lệnh đầu tiên của PHP - ko biết ông ấy có hỏi tại sao lại phải làm phức tạp như thế không, trong khi có thể dùng trực tiếp Perl (sau đó có thêm C) để giải quyết bài toán của ông ta?

Perl là một ngôn ngữ idiomatic. Nó dùng quá nhiều kí hiệu để biểu đạt cú pháp khiến cho việc đọc code là không dễ dàng. Hơn nữa, nó sinh ra trong bối cảnh web chưa ra đời. Do vậy có các dị biệt giữa HTML và Perl là lớn. Giống như Java Servlet hay C# mà thôi.

Rasmus tạo ra PHP là để sinh trang dễ dàng hơn khi mà 90% số code để tạo trang là HTML và CSS thì 10% số còn lại chỉ cần viết bằng một ngôn ngữ khác phía máy chủ. Vào thời điểm những năm 1995, web là các trang đơn giản. Vậy tại sao không tiếp cận HTML trước mà lại phải tìm ra hướng tiếp cận từ Perl hay C với vô số các nối chuỗi phức tạp và khó đọc.

Bình luận:
Lập luận của bạn đi quá xa vấn đề đang thảo luận. Sự lựa chọn giữa Smarty và PHP Template systems như PHPSavant, Zend_View, Symfony hay CakePHP chỉ là sự lựa chọn về cú pháp và cách thức thể hiện nào là hợp lý khi tạo template page chứ vấn đề không đi xa như bạn nghĩ.

Khi Andrei tạo Smarty, anh chàng Nga trắng này chỉ nghĩ là tổ chức chương trình của cộng đồng PHP quá tệ. Kiểu như thế này:

http://www.google.com/codesearch/p?h...p&q=oscommerce

Tức là tư duy kiến trúc rất bản năng dựa trên con mắt của một designer. Nghĩa là hình dung một trang nó hiện lên thế nào thì viết code vào các vùng đó như thế. Giống như là làm Photoshop ý (tôi không bao giờ tin một web designer hay graphic designer làm web mà không biết PHP). Anh ta chỉ hiểu là làm như vậy sẽ làm cho life cycle của ứng dụng rất rối trong khi PHP là ngôn ngữ phía máy chủ sinh ra để mix vào HTML (mặc dù đó không phải là cách làm duy nhất). Vậy nên anh ta nghĩ tính năng này của PHP là vấn đề. Nếu tách PHP thành file riêng và đưa việc nhúng PHP vào trang trở thành việc của một template engine thì vấn đề được giải quyết.

Andrei không có tư duy của một SA và rõ ràng là anh ta định nghĩa sai vấn đề. Bản chất của vấn đề nằm ở các component của ứng dụng có các vai trò khác nhau và không có khái niệm PDP khi cộng đồng PHP đủ lớn. Anh ta chưa biết về MVC hay MVP. Đó cách nghĩ của năm 2001 khi mà web chưa phát triển. Hồi đó tôi còn dùng Frontpage với sự ngưỡng mộ M$ lắm cơ.

Vậy Smarty đã xử lý vấn đề này với sự khác biệt ở chỗ nào so với hình thức templating system dựa trên PHP + tư duy OOP:

In biến ra
------------
PHP, PHPSavant, Zend_View, CakePHP...

<?php echo $var ?>

Smarty

{$var}

Thay đổi format 1 string in ra từ biến
--------------------------------------
PHP, PHPSavant

<?php $this->plugin('modify', $var, 'trim ucwords') ?>

hay

<?php echo trim(ucwords($var)); ?>

Smarty

{$var:strip:capitalize}

Gán biến
-------------
PHP, PHPSavant
hay

<?php $var = 'something'; ?>

Smarty

{assign var='my_variable' value='something'}

Biểu thức điều kiện và vòng lặp
-------------------------------
PHP, CakePHP, Symfony, Zend

<?php if ($var == 'something'): ?>
...
<?php endif; ?>

<?php foreach ($custid as $curr_id): ?>
	<?php echo "id: $curr_id<br>" ?>
<?php endforeach; ?>

Smarty

{if $var == 'something'}
...
{/if}

{foreach from=$custid item=curr_id}
	id: {$curr_id}<br>
{/foreach}

Cái mà Smarty gọi là section

{section name=customer loop=$custid}
	id: {$custid[customer]}<br>
{/section}

thì ở PHP là tầm thường

<?php foreach ($custid as $key => $val): ?>
	id: <?php echo $custid[$key] ?><br>
<?php endforeach;

Code Smarty và PHP không khác biệt nhiều, không cho bạn cảm giác về sự khác biệt giữa chúng giống như ở các attribute language như TAL. Vậy thì Smarty làm tăng tính readability ở đâu? Không có (xem lại post của chủ thread). Chỉ là đôi khi ngắn hơn: tức là một cách viết tắt.

Smarty là được gì cho cộng đồng PHP từ năm 2001: đó là một sự giới hạn có ý đồ. Andrei ngầm nói: Smarty chỉ có vài tag thế thôi, phần còn lại viết bằng PHP thì viết ra chỗ khác, đừng có mix vào HTML như các bố bên OsCommerce nữa. Vậy là cộng đồng đã biết cách tách template file và PHP logic file. Nhưng application flow, rule, configuration và data flows vẫn bị mix. Thường thì các ứng dụng PHP đủ nhỏ để quản lý vấn đề đó một cách dễ dàng. Nhưng lớn như Wikipedia, Moddle và một số ERP system viết trên PHP thì thấy vấn đề là đủ nghiêm trọng.

Các bạn ủng hộ Smarty vì các bạn chưa thành thạo về PHP cũng như lập trình OOP hoặc chưa thật sự hiểu thế nào là template system. Viết trên Smarty tag để Smarty chuyển hộ bạn sang PHP template (gọi là compile) và tự quản lý lấy các file gọi là compile này. Các bạn suy đoán (assume) rằng compiled files này là nhanh. Tôi yêu mến sự hồn nhiên của các bạn.

Tuy nhiên nhìn vào sự thực đi:

Smarty code

{foreach from=$list item=item}
  <li>{$item|escape}</li>
{/foreach}

được dịch thành

<?php $_from = $this->_tpl_vars['list'];
      if (!is_array($_from) && !is_object($_from)) {
          settype($_from, 'array');
      }
      if (count($_from)):
          foreach ($_from as $this->_tpl_vars['item']):
?>
  <li><?php echo ((is_array($_tmp=$this->_tpl_vars['item']))
                 ? $this->_run_mod_handler('escape', true, $_tmp)
             : smarty_modifier_escape($_tmp)); ?>
</li>
<?php     endforeach;
      endif;
      unset($_from);
?>

Template system dựa trên pure PHP và với sức mạnh của OOP, nó mang lại hiệu quả đúng như Smarty nhưng dựa trên quy ước (chứ không dựa trên một third party component): hãy giới hạn số code viết trên template một cách tự giác và chỉ dùng assignment, for, foreach, while, echo, print, number_format tức là các cấu trúc cơ bản. Phần còn lại viết trên Controller và assign các giá trị vào template file dựa trên sự hỗ trợ của template system.

Hãy tìm hiểu về MVC và học cách dùng template system dựa trên PHP, các bạn sẽ thấy Smarty đúng là lịch sử.

Tuy nhiên có một số trường hợp nhỏ cần đến các ngôn ngữ template kiểu Smarty. Đó là use cases của Facebook ML. Nhưng đừng nói với tôi là designer không biết PHP họ chỉ biết viết {foreach from=$list item=item} chứ không thể biết cách viết <?php foreach ($list as $item): ?>. Tôi vẫn gọi là trốn việc (hoặc thiểu năng trí tuệ)

[superthin]

Template system dựa trên pure PHP và với sức mạnh của OOP, nó mang lại hiệu quả đúng như Smarty nhưng dựa trên quy ước (chứ không dựa trên một third party component): hãy giới hạn số code viết trên template một cách tự giác và chỉ dùng assignment, for, foreach, while, echo, print, number_format tức là các cấu trúc cơ bản. Phần còn lại viết trên Controller và assign các giá trị vào template file dựa trên sự hỗ trợ của template system.

Hãy tìm hiểu về MVC và học cách dùng template system dựa trên PHP, các bạn sẽ thấy Smarty đúng là lịch sử.

Tuy nhiên có một số trường hợp nhỏ cần đến các ngôn ngữ template kiểu Smarty. Đó là use cases của Facebook ML. Nhưng đừng nói với tôi là designer không biết PHP họ chỉ biết viết {foreach from=$list item=item} chứ không thể biết cách viết <?php foreach ($list as $item): ?>. Tôi vẫn gọi là trốn việc (hoặc thiểu năng trí tuệ)

Quả pcdinh không hổ danh là một triết gia / guru về PHP ở Việt Nam. Tuy nhiên, tui hơi nghi ngờ về tính thực tiễn của đồng chí một chút, tui nghĩ, có lẽ đồng chí làm ở mức manager hoặc thầy giáo dạy học thì rất tuyệt, nhưng để làm nên một sản phẩm thực sự tui muốn được xem profile của đồng chí, các case-study, porfolio hoặc một vài website được đồng chí viết / demo xem thế nào. Bởi vì lý thuyết và thực tế đôi khi khác rất xa. Mong đồng chí thông cảm và hiểu cho, tui hổng có ý châm chọc gì ở đây mà vì đến với PHP thấy ai cũng bảo dễ nhưng tui thấy rối rắm thật, so với Pascal nó quả là đau đầu hơn.

À, nhưng nói gì thì nói, là vì tui đang tìm hiểu về một số mã nguồn viết bằng PHP, nên sẵn hỏi luôn vài câu:

Drupal có các viết mã tiếp cận theo hướng Smarty hay MVC?
phpBB 3 có các viết mã tiếp cận theo hướng Smarty hay MVC?
Wordpress có các viết mã tiếp cận theo hướng Smarty hay MVC?
PHP-Nuke nữa nhé.
vBB, IPB, SMF kèm theo luôn thể.

Nhờ bác sắp xếp các phần mềm trên theo 2 cột Smarty và MVC với nhé.

Mình đã đọc mã mấy cái này mà vẫn chưa phân biệt được, nói chung là không nắm được cái nào đi theo hướng nào, nhưng nhìn chung là thấy các phần mềm mã mở đều tốt cả.

Xin cám ơn pcdinh, mong sớm nhận được trả lời.

[pcdinh]

Bạn cần tìm hiểu về MVC thực sự là gì thì bạn sẽ tự trả lời cho câu hỏi của bạn thôi.

Tuy nhiên nếu bạn nghĩ lập trình thủ tục không thể là MVC thì checkout dự án của tôi Spica CMS trên Google Code. Nếu muốn pure OOP thì chờ Pone 2.0 framework cũng trên Google Code.

Nếu bạn lại nghĩ tách được template ra bên ngoài như Joomla đã là MVC thì cần đọc phân biệt rõ ràng đâu là chỗ của M, đâu là C. Đặc biệt là dependency giữa chúng.

[conan1212]

Chỉ cần JS là đã đủ để xử lý hết các Actions (phía client) rồi, thế mà tại sao người ta lại viết thêm những Prototype, Mootool, Dojo, Rico, Extjs, YUI, jQuery, ... kèm theo đó là cả đống manuals, documents cho mỗi thằng.

Mấy cái đó chúng được tạo ra với một mục đích ko như Smarty đâu bạn.

Khi Rasmus Lerdorf viết những tập lệnh đầu tiên của PHP - ko biết ông ấy có hỏi tại sao lại phải làm phức tạp như thế không, trong khi có thể dùng trực tiếp Perl (sau đó có thêm C) để giải quyết bài toán của ông ta?

Bạn trả lời xem tại sao con người ta lại fức tạp thế?

Vậy bạn có bao giờ tự nhìn lại và tự hỏi Notepad có thể dùng để code được tại sao người ta lại phải tạo ra Dreamweave, hay Eclipse ko?

Những ông hay bắt đầu với TOPIC mang tiêu đề "Sự thật..." toàn là những ông rất mù mờ về vấn đề mình nói. Cho nên sự thật của mấy ông đó toàn là sự đi hỏi người khác hoặc đúng hơn là sự dối trá trong tâm hồn mấy ổng

Bạn xem lại điều mình nói nhé, thời gian nguyên cứu và làm việc với Smarty của bạn chắc ko nhiều bằng tôi đâu.

Nếu bạn lại nghĩ tách được template ra bên ngoài như Joomla đã là MVC thì cần đọc phân biệt rõ ràng đâu là chỗ của M, đâu là C. Đặc biệt là dependency giữa chúng.

Chỉ có những ai thật sự biết thế nào là MVC và làm việc nhiều với cái gọi là MVC của Joomla mới thấy đó có phải là MVC chính thống ko thôi.