А можно поинтересоваться что в данном контексте он (StringBuilder ) даст? По моему создавать такой тяжелый экземпляр класса только для последовательной конкатации строк - это не практично. Есть какие-то особые причины?
Создать контрол на базе моего примера - дело техники. Что касается вашего класса: если вы используете Page, то зачем создавать свой dictionary, свою логику, а не использовать Page.ClientScript и методы которые я привел выше? К тому же, проверьте, что вам вернет Page.Server.MapPath(value)? Используйте ResolveClientUrl. Ну и если мне не изменяют мои глаза этот пример повыводит одни абсолютные имена файлов на сервере, вместо того, чтобы зарегистрировать в head нормальные link на js файлы.
Я тут подумал, еще вчера на Хабре каждый час постились интересные посты и комменты. А сегодня последние несколько часов ничего путного. Суперхабр съел мозги? Народ, давайте продолжать наполнять Хабр смыслом.
Не понял вопрос, не совсем понял зачем делать еще контрол. На всякий случай объясню ситуацию: есть контрол, этакий черный ящик. Он зависит от внешнего файла js. То есть разработчик контрола должен быть уверен, что когда другой человек поместит контрол на страницу, то связка с js произойдет. Первый "плохой способ" тупо прописывал ссылку в теле контрола и на этом мысль заканчивалась. Второй способ - это грамотная проверка наличия ссылки в head родительской страницы и добавление ее в случае отсутствия. Больше делать ничего не нужно будет.
Решение можно уменьшить на две строчки :) отказавшись от привязки к типу и обращаясь напрямую к Page.ClientScript.
Если серьезно, то лично у меня претензий к реализации нет. По моему проще и не сделаешь. Интересен другой факт. Подобного механизма в .net framework 1.0 просто не было. Похоже, что введение ClientScriptManager и множества прочих элементов касающихся клиентских скриптов, было произведено под давлением программистов, которым не смотря на всю силу asp.net все-таки нужны скрипты.
Я не знаю что и куда вы смотрите. Можете мне снижать карму, но вот реальный пример того, что я демонстрировал выше:
имеем страницу с двумя пользовательскими элементами, которые написаны "плохо" -
<form id="form1" runat="server">
<uc1:WebUserControl ID="WebUserControl1" runat="server" />
<br />
<br />
<uc1:WebUserControl ID="WebUserControl2" runat="server" />
</form>
имеем на выходе следующий html-текст:
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>
Не соглашусь насчет того, что var в данном контексте читается лучше. Считаю, что указание конкретного типа в foreach - это признак хороший тона хотя бы потому, что тогда контекст итераций будет самодостаточным. Разбирая в дальнейшем тело цикла не нужно будет искать определение tracks. Особенно это актуально для тяжелых циклов. Это мое личное мнение, дело вкуса. Я сам стараюсь использовать var в основном для промежуточного буфера. Например, когда LINQ-строка уже слишком длинная, но необходимо все же произвести еще какие-то действия типа ToList или Remove.
"НЛО не допустило вас для участия в эксперименте / UFO has not granted you access to experiment "
:(
Если серьезно, то лично у меня претензий к реализации нет. По моему проще и не сделаешь. Интересен другой факт. Подобного механизма в .net framework 1.0 просто не было. Похоже, что введение ClientScriptManager и множества прочих элементов касающихся клиентских скриптов, было произведено под давлением программистов, которым не смотря на всю силу asp.net все-таки нужны скрипты.
имеем страницу с двумя пользовательскими элементами, которые написаны "плохо" -
<form id="form1" runat="server">
<uc1:WebUserControl ID="WebUserControl1" runat="server" />
<br />
<br />
<uc1:WebUserControl ID="WebUserControl2" runat="server" />
</form>
имеем на выходе следующий html-текст:
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>
</title></head>
<body>
<form name="form1" method="post" action="CtrlTest.aspx" id="form1">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMTEzMzI4MzgwMGRkt+GZS8kLa3l7NAdBn5i0fy5gG2A=" />
</div>
<script src="../js/some_js.js" type="text/javascript"></script>
<input type="submit" name="WebUserControl1$Button1" value="Button" onclick="OnClick();" id="WebUserControl1_Button1" />
<br />
<br />
<script src="../js/some_js.js" type="text/javascript"></script>
<input type="submit" name="WebUserControl2$Button1" value="Button" onclick="OnClick();" id="WebUserControl2_Button1" />
<div>
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKh+eS/BgKMgeP0CQL93ZHkAejhGwbwXP0EMYcwQT7Qge5qGAXz" />
</div></form>
</body>
</html>
Нетрудно заметить что объявление скрипта задваивается. Можете сами проверить.
Хотел бы обратить внимание по этой теме на еще один вариант (более тяжелый, но и более полный) решения проблемы:
http://blogs.msdn.com/jmstall/pages/samp…
Здесь тоже самое реализовано без импорта DLL.