Профессиональная разработка Web-приложений.  
Боишься нашего дизайна?
Новости
PDF журнал
Участники проектa
Сотрудничество
Ссылки
Карта сайта
Комментарии
Комментарии к статье
Добавить комментарий
Обсудить на форуме
Информация об авторе
Оценка статьи

Как поладить дизайнеру с программистом

Продолжение темы применения XML+XSLT в веб-проектах

Продолжение темы дизайнеров, программистов и XSL, который должен бы их связывать, но так пока и не может.

Понятно, что XSL - это небольшой язык программирования, который неопытные программисты глубоко освоить не могут. Если для программиста XSL - это ещё один роман, то для верстальщика - проблема. Но давайте не будем кидаться определениями. Вместе с программистами и дизайнерами могут работать также верстальщики и кодеры.

Разделим технологии на несколько ступенек:

  • дизайн - графические пакеты
  • HTML
  • сопутствующие HTML языки - JavaScript, VB Script, CSS
  • XSLT
  • PHP
  • настройка и администрирование сервера

Автор предыдущего материала работает в фирме, где есть только программисты и дизайнеры. При этом дизайнеры имеют широкие обязанности - не только делать рыбу в HTML, но и вставляют форматирование в код. Обязанности распределяются следующим образом:

дизайнHTMLJS, VBS, CSSPHPсервер
 программист
дизайнер 

Схема дизайнер-верстальщик-программист. Здесь дизайнер не знает HTML, либо знает на слабом уровне. Макеты форматирует верстальщик. Программист занимается скриптами и сервером. Структура, свойственная большим фирмам.

дизайнHTMLJS, VBS, CSSPHPсервер
 программист
 верстальщик 
дизайнер 

В совсем больших фирмах среди программистов выделяют также кодеров.

дизайнHTMLJS, VBS, CSSPHPсервер
 программист
 кодер 
 верстальщик (есть ли?) 
дизайнер 

Разговоры о том, что дескать ни верстальщик, ни дизайнер не знают и не захотят изучать XSL, бессмысленны. Проблемы начинаются из-за неправильного распределения обязанностей.

Пытаемся сделать сайт на XML+XSLT, отводим под это экспериментальный или малозначимый проект, делаем соответствующую организацию этого проекта (плохую то есть). Потом, когда ничего не работает, никто не может сделать то, что нужно, оставляем затею с XSL, переделываем всё старыми испытанными способами. После этого пишем заметки или пинаем меня.

А в начале надо ответить для себя на вопрос: надо ли пробовать делать сайт на XML+XSLT? Если вы, не дай бог, ответили "да", то молитесь! Шутка.

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

Проще всего с применением XSL будет большим фирмам, где программисты разделяются на разработчиков и кодеров. Превращение HTML-рыбы и образца XML-документа в работающий XSLT-лист - работа именно по части кодера. На первой схеме я поместил XSL между "приладами" HTML и PHP - и идея поручить XSL кодеру в эту схему красиво вписывается (сперва предположил про кодера, а схему нарисовал потом, честно! :).

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

Другая фирма: дизайнер рисует макет внешнего вида страницы, остальное делают несколько программистов. Парни эти - мастера на все руки, причём очень высокого уровня. Над одним проектом работает один человек. Тоже нет смысла применять XML, потому что одному человеку, наверное, проще разобраться в одном программном "слое" - php смешанном с HTML, - чем с двумя или тремя (php + шаблон XML + XSL). Выводы:

  • XML+XSL применимы там, где есть разделение труда
  • где разделение труда хорошо организовано
  • проект соответствующего масштаба (мелкий можно и в виде HTML смешанного с PHP, для крупного XSL тоже не очень подходит)




For comment register here
   Unknown 2002-06-03 19:43
Я бы еще сказал, что XML+XSL очень хорошо будут работать на разных content managers. Там где требуется полностью отделить код от дизайна. В принципе не важно РНР это или ASP или CFML. Главное это идея. И то что это все таки стандарт. Что тоже значительно упрощает поддержку готового приложения жругими програмистами. (В отличии от многочисленных классов шаблонов)

   2002-06-20 11:06
по поводу выводов: пункт 1, 2 - согласен
пункт 3: я его несколько раз прочитал, так и не врубился - это почему же XSL не для крупных проектов?
а на фига он нужен в домашних страницах?
а так все хорошо начиналось...

   Unknown 2002-06-20 11:59
Насчёт того что не для крупных проектов - это, конечно, спорно. Здесь я просто ретранслировал мнение одного человека, который работал в крупных проектах, и кому доверяю.

   2003-11-24 00:35
В связке программист-дизайнер нашли решение следующее: дизайнеру говорят - давай такой-то шаблон (или целая страница, или кусок HTML), а там, где будет контент, втыкай спец. теги.
Т.е. независимая работа идет.
Обработка тегов делается программно (например, на Си программма занимает 40 строчек).
Дальше программист на чем хочет, на том и пишет CGI.
Как вы понимаете, можно сделать и на php. Хотя микс кода с HTML в данном случае будет у программиста чрезмерен.
Это все годится для проектов не слишком больших. Т.е. максимум 20-25 разных динамических страниц, иначе нужны более совершенные технологии и бОльшая команда.
Данная технология HTML-шаблонов была успешно опробована на нескольких проектах.


   2005-02-03 11:08
По 3-му пункту скажу так: плохому танцору известно что мешает.
XSLT отлично подходит и для маленьких проектов, и для больших.
Вопрос всего навсего в правильной организации, наработанном инструментарии и уровне владения технологией.
До использования XSLT надо просто дорости.

   2005-04-16 07:57
Я сомневаюсь, что программист будет ответственен за сервер, для такого держут сисадминов, имхо это совершенно разные области...

Продолжение темы применения XML+XSLT в веб-проектах

 
 
 
    © 1997-2008 PHPClubTeam
[]