Комментарии 85
Если бы вас услышал хоть один верстальщик…
Когда присылают верстку под Drupal, то по любому приходится многое менять. Но когда есть такие требования, это делает процесс осознаннее.
В идеале, верстальщик должен быть ознакомлен с Друпалом, но когда присылают левую тему и требуют переделать под Друпал, то остается только надеятся на сознательность.
В идеале, верстальщик должен быть ознакомлен с Друпалом, но когда присылают левую тему и требуют переделать под Друпал, то остается только надеятся на сознательность.
ИМХО, отдельный этап «верстка», не совмещенный непосредственно с созданием рабочего шаблона, под такую сложную CMS как Друпал вообще по сути бессмысленен. Сначала верстальщик верстает, а потом все это с матами и кучем гемора по сути переделывается под Друпал разве что не с нуля… Может имеет смысл сразу брать некую базовую тему (ту же zen) и верстать сразу на нее? И разделить процесс тогда на две другие стадии: чисто верстка (то, что на том же zen'е можно сделать на чистом css и/или немного изменив tpl), а потом — конечный тюнинг, который делает уже кодер через функции темизации по четким указаниям верстальщика («сделай, чтобы вот здесь добавлялся лишний класс» и т.п.)
ну я имел опыт вёрстки сразу в тему, но не сказал бы, что это удобно и приятно. Ну и плюс я не могу успевать делать всю работу. Процесс надо разбивать на несколько человек. И в принципе если верстальщик по такого рода требования что-то делает, то вполне быстро можно прикручивать.
Мне вполне удобно переписать стандартные шаблоны в соответствии с обычной присланной вёрсткой. И код в итоге получается красивым и аккуратным. примеры: asatex.by stereolife.by pix.by
Так ведь качественнее ;)
Мне вполне удобно переписать стандартные шаблоны в соответствии с обычной присланной вёрсткой. И код в итоге получается красивым и аккуратным. примеры: asatex.by stereolife.by pix.by
Так ведь качественнее ;)
Посмотрел ваши примеры. Подобная верстка делается часа за 4, максимум — день. При разбивании процесса разработки на несколько людей вы на коммуникациях и сопутствующих затратах(время PM'a тоже денег стоит) потеряете больше.
Может, просто стоит нанимать более квалифицированных работников, чем содержать раздутый штат сотрудников?
Может, просто стоит нанимать более квалифицированных работников, чем содержать раздутый штат сотрудников?
только не zen =)
НЛО прилетело и опубликовало эту надпись здесь
Меня всегда интересовало, что же это такое «верстка под друпал, джумлу и т.п.». Так в чём прикол то, в наименовании классов, т.к. функции обращаются именно к таким классам?
Не функции обращаются. Модули CMS отдают HTML с предустановленными классами.
Так эти модули можно же спокойно редактировать и ставить туда свои классы, какие надо по верстке. Да и сами шаблоны пэйджеров, форм и т.п. можно редактировать как хочешь. Вобщем, считаю эту проблему верстки сайтов под разные движки надуманной.
А потом обновляем модули и начинаем хачить снова
Зачем хакать то? 0_0
А функции темизации на что?
Единственное придется, если модуль написан криво и не выполняет требования «весь html должен выводиться через theme функции» то имеет смысл задумать о том, нужен ли такой модуль.
А функции темизации на что?
Единственное придется, если модуль написан криво и не выполняет требования «весь html должен выводиться через theme функции» то имеет смысл задумать о том, нужен ли такой модуль.
Те, вы предлагаете, делать перекрывать стандартные theme, только из-за того, что вертальщие поленился называть классы, как они были в стандарте?
Я разве это сказал?) Или подумал?))
Нет конечно, гораздо проще в верстке стили переименовать, а темизировать только в более сложных случаях (когда например проще переопределить тему меню, чем с нуля пытаться его переверстать из-за другого html (что кстати порой без дополнительных элементов не получается и тут только theme в руки, вернее в template.php).
Я за разумный баланс того и другого)
Но вообще конечно в бытность работы в студии верстальщиков обязывал соблюдать конкретные правила верстки и именования файлов, классов и т.д. (хотя они были довольно плавающие из-за перманентной разработки корпоративноговелосипеда CMS).
Нет конечно, гораздо проще в верстке стили переименовать, а темизировать только в более сложных случаях (когда например проще переопределить тему меню, чем с нуля пытаться его переверстать из-за другого html (что кстати порой без дополнительных элементов не получается и тут только theme в руки, вернее в template.php).
Я за разумный баланс того и другого)
Но вообще конечно в бытность работы в студии верстальщиков обязывал соблюдать конкретные правила верстки и именования файлов, классов и т.д. (хотя они были довольно плавающие из-за перманентной разработки корпоративного
можно, но это в друпале не очень быстро.
Дело в том, что крайней не рекомендуется переписывать что-то прямо в коде самого друпаля или готовых модулей. Надо специфические для данного ресурса правки делать в отдельном модуле или теме. Т.е. если нам надо изменить класс, которым присваивается диву, внутрпи которого лежит пэйджер, то мы не открываем и правим готовую функцию, а скорее сперва её находим и потом в своей теме или модуле её переопределяем на нужный нам вывод. Т.е. скорее всего копируем функцию к себе изменяя её название и затем уже правим в ней то, что надо. И каждый элемент переопределять у себя не очень удобно. Тем более если это приходится делать не на одном проекте, а на многих и регулярно. Тогда полюбому начинаешь задумываться о том, чтобы этот процесс оптимизировать.
Я вобще удивлён почему тут такого рода оптимизация воспринимается в штыки и утверждается, что друпаль лажовый в этом плане. При разработке на других системах ведь тоже будет время разработки уменьшено если не надо будет каждый элемент переопределять…
Дело в том, что крайней не рекомендуется переписывать что-то прямо в коде самого друпаля или готовых модулей. Надо специфические для данного ресурса правки делать в отдельном модуле или теме. Т.е. если нам надо изменить класс, которым присваивается диву, внутрпи которого лежит пэйджер, то мы не открываем и правим готовую функцию, а скорее сперва её находим и потом в своей теме или модуле её переопределяем на нужный нам вывод. Т.е. скорее всего копируем функцию к себе изменяя её название и затем уже правим в ней то, что надо. И каждый элемент переопределять у себя не очень удобно. Тем более если это приходится делать не на одном проекте, а на многих и регулярно. Тогда полюбому начинаешь задумываться о том, чтобы этот процесс оптимизировать.
Я вобще удивлён почему тут такого рода оптимизация воспринимается в штыки и утверждается, что друпаль лажовый в этом плане. При разработке на других системах ведь тоже будет время разработки уменьшено если не надо будет каждый элемент переопределять…
ИМХО, что за CMS под которую нужно верстать не так как обычно… считаю что нужно искать проблему в CMS, верстальщика не должно волновать это, у него другая задача…
Вот только порпросить верстальщика сделать верстку под друпал проще, чем искать другой инструмент.
Но с кривостью инструмента согласен — логика не должна зависеть от отображения.
Но с кривостью инструмента согласен — логика не должна зависеть от отображения.
А логика и не зависит. Весть вопрос в том, что верстальщик напишет: [ul class='some-class'], а система стандартно выводит [div class='some-class'][ul]. В результате программисту надо будет переопределять вывод списка. Это не сложно, но это _лишняя_ работа, которую можно было не делать вообще, если следовать соглашениям принятыми в системе.
Если нужна аналогия: представьте, что у вас проект на ООП и вам присылают некий функционал написанный не на классах. Для интеграции вам придётся всё обернуть в нужные классы, создать методы, свойства и т.д. Сложно? Нет — рутинно. Этой работы можно было бы избежать, если бы вам сразу прислали реализацию на классах с соглашениями, принятыми в вашей системе.
Если нужна аналогия: представьте, что у вас проект на ООП и вам присылают некий функционал написанный не на классах. Для интеграции вам придётся всё обернуть в нужные классы, создать методы, свойства и т.д. Сложно? Нет — рутинно. Этой работы можно было бы избежать, если бы вам сразу прислали реализацию на классах с соглашениями, принятыми в вашей системе.
Меня, конечно, закидают помидорами, но вот мне не понятно зачем разделять работу рядовых PHP программистов и верстальщиков. Да, бывают проекты, где верстки огромное кол-во и ее надо внимательно планировать. В этом случае хороший верстальщик может быть полезен, но в остальных случаях можно огрести кучу потерь времени на связях между людьми.
Помню, была у меня подработка в виде верстки для какой-то студии. Так когда надо было в ней что-то поправить, ихние «программисты» даже 2 строчки в CSS заменить не смогли. Вот теперь и вопрос — была это лень или идиотские принципы «мы — не верстальщики»?
Помню, была у меня подработка в виде верстки для какой-то студии. Так когда надо было в ней что-то поправить, ихние «программисты» даже 2 строчки в CSS заменить не смогли. Вот теперь и вопрос — была это лень или идиотские принципы «мы — не верстальщики»?
> вот мне не понятно зачем разделять работу рядовых PHP программистов и верстальщиков
А может сразу заставить программистов тогда еще и дизайнить? И туалеты мыть?
Вы не думали, что программист — программирует. А верстать он может просто не уметь(хотя теорию html/css знает отлично при этом)? И ядерную физику с органической биологией он не знать может — но разве это его минус, как программиста?
А может сразу заставить программистов тогда еще и дизайнить? И туалеты мыть?
Вы не думали, что программист — программирует. А верстать он может просто не уметь(хотя теорию html/css знает отлично при этом)? И ядерную физику с органической биологией он не знать может — но разве это его минус, как программиста?
Неужели вы считаете разработку под готовую CMS настолько сложной?
Кроме того, вы по каждому мелкому багу будете бегать к верстальщику, вместо того, чтобы самому поправить? Это даже не смешно, когда WEB-программист не знает CSS и не может сверстать простенькую страницу.
Кроме того, вы по каждому мелкому багу будете бегать к верстальщику, вместо того, чтобы самому поправить? Это даже не смешно, когда WEB-программист не знает CSS и не может сверстать простенькую страницу.
Вопрос не в сложности, а в профессионализме. Верстальщик сделает вёрстку быстрее, а значит — дешевле. а мелочь и программист может сделать, безусловно.
Сколько потребуется времени, чтобы поставить задачу и верстальщику, и программисту? Каковы затраты на передачи результатов работы одного из них другому? Каковы будут затраты во время баг-фиксинга или просто при итерационной разработке? Насколько усложнится работа PM'a? Каковы будут провалы по эффективности когда программист будет ждать результатов работы верстальщика, что, безусловно, будет отвлекать его от работы?
> Сколько потребуется времени, чтобы поставить задачу и верстальщику, и программисту?
Столько же.
> Каковы затраты на передачи результатов работы одного из них другому?
А какие затраты? Для фриланса — пусть в IM общаются. В офисе — рядом сидят.
> Каковы будут затраты во время баг-фиксинга или просто при итерационной разработке?
Уменьшатся при разделении труда: профильная работа получается куда быстрее.
> Насколько усложнится работа PM'a?
Не изменится.
> Каковы будут провалы по эффективности когда программист будет ждать результатов работы верстальщика, что, безусловно, будет отвлекать его от работы?
Выигрыш — программист занимается своим делом и не лезет туда, где он не профи. Верстальшик соответственно не чаи пинает, а тоже занимается делом.
Я удовлетворил ваше любопытство?
Столько же.
> Каковы затраты на передачи результатов работы одного из них другому?
А какие затраты? Для фриланса — пусть в IM общаются. В офисе — рядом сидят.
> Каковы будут затраты во время баг-фиксинга или просто при итерационной разработке?
Уменьшатся при разделении труда: профильная работа получается куда быстрее.
> Насколько усложнится работа PM'a?
Не изменится.
> Каковы будут провалы по эффективности когда программист будет ждать результатов работы верстальщика, что, безусловно, будет отвлекать его от работы?
Выигрыш — программист занимается своим делом и не лезет туда, где он не профи. Верстальшик соответственно не чаи пинает, а тоже занимается делом.
Я удовлетворил ваше любопытство?
>> Сколько потребуется времени, чтобы поставить задачу и верстальщику, и программисту?
>Столько же.
А ничего, что обоим людям надо объяснять что надо делать? Ничего, что их работу нужно синхронизировать и координировать?
>> Каковы затраты на передачи результатов работы одного из них другому?
>А какие затраты? Для фриланса — пусть в IM общаются. В офисе — рядом сидят.
В IM один разговор — час рабочего времени. В офисе меньше.
>> Каковы будут затраты во время баг-фиксинга или просто при итерационной разработке?
>Уменьшатся при разделении труда: профильная работа получается куда быстрее.
Передача результатов, распределение задач.
>> Насколько усложнится работа PM'a?
>Не изменится.
+1 человек, + еще и связь между ними. Работа станет сложнее, PM требуется более высококвалифицированный.
>> Каковы будут провалы по эффективности когда программист будет ждать результатов работы верстальщика, что, безусловно, будет отвлекать его от работы?
>Выигрыш — программист занимается своим делом и не лезет туда, где он не профи. Верстальшик соответственно не чаи пинает, а тоже занимается делом.
Эта фраза вообще не в тему.
Каждое отвлечение от работы, в том числе на ЛЮБЫЕ разговоры, — это потеря производительности. И ответ на то, что экономически выгоднее для бизнеса — держать верстальщика или программиста с большими обязанностями, отнюдь не однозначен.
>Столько же.
А ничего, что обоим людям надо объяснять что надо делать? Ничего, что их работу нужно синхронизировать и координировать?
>> Каковы затраты на передачи результатов работы одного из них другому?
>А какие затраты? Для фриланса — пусть в IM общаются. В офисе — рядом сидят.
В IM один разговор — час рабочего времени. В офисе меньше.
>> Каковы будут затраты во время баг-фиксинга или просто при итерационной разработке?
>Уменьшатся при разделении труда: профильная работа получается куда быстрее.
Передача результатов, распределение задач.
>> Насколько усложнится работа PM'a?
>Не изменится.
+1 человек, + еще и связь между ними. Работа станет сложнее, PM требуется более высококвалифицированный.
>> Каковы будут провалы по эффективности когда программист будет ждать результатов работы верстальщика, что, безусловно, будет отвлекать его от работы?
>Выигрыш — программист занимается своим делом и не лезет туда, где он не профи. Верстальшик соответственно не чаи пинает, а тоже занимается делом.
Эта фраза вообще не в тему.
Каждое отвлечение от работы, в том числе на ЛЮБЫЕ разговоры, — это потеря производительности. И ответ на то, что экономически выгоднее для бизнеса — держать верстальщика или программиста с большими обязанностями, отнюдь не однозначен.
> Каждое отвлечение от работы, в том числе на ЛЮБЫЕ разговоры, — это потеря производительности.
Я — программист. Если мне будут говорить, что вёртка моего блока едет в опере, и я буду искать глюки в своей вёрстке и хаки для обхода, то это не повысит мою производительность как программиста. Программист я лучший, чем верстальщик, поэтому то что он будет делать 15 минуту, я буду делать час, условно.
И когда подкованный заказчик посмотрит в ведомость и скажет: «Вы чё, охренели на вёрстку столько времени тратить?! Да это работа делается в пять раз быстрее!», что мне ему ответить? Так выше производительность?
Я — программист. Если мне будут говорить, что вёртка моего блока едет в опере, и я буду искать глюки в своей вёрстке и хаки для обхода, то это не повысит мою производительность как программиста. Программист я лучший, чем верстальщик, поэтому то что он будет делать 15 минуту, я буду делать час, условно.
И когда подкованный заказчик посмотрит в ведомость и скажет: «Вы чё, охренели на вёрстку столько времени тратить?! Да это работа делается в пять раз быстрее!», что мне ему ответить? Так выше производительность?
Нет-нет. Вы получите порцию багов, часть из который будет по верстке, а часть по функционалу. И не отвлекаясь на коммуникации вы в спокойном режиме их все пофиксите.
Если верстальщик работает в 10 раз производительнее вас на небольших проектах, то это сигнализирует только о вашей низкой квалификации как web-developer'a.
> И когда подкованный заказчик посмотрит в ведомость и скажет: «Вы чё, охренели на вёрстку столько времени тратить?! Да это работа делается в пять раз быстрее!», что мне ему ответить? Так выше производительность?
Распишите эти цифры по другим пунктам.
При разделении труда так и будет, кстати. Быстрее верстается, но больше сопутствующих затрат, больше рисков (к примеру, больше риск болезни).
Если верстальщик работает в 10 раз производительнее вас на небольших проектах, то это сигнализирует только о вашей низкой квалификации как web-developer'a.
> И когда подкованный заказчик посмотрит в ведомость и скажет: «Вы чё, охренели на вёрстку столько времени тратить?! Да это работа делается в пять раз быстрее!», что мне ему ответить? Так выше производительность?
Распишите эти цифры по другим пунктам.
При разделении труда так и будет, кстати. Быстрее верстается, но больше сопутствующих затрат, больше рисков (к примеру, больше риск болезни).
> И не отвлекаясь на коммуникации…
Коммуникации по времени копеечны. Поставить галочку о переходе задачи к верстальшику это простите 5 секунд. Обсудить с верстальщиком переделку вывода — минуты.
> Если верстальщик работает в 10 раз производительнее вас…
Никто не говорит про «в 10 раз». В два раза — уже выигрыш по времени.
> Распишите эти цифры по другим пунктам…
Отличный подход!
Коммуникации по времени копеечны. Поставить галочку о переходе задачи к верстальшику это простите 5 секунд. Обсудить с верстальщиком переделку вывода — минуты.
> Если верстальщик работает в 10 раз производительнее вас…
Никто не говорит про «в 10 раз». В два раза — уже выигрыш по времени.
> Распишите эти цифры по другим пунктам…
Отличный подход!
> то это сигнализирует только о вашей низкой квалификации как web-developer'a.
А я не вебэникейщик. Я веб-программист. И верстать не умею. У меня есть свой верстальщик.
Проведите аналогию:
«Раз программист знаком с личной гигиеной, значит ему не сложно выдраить офисные сортиры за уборщицу.» — «Раз программист знаком с html/css, значит ему не сложно сверстать за верстальщика.»
А я не вебэникейщик. Я веб-программист. И верстать не умею. У меня есть свой верстальщик.
Проведите аналогию:
«Раз программист знаком с личной гигиеной, значит ему не сложно выдраить офисные сортиры за уборщицу.» — «Раз программист знаком с html/css, значит ему не сложно сверстать за верстальщика.»
Во-первых, давайте не будем проводить глупые и неуместные аналогии.
Во-вторых, давайте программисты физики игр не будут знать физику, программисты графических движков геометрию, программисты операционных систем работу процессоров, а веб программисты не будут знать о деталях HTTP протокола.
Список этот можно продолжать до бесконечности. Суть в том, что если вы умеете только настраивать сайты на одной CMS, то вы — никто. Никто как программист. Если вы можете написать еще и пару не очень сложных сервисов для back-end'a — все все равно ноль. И умение верстать тоже слабо говорит о профпригодности конечного человека.
Специалист только в одной области не может быть специалистом. Он не может взглянуть на проблему с других сторон и с точки зрения других уже готовых решений. Он не может понять особенности, которые будут актуальны для работы его коллег (хороший пример: связка дизайнер — верстальщик).
Если уж говорить о верстальщиках, то говорить имеет смысл о разработчиках интерфейсов. Которые и JS знают, и гайд-лайны для фирмы напишут, и свой html+css фреймворк сделают, и т.п., и т.п. Такие люди будут стоить больших денег, но и производительность всей фирмы смогут сильно повысить.
А обычных верстальщиков, которые только и могут говорить «семантичная верстка», «валидный html» и «таблицы для табличных данных», навалом. Только вот кому с них польза?
Вы, видимо, говорите о программистах-кодерах, которые сидят в офисах, как фермах, и пытаются что-то выдать. Так они профессионалами и не являются. Я же говорю о людях, которые постоянно развиваются, активно интересуются всем подряд и работают увлеченно.
Во-вторых, давайте программисты физики игр не будут знать физику, программисты графических движков геометрию, программисты операционных систем работу процессоров, а веб программисты не будут знать о деталях HTTP протокола.
Список этот можно продолжать до бесконечности. Суть в том, что если вы умеете только настраивать сайты на одной CMS, то вы — никто. Никто как программист. Если вы можете написать еще и пару не очень сложных сервисов для back-end'a — все все равно ноль. И умение верстать тоже слабо говорит о профпригодности конечного человека.
Специалист только в одной области не может быть специалистом. Он не может взглянуть на проблему с других сторон и с точки зрения других уже готовых решений. Он не может понять особенности, которые будут актуальны для работы его коллег (хороший пример: связка дизайнер — верстальщик).
Если уж говорить о верстальщиках, то говорить имеет смысл о разработчиках интерфейсов. Которые и JS знают, и гайд-лайны для фирмы напишут, и свой html+css фреймворк сделают, и т.п., и т.п. Такие люди будут стоить больших денег, но и производительность всей фирмы смогут сильно повысить.
А обычных верстальщиков, которые только и могут говорить «семантичная верстка», «валидный html» и «таблицы для табличных данных», навалом. Только вот кому с них польза?
Вы, видимо, говорите о программистах-кодерах, которые сидят в офисах, как фермах, и пытаются что-то выдать. Так они профессионалами и не являются. Я же говорю о людях, которые постоянно развиваются, активно интересуются всем подряд и работают увлеченно.
Программист физики ДОЛЖЕН знать физику.
Веб-программист ДОЛЖЕН знать CSS.
Программист физики не обязан выводить физические законы в лаборатории.
Веб-программист не обязан верстать.
Аналогия понятна?
> Специалист только в одной области не может быть специалистом.
Откройте словарь и прочитайте значение слова «специализация».
> Суть в том, что если вы умеете только настраивать сайты на одной CMS, то вы — никто. Никто как программист.
Полностью согласен. Но я обратного и не говорил.
> Вы, видимо, говорите о программистах-кодерах, которые сидят в офисах, как фермах, и пытаются что-то выдать. Так они профессионалами и не являются. Я же говорю о людях, которые постоянно развиваются, активно интересуются всем подряд и работают увлеченно.
Я говорю о специалистах. О тех, которые занимаются своим делом и полностью в нем компетентны. И смогут решить абсолютно любую задачу в пределах своей специализации.
Остальные их параметры типа «офисности», креативности, увлеченности, знания чужих областей не имеют роли.
Веб-программист ДОЛЖЕН знать CSS.
Программист физики не обязан выводить физические законы в лаборатории.
Веб-программист не обязан верстать.
Аналогия понятна?
> Специалист только в одной области не может быть специалистом.
Откройте словарь и прочитайте значение слова «специализация».
> Суть в том, что если вы умеете только настраивать сайты на одной CMS, то вы — никто. Никто как программист.
Полностью согласен. Но я обратного и не говорил.
> Вы, видимо, говорите о программистах-кодерах, которые сидят в офисах, как фермах, и пытаются что-то выдать. Так они профессионалами и не являются. Я же говорю о людях, которые постоянно развиваются, активно интересуются всем подряд и работают увлеченно.
Я говорю о специалистах. О тех, которые занимаются своим делом и полностью в нем компетентны. И смогут решить абсолютно любую задачу в пределах своей специализации.
Остальные их параметры типа «офисности», креативности, увлеченности, знания чужих областей не имеют роли.
> А ничего, что обоим людям надо объяснять что надо делать?
И? Или вы имеете ввиду не программист-верстальщик + верстальщик, а просто программист-верстальщик? о_О
> В IM один разговор — час рабочего времени.
Несколько постов: «надо сделать ххх в ххх» — «типа ххх в ххх?», «ага»… «держи», «спасибо большое»
И? Или вы имеете ввиду не программист-верстальщик + верстальщик, а просто программист-верстальщик? о_О
> В IM один разговор — час рабочего времени.
Несколько постов: «надо сделать ххх в ххх» — «типа ххх в ххх?», «ага»… «держи», «спасибо большое»
Есть команда — менеджер, программист, верстальщик.
Менеджер ставит задачу — вывести список игроков в блэкджек, программист задачу принимает, выводит список и направляет задачу верстальщику. Верстальщик верстает. Тестирование, новый виток.
Обычный workflow. Что необычного?
Менеджер ставит задачу — вывести список игроков в блэкджек, программист задачу принимает, выводит список и направляет задачу верстальщику. Верстальщик верстает. Тестирование, новый виток.
Обычный workflow. Что необычного?
ну сегодня мелкий баг вылез, я его поправил. завтра тоже и я тоже поправил, а потом вылазит мега большой баг и отправляется на доработку верстальщику. и тогда стоит вопрос: либо выбирать свои изменения из кода и отдавать ему или же он сам всё делает и потом применять снова свои исправления. И тот и тот вариант не удобен. Каждый должен делать свою работу.
Да, я считаю разработку под готовую CMS очень сложной.
Для верстальщика.
> Кроме того, вы по каждому мелкому багу будете бегать к верстальщику, вместо того, чтобы самому поправить?
Примитивные вещи типа «выделить заголовок жирным» делаю. Не более того. И не считаю зазорным попросить человека исправить работу.
> Это даже не смешно, когда WEB-программист не знает CSS и не может сверстать простенькую страницу.
Настолько же смешно, что веб-программист не может помыть свой кабинет, кабинет директора и отдраить сортир.
Для верстальщика.
> Кроме того, вы по каждому мелкому багу будете бегать к верстальщику, вместо того, чтобы самому поправить?
Примитивные вещи типа «выделить заголовок жирным» делаю. Не более того. И не считаю зазорным попросить человека исправить работу.
> Это даже не смешно, когда WEB-программист не знает CSS и не может сверстать простенькую страницу.
Настолько же смешно, что веб-программист не может помыть свой кабинет, кабинет директора и отдраить сортир.
Приведите примеры сложных с точки зрения верстки сайтов, пожалуйста.
Под разработкой для CMS я не имел ввиду только создание шаблона.
Я имел ввиду еще и впиливание чужих модулей, их доработку.
Это верстальшик не сможет.
Я имел ввиду еще и впиливание чужих модулей, их доработку.
Это верстальшик не сможет.
По-моему, я четко обозначил тезис: разработка под CMS не требует высокой квалификации. Вы возразили, что требует в случае верстальщика. В ответ на просьбу показать примеры ваших утверждений, вы пишите список работ, который, опять же, не требует высокой квалификации.
Если вы готовы вернуться в конструктивное русло — пожалуйста. Если вы хотите продолжать кидаться фразами, обусловленными неспособностью принять чужую точку зрения и слабыми представлениями бизнес-процессов, то я со спокойной душой ухожу из этого топика, т.к. ничего полезного для меня тут уже не будет, а изменять чье-то мнение — не моя задача.
Если вы готовы вернуться в конструктивное русло — пожалуйста. Если вы хотите продолжать кидаться фразами, обусловленными неспособностью принять чужую точку зрения и слабыми представлениями бизнес-процессов, то я со спокойной душой ухожу из этого топика, т.к. ничего полезного для меня тут уже не будет, а изменять чье-то мнение — не моя задача.
> По-моему, я четко обозначил тезис: разработка под CMS не требует высокой квалификации.
Прошлый раз был другой тезис.
Чтобы закрыть эту тему:
Для программиста это не требует высокой квалификации. Но не будет решена задача смены шаблона.
Для верстальщика эта задача невозможно т.к. де факто он знает лишь основы программирования и ему далеко даже для новичка.
> Если вы хотите продолжать кидаться фразами, обусловленными неспособностью принять чужую точку зрения и слабыми представлениями бизнес-процессов
Почему «продолжать»? Я исхожу просто из общепринятых определений и не называю вещи не своими именами.
Прошлый раз был другой тезис.
Чтобы закрыть эту тему:
Для программиста это не требует высокой квалификации. Но не будет решена задача смены шаблона.
Для верстальщика эта задача невозможно т.к. де факто он знает лишь основы программирования и ему далеко даже для новичка.
> Если вы хотите продолжать кидаться фразами, обусловленными неспособностью принять чужую точку зрения и слабыми представлениями бизнес-процессов
Почему «продолжать»? Я исхожу просто из общепринятых определений и не называю вещи не своими именами.
ровно на столько насколько сложна замена Lorem ipsum текста на
Напишу более конкретно: программирование — это решение задач в определенной области. Если вы пишите физику для игры, то должны на определенном уровне знать физику, если поисковый движок — соответствующую теорию, если делаете web сайты — верстку + js. Хочу заметить, что я НЕ говорю, что эти смежные области надо знать на высшем уровне.
Объем знаний для программирования рядового сайта настолько мал, что утверждать, что программист не должен знать верстку как-то… Попахивает нежеланием обучаться.
Объем знаний для программирования рядового сайта настолько мал, что утверждать, что программист не должен знать верстку как-то… Попахивает нежеланием обучаться.
Я и говорю: программст на определенном уровне должен знать CSS: на уровне теории. Этот тот уровень, который позволит ему работать с тем, что ему дал верстальщик.
Исправлять косяки верстки — не его работа. Если возникают вопросы — нужно просто попросить верстальщика поправить. Это проще, чем самому программисту ковыряться в непрофильной для него работе.
Исправлять косяки верстки — не его работа. Если возникают вопросы — нужно просто попросить верстальщика поправить. Это проще, чем самому программисту ковыряться в непрофильной для него работе.
или кучу времени потерять, когда программист, не зная определенных «трюков» верстки, будет ровнять блок 2 часа под ИЕ, ФФ, Сафари и т.п
Это ужасно, просто ужасно, когда в цээмэске зашиты какие-то ожидания, какие-то более или менее жесткие требования насчет того, какой должна быть верстка.
На мой взгляд это просто средневековье, пережиток и атавизм.
На мой взгляд это просто средневековье, пережиток и атавизм.
Нет, это стандарт, придерживаясь которого, можно избежать кучи проблем. Точно так же как и стандарты кодирования, комментирования.
Я говорю о том, что такая подход к изготовлению сайта (затачивание верстки) — это пережиток. Вы мне отвечаете, что такой способ подготовки верстки помогает избегать проблем (как я понимаю при изготовления шаблона для Друпала из этой верстки).
Одно другому не мешает и ваше «нет» здесь бессмысленно.
Задача дазайнера — все красиво задизайнить, задача верстальщика заверстать все красиво, удобно, кроссбраузерно и валидно. Когда я делаю интеграцию верстки с цмс, на выходе получается в точности то, что сверстано.
А вот эти все методы — единственный их сомнительный смысл это дать возможность построителю сайта вставить меню или другой блок (навигация по сайту, пейджинг или еще что-нибудь) «одним кликом». Потрудиться немного больше и прописать отдельные шаблоны для заголовка меню, активного пункта, неактивного пункта это уже черт побери слишком сложно. Нет, этот метод не для нас, давайте нагрузим верстальщика всякой фигней.
Одно другому не мешает и ваше «нет» здесь бессмысленно.
Задача дазайнера — все красиво задизайнить, задача верстальщика заверстать все красиво, удобно, кроссбраузерно и валидно. Когда я делаю интеграцию верстки с цмс, на выходе получается в точности то, что сверстано.
А вот эти все методы — единственный их сомнительный смысл это дать возможность построителю сайта вставить меню или другой блок (навигация по сайту, пейджинг или еще что-нибудь) «одним кликом». Потрудиться немного больше и прописать отдельные шаблоны для заголовка меню, активного пункта, неактивного пункта это уже черт побери слишком сложно. Нет, этот метод не для нас, давайте нагрузим верстальщика всякой фигней.
Из собственного опыта… Например нужно заскинить форму для Друпала. Пока я не попросил слайсера взглянуть на структуру дурупал формы, тратил образно говоря 3 часа на ее прикручивание. После того, как слайсер стал слайсить, используя предложенную структуру — форма прикручивается за 20 минут. При этом не увеличивается время на сам слайс. Помоему, выигрыш очевиден.
Очень вас понимаю и согласен, что если в Друпале есть требования к верстке, то понимание этих требований верстальщиком сильно облегчит интеграцию.
Но вот извиняюсь за такие слова, но в нормальной cms вообще не должно быть никакого «заскинения». Я беру страницу с формой которую сделал верстальщик, добавляю в нее некоторые hidden поля, чтобы движок сайта правильно обработал добавление или редактирование объекта, прописываю уже в cms-ке код, который должен выполняться при успехе или неуспехе и все, форма у меня работает.
Все оформление при этом работает точно также как в «голой верстке». В случае простой формы с 3-4 полями это 15-20 мин.
Но вот извиняюсь за такие слова, но в нормальной cms вообще не должно быть никакого «заскинения». Я беру страницу с формой которую сделал верстальщик, добавляю в нее некоторые hidden поля, чтобы движок сайта правильно обработал добавление или редактирование объекта, прописываю уже в cms-ке код, который должен выполняться при успехе или неуспехе и все, форма у меня работает.
Все оформление при этом работает точно также как в «голой верстке». В случае простой формы с 3-4 полями это 15-20 мин.
Что я хочу сказать, так это то, что если друпал предоставляет стандарт вывода формы, то кто бы ни взялся работать с проектом, всегда будет знать, как и где нужно темить вывод. В Вашем случае, формы разных слайсеров будут иметь разную структуру, что не есть хорошо.
ну ето не совсем чтобы требования… Возможно я не очень точно подобрал заголовок. Это скорее пожелания. Никаких проблем, чтобы верстальщик сделал как ему удобнее, а программист потом переколбасит вывод всех элементов. Это вполне можно сделать. Но зачем? Мы на друпале делаем в основном мелкие проекты, например промо-сайты, где время ограничено и надо максимально быстро всё сделать. Вот и ищутся способы по оптимизации рабочего процесса. Выставление кое-каких требований к верстальщику заметно ускоряет этот процесс, а значит это выгодно.
Время — деньги!
Время — деньги!
что за слайсер?
Скорее это можно назвать правилами по умолчанию, а на самом деле через theming api можно реализовать всё что угодно
тут не жесткие требования…
тут скорее предлагается использовать стандартный вывод модулей дабы минимизировать затраты времени на темизацию. Можно при желании заставить отдавать другой код…
а стандарты они есть. и на мой они вполне разумны — Theming Guide drupal.org/node/341707
тут скорее предлагается использовать стандартный вывод модулей дабы минимизировать затраты времени на темизацию. Можно при желании заставить отдавать другой код…
а стандарты они есть. и на мой они вполне разумны — Theming Guide drupal.org/node/341707
Эти требования не являются уникальными, предназначенными именно для друпала. Любой верстальщик, который умеет верстать шаблоны под разные CMS, придерживается этих принципов.
А тому кто не верстал ни одного шаблона, лучше не давать такую работу, все равно сделает не так. Потому что не знает как из верстки делается шаблон.
А тому кто не верстал ни одного шаблона, лучше не давать такую работу, все равно сделает не так. Потому что не знает как из верстки делается шаблон.
Очень хорошие замечания, я обычно частично про них забываю, потом приходится тратить время на перебивание стилей :)
Можно еще, кстати, написать про стандартные выводы во views. Например, при верстке обычных новостей или каталога.
во views за стандартные классы можно принять только враппер .view > .view-content
все, что внутри, с легкостью перешивается на любой вкус.
все, что внутри, с легкостью перешивается на любой вкус.
я в 95% случаев переопределяю свои views-view.tpl.php, views-view-unformatted.tpl.php, views-view-fields.tpl.php для каждого view. При этом для порядка я раскидываю их по папкам внутри темы (благо views сканят все папки в теме и поэтому раскладывать шаблоны можно в любой удобной структуре).
И в них я вобще мало что родного оставляю. Тут вобщем я оставляю свободу верстальщику, а сам потом очень быстро это прикручиваю.
И в них я вобще мало что родного оставляю. Тут вобщем я оставляю свободу верстальщику, а сам потом очень быстро это прикручиваю.
Верстать надо не только красиво и кроссбраузерно, но и семантично. Придерживаясь необходимых правил. такой верстки и ожидает друпал.
Тогда не надо будет ничего подгонять (или самую малость)…
Тогда не надо будет ничего подгонять (или самую малость)…
Странный топик. Пожалуйста, не вносите в ряды верстальщиков мифы!
Очень похоже на правила занятия сексом для адептов секты… Бррр
Ребята, какие правила, стандарты и требования?
Если вы не первый день знакомы с Drupal — то знаете, что любой вывод в тее переопределяется как угодно. И делается это легко и быстро… Покажите верстальщику пару сайтов на Drupal. У хорошего спеца вопросов не должно возникнуть.
Если вы знакомы только с гарландом — то ваша судьба это только миссионерская позиция и всех вокруг заставлять жить так же как и вы…
Очень похоже на правила занятия сексом для адептов секты… Бррр
Ребята, какие правила, стандарты и требования?
Если вы не первый день знакомы с Drupal — то знаете, что любой вывод в тее переопределяется как угодно. И делается это легко и быстро… Покажите верстальщику пару сайтов на Drupal. У хорошего спеца вопросов не должно возникнуть.
Если вы знакомы только с гарландом — то ваша судьба это только миссионерская позиция и всех вокруг заставлять жить так же как и вы…
Василий, не передёргивай. Да, всё можно переопределить, но можно этого не делать, если вёрстка будет «правильная».
Это не вопрос необходимости, это вопрос скорости.
Это не вопрос необходимости, это вопрос скорости.
Я же написал, что любому нормальному верстальщику достаточно глянуть пару сайтов на Drupal, а не заучивать правила «правильной вёрстки» под каждую CMS :).
Тем более, в топике нет ничего принципиального, что отличает верстку для Drupal от любой другой.
Блоки завернут, классы прописаны. А в какой CMS это не делается?
Тем более, в топике нет ничего принципиального, что отличает верстку для Drupal от любой другой.
Блоки завернут, классы прописаны. А в какой CMS это не делается?
ну вот когда делаешь один за одним постоянно сайты, то волей-неволей начинаешь задумываться о том, что каждый раз для каждого проекта переписывать свои функции темизации не прикольно. Вот и рождаются такие требования.
ну и кстати тут требования никак не в духе гарланда, а от стандартных выводов. гарланд в себе только пару функций тем переопределяет и то мелких. Я писал по системным выводам.
ну и кстати тут требования никак не в духе гарланда, а от стандартных выводов. гарланд в себе только пару функций тем переопределяет и то мелких. Я писал по системным выводам.
Странный топик. Пожалуйста, не вносите в ряды верстальщиков мифы!
Очень похоже на правила занятия сексом для адептов секты… Бррр
Ребята, какие правила, стандарты и требования?
Если вы не первый день знакомы с Drupal — то знаете, что любой вывод в теме переопределяется как угодно. И делается это легко и быстро… Покажите верстальщику пару сайтов на Drupal. У хорошего спеца вопросов не должно возникнуть.
Если вы знакомы только с гарландом — то ваша судьба это только миссионерская позиция и всех вокруг заставлять жить так же как и вы…
Очень похоже на правила занятия сексом для адептов секты… Бррр
Ребята, какие правила, стандарты и требования?
Если вы не первый день знакомы с Drupal — то знаете, что любой вывод в теме переопределяется как угодно. И делается это легко и быстро… Покажите верстальщику пару сайтов на Drupal. У хорошего спеца вопросов не должно возникнуть.
Если вы знакомы только с гарландом — то ваша судьба это только миссионерская позиция и всех вокруг заставлять жить так же как и вы…
опять хабро-глюбки? хотел исправить опечатку — создал пост ;)
Зря конечно Drupal выводит предопределённый заранее html. Мог бы выводить просто массивы и переменные, тогда будет явное разделение функционала и вёрстки. Я много работаю со Smarty мне удобно получить например, меню в виде вложенных массивов и из него быстренько сделать шаблон, который выводит нужный html код.
Программист при таком подходе абсолютно не заботиться ни об html, ни о активных классах ни о чём-то другом, кроме логики! Его код не перемешан с командами вывода (print, echo и т.п.). Единственное — соблюдать один и тот-же стандарт вывода переменных.
Я считаю такой подход очень удобным и меня просто бесит, когда разбирая очередную CMS я вижу в функциях логики переплетение команд print c кучей перемешанных переменных и html тегов.
Программист при таком подходе абсолютно не заботиться ни об html, ни о активных классах ни о чём-то другом, кроме логики! Его код не перемешан с командами вывода (print, echo и т.п.). Единственное — соблюдать один и тот-же стандарт вывода переменных.
Я считаю такой подход очень удобным и меня просто бесит, когда разбирая очередную CMS я вижу в функциях логики переплетение команд print c кучей перемешанных переменных и html тегов.
Нравиться Smarty? Работайте в друпале со Smarty.
Можно сделать вывод в XML, если хочется и работать с ним.
Можно сделать вывод в XML, если хочется и работать с ним.
ну вы при таком подходе на каждом проекте по новой пишите одно и то же, а я делаю много сайтов и я заинтересован в оптимизации своей работы и ускорении. и поэтому я не хочу каждый раз одно и то же писать.
Время — деньги! ;)
Время — деньги! ;)
А почему Вы не указали, что много чего можно переопределить через template.php?
вы хотите верстальщицу предложить сразу и template.php править?
Я наблюдаю два подхода в создании сайтов.
1. Дизайнер рисует, верстальщик верстает, программист программирует и т. п. На выходе имеем: дизайн, верстку, программную часть.
2. Понимание задачи: сделать сайт — цельный продукт такой, в котором все хорошо вместе. Вот здесь и ответ на Ваш вопрос: нельзя делать хорошие вещи порознь.
Если Вы не можете доверить верстальщику template.php, значит или верстальщик в первый раз видит Друпал или он тупое позвоночное, которое всю жизнь твердит, что его профиль — верстка и он не собирается прикасаться к пхп!
1. Дизайнер рисует, верстальщик верстает, программист программирует и т. п. На выходе имеем: дизайн, верстку, программную часть.
2. Понимание задачи: сделать сайт — цельный продукт такой, в котором все хорошо вместе. Вот здесь и ответ на Ваш вопрос: нельзя делать хорошие вещи порознь.
Если Вы не можете доверить верстальщику template.php, значит или верстальщик в первый раз видит Друпал или он тупое позвоночное, которое всю жизнь твердит, что его профиль — верстка и он не собирается прикасаться к пхп!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Требования к вёрстке под drupal