Response.Write или обычный старый HTML

Question

Что является лучшей практикой кодирования с учетом скорости (Classic ASP):

sPg=sPg& "<select id=""actions"" onchange=""emact(this.value)"">"
sPg=sPg& "<option value=""""></option>"
sPg=sPg& "<option value=""read"">read</option>"
sPg=sPg& "<option value=""unread"">unread</option>"
sPg=sPg& "<option value=""spam"">spam</option>"
sPg=sPg& "<option value=""unspam"">unspam</option>"
sPg=sPg& "<option value=""delete"">delete</option>"
sPg=sPg& "<option value=""undelete"">undelete</option>"

OR

<select id="actions" onchange="emact(this.value)">
<option></option>
<option value="read">read</option>
<option value="unread">unread</option>
<option value="spam">spam</option>
<option value="unspam">unspam</option>
<option value="delete">delete</option>
<option value="undelete">undelete</option>

думаю, но в гораздо большем масштабе (бэкэнд интернет-магазина написан почти полностью, работает над новой версией) - я собираюсь преобразовать все это в простой для управления HTML вместо response.write каждый раз, но я просто хочу узнать, делая это, я не копаю себе яму.

Answer 1

Это то, что я хотел бы сделать.

Нет абсолютно никаких оснований для создания всей структуры HTML с помощью конкатенации строк, и вы получите небольшую производительность, перейдя на прямой HTML.

Это также было бы более легко обслуживаемым, так как вам не нужно беспокоиться о экранировании кавычек и проверке правильности конкатенации ваших строк.

Answer 2

Если вы переписываете, почему вы собираетесь использовать 10-летнюю технологию?

(используйте второй.)

Answer 3

Разве аргумент для использования Response.Write поверх HTML не будет таким же, как для параметризации операторов SQL по прямым запросам SQL? То есть закрыть несколько лазеек для возможной инъекции?