ASP.NET — пути для javascript

На первом этапе знакомства с ASP.NET был я сильно удивлен непродуманностью управления путями к клиентским сценариям. По причине неизвестных мне особенностей самой технологии или ее разработчиков рендеринг корркетно обрабатывал только ссылки стилей при использовании значка корня «~». С javascript сценариями все было довольно плохо. в первый раз получилось их подрубить только при вводе относительного пути. Но при добавленнии masterpage и нескольких подпапок для страниц с разной логикой начался кошмар, поскольку никакого динамического преобразования путей к клиентским сценариям не происходило. Я проклинал Майкрософт, проклинал ASP.NET, проклинал всю команду разработчиков этой технологии. Прошерстив немного интернет я нашел выход. Для преобразования абсолютного урла в динамический правильный относительный путь можно воспользоваться методом ResolveClientUrl класса Controll. Собственно поскольку сама страница так же является контроллом пишем внутри аттрибута src:

<%= ResolveClientUrl("~/frontend/js/jquery-1.3.2.min.js") >

Вот что написано в официальной документации:

Метод ResolveClientUrl используется для возвращения строки URL-адреса, подходящего для использования клиентом для доступа к ресурсам веб-сервера, таким как файлы рисунков, ссылки на дополнительные страницы и т.д. URL-адрес, возвращенный этим методом, определяется относительно папки, содержащей файл источника в котором создан элемент управления. Элементы управления, которые наследуют это свойство, например и MasterPage, возвращают полный URL-адрес относительно элемента управления

Фаулер о замене метода

Иногда я сохраняю старый метод, но для обработки в нем привлекается новый метод. Это полезно, если метод объявлен с модификатором видимости public, а изменять интерфейс других классов я не хочу.

Мартин Фаулер

Стоит ли заниматься переименованием?

Стоит ли заниматься переименованием? Без сомнения, стоит. Хороший код должен ясно сообщать о том, что он делает, и правильные имена переменных составляют основу понятного кода. Не бойтесь изменять имена, если в результате код становится более ясным. С помощью хороших средств поиска и замены сделать это обычно несложно. Строгий контроль типов и тестирование выявят возможные ошибки. 

Запомните:

ПримечаниеНаписать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям.Очень важно, чтобы код сообщал о своей цели. Я часто провожу рефакторинг, когда просто читаю некоторый код. Благодаря этому свое понимание работы программы я отражаю в коде, чтобы впоследствии не забыть понятое.Мартин Фаулер

ECHO or PRINT

Вопрос который возникает у любого начинающего php программиста, когда он открывает для себя великую истину — «не все функции работают одинаково быстро», что быстрее print или echo? На самом деле любой мог бы сам это проверить. Но новичку эта идея не всегда приходит в голову.

Несколько коротких выводов из моего опыта и попутно упомяну несколько важных особеннностей:

  • быстрее echo, правда результат не назовешь стабильным. В моих экспериментах результат с единичным вызовом и множественной итерации сильно отличался
  • разница исполнения очень мала

поэтому плюньте и учитывайте только в действительно больших итерациях, правда и тут под вопросом, автор статьи по данной ссылке даже при 20 000 000 итераций добился лишь 0,16% выигрыша производительности. используйте то, к чему вы привыкли

Особенности:

  • print ведет себя как функция, то есть возвращает значение (int 1)
  • echo поддерживает вывод нескольких параметров разделенных запятой, что быстрее чем вывод с конкантинацией, который единственно доступен для print.