Боюсь, что если бы за это дело взялись советские стандартизаторы, то браузер в отечественном варианте назывался бы как-нибудь в стиле «ПДПИС» — «Программа для просмотра интернет-страниц». И были бы лолы в стиле «ЛПЗК» — «Лопата, покрашенная зеленой краской»
согласен на все 100, просто не всегда есть время и навыки делать такое с нуля. Я, вот, например, новичок в роботостроении (даже так — нуб :)), мне выгоднее показалось купить такую штуку, распотрошить и на её основе что-то делать. Конечно, её много с чем не сравнить :) тот же Lego Mindstorms, или то что приведено на ссылках выше
как в недавнем анекдоте: Письмо от друга из армии: «Нас тут учат убирать снег и варить картошку. Так что если враг нападет — мы ему дорогу расчистим и жрать приготовим».
когда учился в универе, у нас была военная кафедра, да… Была. Помню. Правда, если учесть маленький нюанс (набор 50 человек в год, условие — все пятерки на первом курсе, т.е. попасть туда можно только со второго курса отличником), то кафедры как бы и не было для 99% студентов.
От этого взорвется сервер или самопроизвольно зародится линукс? Еще в самом начале обсуждения я упомянул, что это не конкурс чистоты паттернов. Да, в MVC море стандартных возможностей, но изобретение велосипеда дело изобретателя, если мозг хочет разминки и руки чешутся, никто этого запретить не может.
Не сложнее чем тот же дополнительный кастомный хелпер. В общем понятно, я понял о чем вы говорите, буду копать в эту сторону, но в некоторых моментах лично для меня мой подход выгоднее и удобнее.
«Я же написал: инъекцией в глобальном фильтре. Контроллер тут не при чем»
если я правильно понимаю, ViewBag это динамическая коллекция. Если в фильтре я задам ViewBag.Test = 123
а в представлении напишу
<%=ViewBag.
то после точки IntelliSence мне ничего не подставит, т.к. ViewBag заполняется в рантайме. Так?
«Для этого masterpage, как уже писалось выше, можно передавать из контроллера, подставлять в глобальном фильтре, подставлять во viewengine. Ничего из того, что вы делаете, не нужно.»
Контроллеру абсолютно ничего не нужно знать про тему и про masterpage. Возможно, дизайнер вообще отказался от использования masterpage в данном представлении и он не нужен, а контроллер продолжает передавать ему ненужную информацию.
«Данные по теме пишутся во viewbag (инъекцией в глобальном фильтре), дальше пишется один хелпер, который достает эти данные (синтаксисом Html.Theme().Path), дальше эти данные *явно* используются в странице (т.е., для генерации пути к картинке делается Url.Content(string.Format(»{0}/Images/Logo.jpg", Html.Theme().Path))."
опять же во ViewBag писать нужно из контроллера. Контроллер не должен знать про тему.
насчет виджета да, варианты есть, не спорю. Можно вообще сделать свой server control и работать так: />.
приведу очень простую схему, которая используется в некоторых форумных движках:
Есть выбранная по-умолчанию тема сайта, есть тема, выбранная пользователем. Index.aspx не знает о том, какая тема выбрана, ему знать это и не надо. Ему автоматом подставляется нужный masterpage итоговой темы.
Пример 2. Есть основная тема сайта, есть маленькая «дочерняя» тема, которая отличается от основной только стилями Css и изображениями (к примеру), выходит некое наследование тем. Невозможно каждый путь к изображениям заключать в placeholder-ы, а стандартные Skin И Theme ASP.NET могут не устраивать по функционалу. В таком случае пути к ресурсам тем (например, картинка /Theme/Main/Images/Logo.jpg в masterpage прописывается как {ThemePath}/Images/Logo.jpg. Хелпер возвращает путь /Theme/Main/Images/Logo.jpg для основной темы, и /Theme/MainBlack/Images/Logo.jpg для дочерней.
Пример 3. У меня реализованы информационные блоки в представлениях. Грубо говоря, это отдельный usercontrol, с шапкой и телом, например как блок «Информация о блоге» в верхней части этой страницы. Виджеты дизайнер волен вставлять на странице в любую точку. Но нюанс в том, что виджеты могут быть разные от темы к теме, они могут блокироваться на определенных страницах. Обращаться к ним следует так <%=Helper.Widget(«name»)%>. Как предложите реализовывать их стандартными средствами, через зарегистрированный UserControl? А где тогда тут MVC? виджет это собственный маленький MVC, где Controller=объект виджета, View=представление для виджета, Model — отдельная модель для взаимодействия виджета и его представления.
Нюансов море, я еще не сделал и половины работы, но стандартные средства меня не устроили. А вот вы предложите вариант парсинга такого тегированного MasterPageFile с помощью кастомного Viewengine.
Да, скорее всего я ушел от чистого MVC, но ушел осознанно, т.к. мне не нравится подход, в котором модели необходимо передавать ВСЕ данные для отображения. Имхо это ничем не отличается от php-кода вида
<?php
echo ""
if (..) echo "1"; else echo…
?>
где все жестко забито без изменений. Чтобы что-то изменить, нужно лезть в код самого приложения, малейшее изменение в модели (необходимое дизайнеру) мгновенно затрагивает программиста, от чего я и пытаюсь уйти, предоставляя дизайнеру некую свободу действий. Да, не чистый MVC. Но мы не на соревновании чистоты паттернов.
Вы всегда точно знаете, где у вас лежит MasterPage? Или же параметр все-таки может зависеть от настроек, от выбранной темы, от выбранного стиля, от фазы луны....?
У меня как раз плавно звук музыки затухает, так что в настройках это есть. «Настройки -> Звук -> Затухание, кроссфейд и gapless».
Письмо от друга из армии: «Нас тут учат убирать снег и варить картошку. Так что если враг нападет — мы ему дорогу расчистим и жрать приготовим».если я правильно понимаю, ViewBag это динамическая коллекция. Если в фильтре я задам ViewBag.Test = 123
а в представлении напишу
<%=ViewBag.
то после точки IntelliSence мне ничего не подставит, т.к. ViewBag заполняется в рантайме. Так?
Контроллеру абсолютно ничего не нужно знать про тему и про masterpage. Возможно, дизайнер вообще отказался от использования masterpage в данном представлении и он не нужен, а контроллер продолжает передавать ему ненужную информацию.
«Данные по теме пишутся во viewbag (инъекцией в глобальном фильтре), дальше пишется один хелпер, который достает эти данные (синтаксисом Html.Theme().Path), дальше эти данные *явно* используются в странице (т.е., для генерации пути к картинке делается Url.Content(string.Format(»{0}/Images/Logo.jpg", Html.Theme().Path))."
опять же во ViewBag писать нужно из контроллера. Контроллер не должен знать про тему.
насчет виджета да, варианты есть, не спорю. Можно вообще сделать свой server control и работать так: />.
Есть выбранная по-умолчанию тема сайта, есть тема, выбранная пользователем. Index.aspx не знает о том, какая тема выбрана, ему знать это и не надо. Ему автоматом подставляется нужный masterpage итоговой темы.
Пример 2. Есть основная тема сайта, есть маленькая «дочерняя» тема, которая отличается от основной только стилями Css и изображениями (к примеру), выходит некое наследование тем. Невозможно каждый путь к изображениям заключать в placeholder-ы, а стандартные Skin И Theme ASP.NET могут не устраивать по функционалу. В таком случае пути к ресурсам тем (например, картинка /Theme/Main/Images/Logo.jpg в masterpage прописывается как {ThemePath}/Images/Logo.jpg. Хелпер возвращает путь /Theme/Main/Images/Logo.jpg для основной темы, и /Theme/MainBlack/Images/Logo.jpg для дочерней.
Пример 3. У меня реализованы информационные блоки в представлениях. Грубо говоря, это отдельный usercontrol, с шапкой и телом, например как блок «Информация о блоге» в верхней части этой страницы. Виджеты дизайнер волен вставлять на странице в любую точку. Но нюанс в том, что виджеты могут быть разные от темы к теме, они могут блокироваться на определенных страницах. Обращаться к ним следует так <%=Helper.Widget(«name»)%>. Как предложите реализовывать их стандартными средствами, через зарегистрированный UserControl? А где тогда тут MVC? виджет это собственный маленький MVC, где Controller=объект виджета, View=представление для виджета, Model — отдельная модель для взаимодействия виджета и его представления.
Нюансов море, я еще не сделал и половины работы, но стандартные средства меня не устроили. А вот вы предложите вариант парсинга такого тегированного MasterPageFile с помощью кастомного Viewengine.
<?php
echo ""
if (..) echo "1"; else echo…
?>
где все жестко забито без изменений. Чтобы что-то изменить, нужно лезть в код самого приложения, малейшее изменение в модели (необходимое дизайнеру) мгновенно затрагивает программиста, от чего я и пытаюсь уйти, предоставляя дизайнеру некую свободу действий. Да, не чистый MVC. Но мы не на соревновании чистоты паттернов.