используя Velocity Macro для создания UI Component - PullRequest
1 голос
/ 27 октября 2011

Является ли хорошей идеей использование макроса скорости для создания компонентов пользовательского интерфейса, например, о производительности и поддерживаемости кода

вместо

<input type="text" name="$name" value="$value" />

мы напишем

#text($name $value)

Ответы [ 2 ]

1 голос
/ 31 октября 2011

Это, безусловно, удобно, если у вас есть логика ветвления или длинный html, который вы хотите просто скрыть. Предположим, вы хотите использовать стандартный форматировщик навигационных кнопок, вам нужно всего лишь изменить код в одном месте. ИМХО, для рефакторинга это проще, для переносимости и новых членов команды, может быть, сложнее.

Вот пример кода, который я использую, чтобы проиллюстрировать это:

#macro( viewCtrlButton $butId $butText $style)      ##style is optional
##configuration phase
    #if ($style == "save")        #set($type = "icon-buttons cat-save")
    #elseif($style == "cancel")   #set($type = "icon-buttons cat-cancel")
    #elseif($style == "next")     #set($type = "buttonz but_naviR")
    #end
    #if ($butId.contains(".")) 
        #set($link = "super_link") 
    #else 
        #set($link = "submit_link") 
    #end
##the actual code to construct
<a id="$butId" href="#" class="$type $link"> 
    <span> $butText </span>
</a>
#end
0 голосов
/ 29 октября 2011

Нет "хорошего" или "плохого", есть "соответствующее обстоятельствам".

Если бы не было много логики или большого упрощения, я бы не просто заменил бы стандартные теги макросом или шаблоном - мне нужно было бы достаточно функциональности, чтобы завершить дополнительная работа, дополнительное время и дополнительная когнитивная нагрузка того стоят.

(«Когнитивная нагрузка» просто означает, что если я смотрю на файл шаблона, мне потребуется больше времени, чтобы полностью понять, что он делает, если мне придется искать макросы. Это не обязательно плохо, и если я знаю, код приложения не имеет значения.)

...