Под сопряжением клиентского и серверного кода я понимаю некоторый JSON-закодированный объект, который генерирует серверное представление, чтобы передать клиентской части приложения начальное состояние при загрузке страницы.
Такое сопряжение я использую в своих приложениях. Передать некоторое состояние в JavaScript можно и другими способами, например, используя data-* атрибуты (http://api.jquery.com/data/) либо загружая только разметку в виде шаблонов, наполняя её данными с помощью ajax-запросов. http://knockoutjs.com/ — тоже очень классная штука.
Вы скажете: «Фу, буэ, ты мешаешь JS-код и разметку». Я отвечу, что нет, не мешаю, JS код лежит аккуратно в header. Не вижу особой разницы, где именно в разметке закодированы эти данные: в атрибутах html или вот так явно в специальном блоке. Преимущество данного подхода в том, что мы явно декларируем в одном месте, что наш клиентский код зависит от таких-то начальных значений. Эдакий Dependency Injection. Более того, можно автоматизировать тестирование того, что View (а именно View должна отвечать за создание эти блоков) наполняет объект pageInitVars значениями. Короче говоря, мы хотим защититься от Null Reference Exception в клиентском коде.
Можно создавать тест для каждого представления и перечислять в нём переменные для клиентского кода, который оно должно инициализировать, а можно — держитесь крепче — найти в клиентском коде, связанном с данным представлением, все обращения к pageInitVars и протестировать, что View эти значения передаёт через ViewModel. Мне кажется, что это довольно простая задача. Заниматься парсингом JavaScript кода не обязательно. Достаточно искать все вхождения pageInitVars, или другого объекта с более удачным названием, смотреть на то, что идёт после точки, например pageInitVars.nextPageUrl и проверять есть ли этот Url во ViewModel. А что вы думаете по этому поводу? Тестируете ли вы клиентский код таким образом?
<html>
<header>
<script type="text/javascript">
var pageInitVars = { /* initial state and variable values */ }
</script>
</header>
Такое сопряжение я использую в своих приложениях. Передать некоторое состояние в JavaScript можно и другими способами, например, используя data-* атрибуты (http://api.jquery.com/data/) либо загружая только разметку в виде шаблонов, наполняя её данными с помощью ajax-запросов. http://knockoutjs.com/ — тоже очень классная штука.
Вы скажете: «Фу, буэ, ты мешаешь JS-код и разметку». Я отвечу, что нет, не мешаю, JS код лежит аккуратно в header. Не вижу особой разницы, где именно в разметке закодированы эти данные: в атрибутах html или вот так явно в специальном блоке. Преимущество данного подхода в том, что мы явно декларируем в одном месте, что наш клиентский код зависит от таких-то начальных значений. Эдакий Dependency Injection. Более того, можно автоматизировать тестирование того, что View (а именно View должна отвечать за создание эти блоков) наполняет объект pageInitVars значениями. Короче говоря, мы хотим защититься от Null Reference Exception в клиентском коде.
Можно создавать тест для каждого представления и перечислять в нём переменные для клиентского кода, который оно должно инициализировать, а можно — держитесь крепче — найти в клиентском коде, связанном с данным представлением, все обращения к pageInitVars и протестировать, что View эти значения передаёт через ViewModel. Мне кажется, что это довольно простая задача. Заниматься парсингом JavaScript кода не обязательно. Достаточно искать все вхождения pageInitVars, или другого объекта с более удачным названием, смотреть на то, что идёт после точки, например pageInitVars.nextPageUrl и проверять есть ли этот Url во ViewModel. А что вы думаете по этому поводу? Тестируете ли вы клиентский код таким образом?
