Được gửi bởi
fotech_nd
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
Được gửi bởi
fotech_nd
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.
Được gửi bởi
fotech_nd
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...
Smarty
Thay đổi format 1 string in ra từ biến
--------------------------------------
PHP, PHPSavant
Code:
<?php $this->plugin('modify', $var, 'trim ucwords') ?>
hay
Code:
<?php echo trim(ucwords($var)); ?>
Smarty
Code:
{$var:strip:capitalize}
Gán biến
-------------
PHP, PHPSavant
hay
Code:
<?php $var = 'something'; ?>
Smarty
Code:
{assign var='my_variable' value='something'}
Biểu thức điều kiện và vòng lặp
-------------------------------
PHP, CakePHP, Symfony, Zend
Code:
<?php if ($var == 'something'): ?>
...
<?php endif; ?>
Code:
<?php foreach ($custid as $curr_id): ?>
<?php echo "id: $curr_id<br>" ?>
<?php endforeach; ?>
Smarty
Code:
{if $var == 'something'}
...
{/if}
Code:
{foreach from=$custid item=curr_id}
id: {$curr_id}<br>
{/foreach}
Cái mà Smarty gọi là section
Code:
{section name=customer loop=$custid}
id: {$custid[customer]}<br>
{/section}
thì ở PHP là tầm thường
Code:
<?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
Code:
{foreach from=$list item=item}
<li>{$item|escape}</li>
{/foreach}
được dịch thành
Code:
<?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ệ)
Bookmarks