Какова лучшая практика для отделения дизайна GUI от серверной разработки при разработке современных веб-приложений? - PullRequest
Новая
       5

Какова лучшая практика для отделения дизайна GUI от серверной разработки при разработке современных веб-приложений?

3 голосов
/ 11 марта 2010

В настоящее время мы разрабатываем несколько веб-приложений и позволяем нашим дизайнерам преобразовывать подписанные бумажные прототипы в статические веб-страницы. В дополнение к наличию гиперссылок между страницами дизайнеры начали добавлять вызовы jquery для обновления элементов на страницах путем извлечения данных из статических файлов json. Как только дизайнеры закончат и передадут готовые веб-страницы, файлы CSS и JavaScript; разработчики на стороне сервера затем редактируют страницы и заменяют ссылки на локальные статические документы json ссылками на живые URL-адреса json, которые возвращают те же структуры данных json.

Мой вопрос: Каковы эффективные способы отделения дизайна графического интерфейса от сервера и разработки и сокращения времени и усилий на интеграцию? Некоторые примеры:

  • У вас есть разработчики, чтобы вручную изменить каждую ссылку json на веб-страницах прототипов дизайнеров?
  • Добавляете ли вы где-нибудь глобальную переменную, чтобы позволить страницам дизайнеров легко переключаться между статическими и динамическими данными?
  • Делаете ли вы веб-страницы осведомленными, когда они запускаются с веб-сервера или просто обслуживаются из какой-то папки?

Ответы [ 3 ]

1 голос
/ 11 марта 2010

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

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

0 голосов
/ 11 марта 2010

Не совсем понятно, что именно является вашей средой (только обычный html? Или что-то вроде php?), Так что это немного выстрел в темноте ...

Если это обычный старый HTML +javascript, вы можете использовать javascript include на каждой странице, чтобы получить правильный набор адресов.Когда включаемый файл со всей этой специфичной для среды информацией (например, использовать локальный или использовать сервер) остается в одном и том же относительном месте, вам не нужно беспокоиться об изменении реальной страницы.Просто скажите парням с графическим интерфейсом всегда использовать один и тот же набор переменных для информации об адресе и определить информацию об адресе в этом включаемом файле.Переменная names не меняет, получаете ли вы локально или с сервера, только значения , хранящиеся в переменных.

У меня мало витаминного кофе,надеюсь, что это имеет смысл.

0 голосов
/ 11 марта 2010

Одна из вещей, которые я видел, довольно успешно работает для всей проблемы "url / path" (dev vs test vs production и т. Д.) - это создание поддомена для вашего проекта "proto" (так, proto.mycoolapp.company) .int) и послужит основой для всех URL-адресов, используемых в любом месте приложения.

Кроме того, используя любую платформу, которую вы используете, настройте глобальные обработчики страниц, чтобы идентифицировать раздел / страницу / функцию + [данные url] для всех ваших файлов данных (то есть вызовов json и т. Д.).

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

Например, скажем, у меня есть приложение с тремя разделами (вход в систему, управление учетной записью, предварительный просмотр). У меня будет служба URL для входа (данные, файлы и т. Д.) По адресу proto.mycoolapp.company.int/frontend/login/securelogin? пользователь = GrayWizardX. Команда UI может добавить их, так как они определяют потребность в данных, а ваша команда разработчиков приложений может видеть, какие функции запрашиваются (через журналы сервера и т. Д.), И убедиться, что все соответствует.

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

...