Теренс Парр - очень умный парень, и его статья может похвалить его, но с практической точки зрения я обнаружил, что использование просто этих конструкций несколько ограничивает.
трудно предотвратить проникновение бизнес-логики, особенно если у вас есть возможность что-либо делать, как, например, ASP.NET и JSP дадут вам. Это сводится к тому, как вы проводите свое время:
- Разрешить ограниченную дополнительную функциональность (я не сторонник "все идет") и использовать механизмы проверки кода для обеспечения правильного использования, или
- Ограничивайтесь четырьмя конструкциями, приведенными выше, и тратьте больше времени на предоставление таких атрибутов, как
valueLessThanFive (не забывая переименовывать его в valueLessThanSix при изменении бизнес-требований или добавляя valueMoreThanThree - в качестве примера это немного шутливо, но я думаю, вы поймете, к чему я клоню).
На практике я считаю, что использование условных и циклических конструкций полезно, так же как и разрешение свойств, таких как attr[index].value в шаблонных выражениях. Это позволяет эффективно управлять логикой представления, в то же время подвергаясь лишь небольшому риску неправильного использования.
Предоставление большей функциональности, такой как произвольные вызовы методов, становится все более «опасным» (с точки зрения облегчения неправильного использования). В некоторой степени это зависит от культуры развития, существующей в вашей среде, процессов разработки и уровня навыков и опыта в вашей команде.
Другим фактором является то, что в вашей среде вы можете позволить себе строгое разделение работы между презентацией и логикой, с точки зрения наличия преданных дизайнеров, не являющихся программистами, которые были бы обеспокоены продвинутыми конструкциями в шаблоне. В этом случае вам, вероятно, будет лучше с более ограниченными функциональными возможностями шаблона.