Как сделать проект JSP проще для дизайнера - PullRequest
0 голосов
/ 06 июля 2011

У меня есть веб-приложение Java / Spring MVC / JSP / JSTL.У нас есть дизайнер, который дал нам несколько страниц для начала, но он довольно отстал, поэтому нам пришлось создавать некоторые страницы самостоятельно, и, очевидно, по мере развития проекта другие элементы пользовательского интерфейса изменились.Я думаю, что одна из причин, по которой он стоит, заключается в том, что ему трудно работать с сайтом.

Мы не настроили для него среду разработки, потому что она включала бы базу данных, Eclipse и Tomcat на его коробке, и я волнуюсьчто мы потратим слишком много времени на поддержку его среды разработки, и он все равно ничего не сделает.С другой стороны, у него, по сути, уже был неудачный опыт, и я потратил время на то, чтобы забрать его изменения (просмотреть источник, изменить, отправить мне электронное письмо) и попытаться выяснить, что изменилось, и скопировать их обратно в файлы JSP.

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

Ответы [ 2 ]

3 голосов
/ 07 июля 2011

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

Разработчики должны создавать быстрые и грязные страницы со всеми необходимыми данными.Дизайнер, который силен в макете, должен затем превратить эти страницы в готовый продукт.Таким образом, существует хорошее разделение ответственности.Дизайнеру иногда потребуется работать в тесном контакте с разработчиками, чтобы получить данные в удобном для работы формате, но как только они уже созданы, работа в паре (программирование пара дизайнер / разработчик) иногда становится достаточно экономичной.

Если этот тип разработки будет нормой, то разработчик должен изучить интерфейс веб-приложения, так как он должен знать об инструментах, таких как сетка сайта, и свободно владеть несколькими библиотеками тегов JSP.

Если вы работаете с тяжелыми приложениями REST / ajax: тогда вы можете получить большее разделение задач, так как дизайнер может создавать страницы, когда разработчики предоставляют сервисы.Это может снизить потребность в полноценной среде разработки, но я не думаю, что это можно отрицать.Разработчик должен быть в состоянии прочитать базовый код, чтобы знать, что подвергается JSP для наиболее эффективной работы.

2 голосов
/ 07 июля 2011

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

Это в основном означает, что дизайнер отвечает за создание законченных, функционирующих страниц в чистом HTML. В идеале у дизайнера есть хороший старт на JSP-кодерах. Что дизайнер работал с проблемами навигации и т. Д.

Если на странице есть динамические элементы, то разработчик должен представить все правильные представления для кодировщиков JSP. Для этого может потребоваться несколько копий «одних и тех же» страниц, но каждая с разным динамическим представлением.

Разработчик должен делать заметки или использовать другие соглашения для определения на странице элементов, которые он считает динамическими (это может быть не только содержимое тега INPUT, но также и другие вещи, такие как ярлыки и т. Д.).

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

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

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

Например, если кодер вносит изменения, которые разбивают страницу, он может загрузить сгенерированный файл HTML на этот сервер, и он должен просто отобразиться так, как это сделала бы его страница JSP. Это позволяет каждому увидеть его «на месте». Дизайнер может даже исправить сгенерированный HTML-файл, если он считает, что это проще всего. Первоначальный кодер должен будет хранить старую копию, чтобы они могли выполнить различие, если они должны были найти изменения. Обычно эти изменения достаточно очевидны, если разработчик должным образом сообщит о них.

Еще один аспект заключается в том, чтобы в основном убедиться, что вы следуете действительно хорошим HTML-практикам, особенно семантической разметке, большому количеству CSS и т. Д.

Это связано с тем, что в настоящее время многие проблемы с HTML-страницами не так сильно размечены, как в CSS. Люди JSP обычно не должны работать с файлами CSS. Это позволяет конструктору вносить изменения на месте, чтобы вносить исправления гораздо проще. Он также поддерживает разметку как аккуратную и разреженную, насколько это практически возможно, опять же, это позволяет людям JSP легче отслеживать изменения в документах.

Если вы работаете с Ajax, тогда разработчик должен использовать «локальные» источники данных, которые можно легко заменить на «удаленные» источники данных. Это сохраняет код страницы неизменным и требует, чтобы JSP-кодеры просто меняли реализации источников данных, чтобы поразить их серверы, а не статические данные.

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

...