Разработчики и веб-дизайнеры ASP.NET Webforms: как взаимодействовать?

Я разработчик ASP.NET Webforms, и я сталкиваюсь с некоторыми проблемами, когда имею дело с дизайнерами.

Дизайнеры всегда жалуются на asp.net server controls. Они предпочли бы иметь HTML-файл и создавать cssфайлы вместе с необходимыми изображениями, чтобы идти с ними. Иногда, если этап проектирования выполнен заранее, я получаю html-файлы со связанными css-файлами, но тогда мы сталкиваемся со многими проблемами при интеграции дизайна с aspxфайлами (sever контролирует telerik ... и т. Д.).

О чем я хочу спросить:

• Как мне преодолеть эти проблемы? Дизайнеры предпочитают разработчиков php- и mvc из-за проблем с серверными элементами управления .net. Мне нужно знать, как правильно взаимодействовать с дизайнерами.
• Существуют ли какие-либо инструменты или приложения, чтобы предоставить дизайнерам визуализированные (html-страницы) страницы .aspx? Под этим я подразумеваю страницу во время выполнения, а не aspx в Visual Studio. Они используют Web Expression, но хотят, чтобы отображаемая страница также была в формате html.

Бывший дизайнер здесь превратился в Dev, и я тоже писался и стонал о веб-элементах управления. Честно говоря, дизайнеру гораздо проще настроить свои методы, чем разработчику .NET вникать в пользовательскую реализацию GridView, потому что дизайнер УСТАРЕЛ, что у каждого TD есть тег rel (или что-то еще).

Как очень мудро отметил Арсений Мурзенко, решение использовать Webforms - это выбор компании, который ограничивает часть контроля над HTML, одновременно обеспечивая некоторую эффективность в кодировании. Если компания не захочет пересмотреть (что они НЕ должны делать, чтобы угодить дизайнерам), тогда дизайнеры должны принять эту реальность. Вот несколько вещей, которые они могут сделать:

1) Стоп в зависимости от идентификаторов для чего-либо . Несмотря на то, что это поначалу казалось неправильным, я обнаружил, что жизнь стала намного проще, когда я все стилизовал с помощью классов (и, конечно, наследования). Прежде всего, это выровняло все мои веса селектора. В наследовании CSS ID превосходит CLASS. На самом деле было очень приятно иметь все в качестве дочернего и / или селекторного класса, и это немного упрощало определение порядка специфичности. То же самое в слое JS, это дало мне ноль боли, чтобы поменять мои селекторы на основе идентификаторов на селекторы на основе классов.

2) Научите их, во что преобразуются RadioButtonLists и CheckboxLists , вместе с Label = span, Panel = div и другими неочевидными элементами управления в html. То, как .NET отображает их в HTML, оказалось немного страннее, чем я ожидал, и мне было гораздо проще создавать экраны, когда я знал, как HTML выйдет из этих элементов управления.

3) Сделайте так, чтобы их дизайнеры НАПРАВЛЯЛИ НАПРЯМУЮ , а не на сырой HTML ( ! Важно ). Научите дизайнеров основам GridViews, ListViews и т. Д. Дайте им несколько фрагментов кода, чтобы вставить анонимную коллекцию объектов в элемент управления Grid / ListView. Если они могут изучать CSS, то они могут научиться копировать и вставлять этот код. Они могут использовать бесплатную версию VS Web Express, которая неплохо работает в CSS и JS. Эти фиктивные веб-проекты дадут дизайнерам возможность ввести некоторые элементы управления, а затем просмотреть исходный код, чтобы увидеть, как они отображаются.

4) Объясните, как тег FORM используется в .NET . Ранее об этом забыли, но дизайнер должен привыкнуть к тому, что обычно один тег FORM оборачивает всю страницу. Это изменяет поведение элементов управления, и вы не можете вкладывать теги FORM без действительно странных побочных эффектов. Убедитесь, что дизайнеры понимают это, иначе HTML-форма станет кошмаром для превращения в WebForms.

5) Держитесь подальше от тем и кожи . Несмотря на то, что .NET Framework имеет эти инструменты, помогающие стилизовать элементы управления в приложении, они неуклюжи и странны для обычных веб-дизайнеров, и я никогда не находил их достойными своего времени. Они кажутся хорошим инструментом для разработчиков, которые плохо разбираются в CSS, но только замедляют работу дизайнеров. Пусть дизайнеры работают в своей естественной среде (файлы html и css), и они будут счастливее и продуктивнее.

6) Храните «прототип» проектов на вашем сайте . Чтобы убедиться, что у разработчиков всегда есть цель для кода, попросите дизайнеров создать фальшивый веб-проект в вашем реальном решении, чтобы настоящие разработчики сохраняли и не затрагивали свои страницы только для ASPX. Это означает, что дизайнеры могут оглянуться на свои прототипы в том же решении, что и настоящий проект, чтобы проверить, как разработчики сделали, и разработчики могут запустить прототип в любое время, чтобы убедиться, что их работа соответствует замыслу дизайнеров.

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

В конце концов, не было НИКАКОГО ДИЗАЙНА, КОТОРОГО Я ПРИШЕЛ ПО СВОЕМУ, что я не мог лично сделать работу в WebForms, даже если бы я закончил ругаться с этим проклятым GridView в течение часа, прежде чем понять это.

Существуют ли какие-либо инструменты или приложения, чтобы предоставить дизайнерам визуализированные (html-страницы) страницы .aspx?

Забудь о выражении (мне это никогда не нравилось). Получите им бесплатную версию Visual Studio (Web Developer Express). Он может подключиться к любому решению управления исходным кодом, которое у вас есть, и позволит дизайнерам запускать свои ASPX-страницы и видеть отображаемый HTML в браузере. Инструменты CSS и JS намного лучше, чем раньше, и есть несколько замечательных инструментов, встроенных в такие расширения, как Web Essentials. Преобразование CSS-правил в один клик во все их отклонения, характерные для разных поставщиков, палитры цветов и палитры прямо в интерфейсе VS, встраивание изображений в INS-файлы в один клик, CSS-преобразования «LESS» (вы можете «кодировать» в CSS), F12 «Навигация к» на JavaScript, плюс реальная интеллигентность и многое другое. Это сокровище для дизайнеров, FYI,

Есть решение ваших проблем, но оно предполагает изменение шаблона проектирования на MVP . Это предварительное вложение времени, которое требует серьезного рассмотрения перед началом.

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

Это очень всеобъемлющая тема, в которой есть смысл рассматривать образец как пример из жизни. Вы найдете этот пример довольно информативным для вашего случая - « Лучшие веб-формы с шаблоном MVP» .

Изменить: Если вышеупомянутое предложение слишком дорого (с точки зрения времени и ресурсов) следовать, я бы определенно посоветовал поработать с вашим дизайнером поближе . Я действительно считаю, что информирование о ваших проблемах в команде должно в значительной степени помочь устранить препятствия в вашей работе (дизайнера и разработчика). Это командная работа, и удачное совместное решение вопросов для устранения всех препятствий для выполнения работы - это способ добиться успеха в проекте в команде ! Это то, что мы делаем в нашем проекте.

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

Заинтересованные стороны должны решить: либо вы используете элементы управления ASP.NET с их сильными сторонами и недостатками, либо переходите на ручной HTML (или на ASP.NET MVC), увеличивая стоимость текущего проекта на тысячи долларов. ,

Неспособность настроить HTML в этом контексте является ограничением, как и любой другой. Дизайнеры должны учитывать это техническое ограничение в своей работе. Случай очень похож на случай, если дизайнер скажет вам, что текст должен отображаться точным шрифтом с точным размером: это веб-поддержка, а не печать, что означает, что размер текста будет меняться.

Что касается инструментов, я не знаю инструментов, которые преобразуют простой HTML в шаблон ASP.NET. Как можно предположить, что конкретная таблица должна быть преобразована в определенный элемент управления ASP.NET?

На моей последней работе разработчики создавали приложение, а затем передавали его проектировщикам, чтобы они могли выглядеть так, будто куча программистов этого не делали. :)

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

Я сел с каждым дизайнером и научил их, как установить веб-приложение на их локальную коробку. Я показал им, как запустить его и все. Я объяснил, как элементы управления asp отображаются на экране. А затем мы открыли его в браузере и использовали firebug, чтобы увидеть связь между элементами управления asp и тем, что было отрендерено.

Это им очень помогло. Как только они увидели его, запустили на своих коробках и использовали инструменты дизайна для настройки и игры со стилями, это облегчило их жизнь.

После этого я встретился с разработчиками и сообщил им, что они должны использовать тег CssClass и убедиться, что стили определены. И что-либо, что динамически выводилось на экран, должно иметь присоединенный к нему класс css, потому что дизайнеры не смогут его добавить.

Это был процесс. Обе стороны привыкли к тому, что договорились. Но это открыло линии связи. Вместо того чтобы жаловаться на используемые элементы управления, дизайнеры смогли запросить добавление стилей к различным элементам.

Поэтому я бы хотел посидеть с дизайнерами и показать им, как отображается страница. Используйте Firebug, чтобы проанализировать страницу и пройти через страницу, если она сформирована.

Вот несколько полезных подходов, которые я использовал в прошлом для дизайнеров, когда им приходится работать над разрабатываемым проектом веб-форм ASP.NET.

1. Развертывание локально: разработчики предоставляют промежуточную версию проекта, развернутую локально. Это экономит время для обоих. Дизайнер запрашивает .aspx, но взаимодействует с отображаемым HTML, а не с кодом сервера. Этот подход абстрагирует серверный код от дизайнера. Ему не нужно знать , как генерируется HTML или как javscript и cssфайлы доставляются клиенту. Это, конечно, предполагает, что дизайнеры имеют опыт работы с отладчиками браузера / инспектором DOM. Дизайнер может применить все свои cssизменения в браузере, а затем применить их к cssфайлам.
2. Предоставление моделей. Чтобы конструкторам было удобнее работать с HTML, предоставьте им модель HTML, отображаемую серверным элементом управления. Они могут настроить HTML так, чтобы им понравилось, и предложить изменения, которые будут применены в реализации на стороне сервера. Это нужно делать рано и часто , потому что вы не хотите в конечном итоге иметь HTML-структуру, на которую опирается реализация на стороне клиента, а затем проектировщик предлагает внести изменения в эту структуру.

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

Я, как гибридный разработчик (выполнив большую работу как с серверными, так и с внешними ролями, часто вместе), имею давнюю неприязнь к модели ASP.NET WebForms ... в то время как она изначально Стимулом дизайна было предоставление простых инструментов перетаскивания для демократизации веб-разработки (так же, как Visual Basic сделал программирование приложений доступным для не-CS-Major), методы, которые он использовал, чтобы попытаться навязать состояние Окружающая среда без состояний (веб) неуклюжая и вынужденная (о ViewState, как я тебя ненавижу!).

Они также нарушают некоторые из основных принципов разработки и стилизации разметки, просто потому, что ASP.NET по умолчанию принимает атрибут ID, заставляя дизайнеров CSS использовать классы так же, как должны были использоваться идентификаторы, наложение элементов в глубоких стопках элементов div и вложенных тегов, которые могут сделать стилизацию элементов управления кошмаром во всех, кроме самых упрощенных систем.

Учитывая эти вещи, ваш путь не из легких, так как я предполагаю, что переписывание для MVC было бы непомерно дорогим или временным.

Есть ли способ предоставить дизайнеру среду, в которой можно запускать веб-приложение, чтобы они могли видеть свои изменения CSS в режиме реального времени? Когда я занимаюсь проектированием в ASP.NET WebForms, я нахожу бесценным возможность запускать веб-приложение на моем собственном компьютере, вносить изменения в CSS и запускать его локально, чтобы увидеть, как это влияет на приложение.

Одним из вариантов может быть установка виртуальной машины, специально предназначенной для разработки ASP.NET, которую дизайнер может запускать со своей рабочей станции, чтобы им не приходилось смешивать два набора инструментов, и если им случалось что-то испортить в разработчике. пространство, оно всегда может быть перезагружено из функционирующего образа.

Да, это означает, что дизайнеру придется научиться нажимать клавишу F5, чтобы запустить приложение. (Или просто предоставьте им доступ по FTP к каталогам, где CSS, JS и изображения, даже в тестовой среде!) Это также означает, что они увидят много внутреннего кода, хотя, если вы скажете им просто игнорируйте ваши файлы .cs или .vb, это поможет избежать их паники ... Конечно, это означает, что вы должны быть уверены, что вы не будете делать такие вещи, как установка стилей из ваших файлов кода. (но вы бы этого не сделали, не так ли, поскольку это связывает данные и просматривает их слишком внимательно, верно?).

Если ваш сайт хорошо структурирован, с различными файлами CSS и JS, и в разметке не требуется много встроенных стилей, возможно, они смогут выполнить большую часть своей работы, просто избегая областей <%%>. С другой стороны, это может также дать разработчику немного больше понимания того, через что вы должны пройти, пытаясь перевести их статический HTML / CSS во что-то, что работает для динамического приложения.

Вы должны заставить их говорить вместе, понимать потребности и предпочтения друг друга. Это «проблема», которая не может быть решена с помощью программного обеспечения и инструментов. Не пытайтесь угодить обеим сторонам, это никогда не сработает. Им нужно идти на компромисс - это как брак.

Одним из способов является организация f.ex. семинары, на которых у каждой стороны есть возможность объяснить, почему они предпочитают то, что предпочитают. Хорошее общение всегда является ключом в подобных ситуациях. Подобные сборы можно рассматривать как инвестиции.

Или, проще говоря, проблема ориентирована на организацию, а не техническую, и именно здесь вам нужно предоставить решение.

Другой вариант - повысить зарплату и попросить их заткнуться (обычно это краткосрочное решение ...).