Grails: шаблоны против TagLibs. [закрыто]
someVar должно быть доступно только в контексте some_function(), а не от слушателя. Если вам нравится иметь его внутри слушателя, вы должны сделать что-то вроде:
someObj.addEventListener("click",
function(){
var newVar = someVar;
some_function(someVar);
},
false);
и вместо этого использовать newVar.
Другой способ - вернуть значение someVar из some_function() для дальнейшего использования в слушателе (как новый локальный var):
var someVar = some_function(someVar);
2 ответа
Определенно есть некоторые совпадения, но ниже есть несколько вещей, о которых следует подумать. Можно подумать, что Template похож на повторное использование на уровне метода, тогда как TagLibs более удобны для повторного использования на уровне API.
Шаблоны отлично подходят, когда вам нужно отформатировать что-то конкретное для отображения. Например, если вы хотите отобразить объект домена определенным образом, обычно это проще сделать в шаблоне, поскольку вы в основном просто пишете HTML с некоторыми из них. Многоразовый, но я думаю, что возможность его повторного использования немного ограничена. Т.е. если у вас есть шаблон, вы бы использовали его на нескольких страницах, а не на сотнях страниц.
С другой стороны, taglibs - это небольшая функциональная единица, но вы, скорее всего, будете использовать ее во многих местах. В нем вы, вероятно, объедините строки, поэтому, если вы хотите создать сотню строк HTML, они менее удобны. Ключевой особенностью библиотеки тегов является возможность вводить / взаимодействовать с сервисами. Например, если вам нужен фрагмент кода, который вызывает службу аутентификации и отображает текущего пользователя, вы можете сделать это только в TagLib. В этом случае вам не нужно беспокоиться о передаче чего-либо в taglib - taglib пойдет и выяснит это из службы. Вы также можете использовать это на многих страницах, поэтому ' Намного удобнее иметь taglib, не требующий параметров.
Есть также несколько видов taglib, включая те, которые позволяют вы перебираете что-то в тело, условное и т. д. - это это невозможно с шаблонами. Как я сказал выше, хорошо продуманный библиотеку taglib можно использовать для создания API многократного использования, который делает ваш GSP код более читабельный. Внутри одного и того же * taglib.groovy вы можете иметь несколько определений тегов, так что есть еще одно отличие - вы можете сгруппировать их все в одном месте и вызывать из одной библиотеки тегов в другую.
Также имейте в виду, что вы можете вызывать шаблон из библиотеки тегов или вызывать библиотеки тегов с помощью шаблонов, чтобы вы могли смешивать и сопоставлять их по мере необходимости.
Надеюсь, это немного проясняет вам ситуацию, хотя на самом деле многое из этого связано с тем, какие конструкции удобнее кодировать и как часто они будут использоваться повторно.
Что касается нас ...
Кодировщик должен видеть конкретную логику представления объекта в шаблоне, а не где-либо еще.
Мы используем библиотеки тегов только для отдельных элементов страницы, не имеющих отношения к бизнес-логике. На самом деле мы стараемся минимизировать их использование: слишком просто написать бизнес-логику в taglib.
Шаблоны - это обычный способ; например, они поддерживают макеты (кстати, их можно назвать третьим механизмом)