Как обеспечить простое редактирование главных страниц ASP .NET для дизайнеров?

Question

Сценарий: У меня есть довольно стандартная главная страница для всех моих страниц. Он включает в себя обычные формы входа и другие динамические списки для извлечения на каждой странице. Веб-дизайнеры уже могут изменять центральный заполнитель содержимого каждой страницы. Но, тем не менее, дизайн и макет главной страницы все еще в моем проекте, и любые изменения в дизайне должны быть сделаны в Visual Studio, а проект перекомпилирован и повторно развернут.

Каков наилучший способ обеспечить почти полный доступ к разработке главной страницы через CMS? Некоторые из проблем, которые я могу определить, - это включение каких-либо динамических списков или определенных элементов управления, таких как форма входа.

Спасибо.

Answer 1

Хотя это не ответ CMS, у вас есть возможность разрешить дизайнерам открывать главные страницы в Expression Web. Я не скажу, что это величайший инструмент в мире, но у меня были дизайнеры, которые работали над дизайном главной страницы в Expression с хорошими результатами.

Однако есть болевая точка. Если весь проект открыт, дизайнер увидит код за файлами как отдельные элементы, а не как древовидное представление в Visual Studio.

Я полагаю, вы могли бы проверить главную страницу для использования с Expression через CMS, но нет встроенного способа сделать это, и при этом я не знаю стороннего инструмента для этого. Надеемся, что Expression Web 3 облегчит эту задачу.

Answer 2

Если у вас есть CMS, возможно, вам лучше предоставить ей полный контроль над содержимым страницы. Если есть вещи, которые CMS не может сделать, вы можете написать расширения или модули плагинов для CMS, которые ваши дизайнеры могут затем перетащить на страницу в редакторе страниц CMS.

Если ваша CMS не поддерживает подключаемые модули, возможно, вы пытаетесь заставить CMS и главные страницы выполнять действия, для которых они не предназначены.

Если вышеизложенное не работает в вашей ситуации, вот еще одна мысль: разместите встроенные фреймы на главной странице, на которых размещаются страницы, которые редактируются в CMS.

Надеюсь, это поможет.

Answer 3

Это действительно интересный вопрос, и идеального решения не существует. Я работал над этим вопросом в интернет-магазине и, честно говоря, во многих случаях я просто просил дизайнеров предоставить мне html и css, а затем я взял бы кусочки html и css и добавил их в свой проект. Да, это было утомительно ....

Затем мы создали cms, где дизайнеры могли копировать и вставлять свои html в редакторы html, и мы сохраняли эти html в базе данных. Мое веб-приложение получит их из базы данных во время выполнения. Это решает некоторые проблемы, но не все, поскольку не дает им полного контроля над дизайном веб-страницы.

Суть в том, что вам нужно определить, как дизайнер представит вам свою работу. Если у вас есть это, и вы можете рассчитывать на html и css, тогда вы можете подумать о возможном построении CMS вокруг этого. В наши дни RAD мне было проще работать с html и css, доставленными мне, и просто копировать и вставлять фрагменты в мою главную страницу и другие страницы по мере необходимости.

Answer 4

Если вы не хотите разместить свой контент на портале, я не знаю идеального ответа на этот вопрос.

Если разряды, которые они проектируют, равны внешнему виду страницы, тогда это может контролироваться css, и вы можете позволить им создавать темы, используя разные файлы css.

Answer 5

.master - это просто текстовый файл. Они могут редактировать его так, как им нравится. Они, безусловно, ничего не сделают с этим, что потребует от вас перекомпиляции кода только для его просмотра. В первую очередь это большая победа с Master Pages: дизайнеры и другие непрограммисты могут редактировать их вручную, ничего не нарушая.

Дайте им доступ к файлу под контролем исходного кода и дайте им сойти с ума.

Answer 6

Возможно ли, чтобы вы разместили заполнители на главной странице вместо областей, которые дизайнеры должны редактировать? Поскольку мастер-страницы доступны для редактирования только в Visual Studio, на данный момент это может быть единственным возможным вариантом. Одна из проблем этого подхода заключается в том, что контент, помещенный в заполнители, вряд ли будет действительным, поскольку у вас, вероятно, будут теги оставаться открытыми в одном заполнителе и закрыты в другом.

<html>
<head>
<title></title>
<asp:PlaceHolder ID="headerContent" runat="server"></asp:PlaceHolder>
</head>
<body>

<asp:PlaceHolder ID="beforeContent" runat="server"></asp:PlaceHolder>

<asp:PlaceHolder ID="centralContent" runat="server"></asp:PlaceHolder>

<asp:PlaceHolder ID="afterContent" runat="server"></asp:PlaceHolder>

</body>
</html>

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

Мысли

РЕДАКТИРОВАТЬ: Это не будет работать. PlaceHolder будет отображать <div> тегов, которые могут испортить ситуацию. Может быть, вы могли бы расширить PlaceHolder и переопределить, как он отображает свой HTML.

Answer 7

Интересный вопрос,
Сам баловался в этой области некоторое время назад.

Насколько осведомлены эти веб-дизайнеры, когда они не в сфере Photoshop или Flash?

Если вы используете DIY-CMS, возможно, вы сможете шаблонировать наиболее восприимчивые объекты, например, e. г. составление общего (как и в любом другом месте) списка, а также способа ввода дизайна, если это применимо.

Пока у вас настроена полная среда, которая работает с атрибутами, доступными для дизайнеров через CMS, перекомпиляции не нужно, но, конечно, я легко могу увидеть разработчика ( читаю: мне) камень в пропасть безмятежного совершенства ....

Боюсь, что самый простой и единственный управляемый путь - стандартизировать то, как дизайнеры выражают свои потребности и желания для вас ... это просто не закодирует саму себя ...

Не могли бы вы привести несколько примеров?

Answer 8

Что ж, с проектом веб-приложения страницы не компилируются до получения доступа (ссылка 2005, но она все еще применяется). Это означает, что фактическая страница .aspx (и .ascx и т. Д.) Развернута в исходном состоянии. Дизайнер может обновить формат страницы на сервере, и обновления будут скомпилированы при следующем запросе этого содержимого.

Было бы относительно тривиально разрешить дизайнерам загружать текущие страницы и загружать замены через пользовательский интерфейс вашего сайта. Тем не менее, это не очень безопасно (и, вероятно, никогда не должно быть сделано). Было бы лучше разрешить разработчикам доступ к виртуальному каталогу через Интернет, чтобы они могли подключиться к нему с помощью такого инструмента, как Expression Web . Таким образом, дизайнер может открывать текущий веб-сайт, редактировать страницы и отправлять результаты непосредственно в производство (страшно, но это может показаться).

---

Поскольку я получил отрицательный ответ за правильный ответ, позвольте мне кое-что указать.

Проекты веб-сайтов компилируют код и страницы по запросу. Если вам нужно регулярно обновлять код, это хорошее решение.

Проекты веб-приложений можно настроить на обновление. Весь код и классы компилируются в сборку, а все страницы aspx, ascx и т. Д. Развертываются и компилируются по требованию. Это означает, что дизайнер может подключиться к веб-сайту, обновить макет и статический контент и увидеть изменения в следующем запросе.

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