Comments 19
Все просто и понятно, но что будет если элементы а, с интересующим нас классом появляются на странице асинхронно? Выходит, что нужно руками вызвать функцию, которая заново навесит все обработчики, либо дублировать этот код в месте возврата асинхронного контента.
Недавно столкнулся с подобной проблемой, но разве нельзя добавить данный код в callback функцию, после добавления элементов, или почему это не правильно делать?
(function ($) {
//
}) (jQuery);
Вроде везде такая обертка приветствуется, чтобы не конфликтовать с другими библиотеками
Теминг, бихевиор, бейс урл? Что? Странно звучит, как минимум. Теминг — темизация, бихевиор — ну, поведением хотя бы назвать, бейс урл — базовый URL.
А потом проклятия сыпятся на тех, кто вывод перемешивает с оформлением, зашивает меню и информационные блоки в шаблоны, а файлы подключает не через drupal_add_.
Не совсем понял, это как-то связано со способом подготовки верстки?
Лучше его пристрелить и найти того, кто знает, что такое и зачем нужен jQuery.noConflict(). Drupal тут не при чём, это общая практика.
Конечно такой верстальщик лучше, очень хочу найти хотя бы такого, да еще чтоб и под друпал верстал хорошо. Есть кого посоветовать?
товарищ спрашивает: «Отличается ли верстка под друпал по цене, от обычной верстки такой же сложности?»
Когда вы делаете проект на 10-15 тысяч человеко-часов
вы вынуждены распараллеливать работу
и начинать верстку не дожидаясь того когда «весь» функционал будет сделан
особенно если учесть что состояние «весь» не бывает вообще никогда достигнуто как минимум в половине проектов
хотя бы потому что в процессе работы даже если был подписан договор с макетами
все равно выясняется что что-то надо убрать, что-то переделать, а чегото срочно добавить причем раньше чем сдать основной функционал в договоре.
ну и опять же не уверен что 100% объективно «писать css» отделять от «верстать»
мы не имеем отдельной должность CSSщик
для нас это верстальщик
и это другой человек чем программер
с другими навыками и умениями.
вы вынуждены распараллеливать работу
и начинать верстку не дожидаясь того когда «весь» функционал будет сделан
особенно если учесть что состояние «весь» не бывает вообще никогда достигнуто как минимум в половине проектов
хотя бы потому что в процессе работы даже если был подписан договор с макетами
все равно выясняется что что-то надо убрать, что-то переделать, а чегото срочно добавить причем раньше чем сдать основной функционал в договоре.
ну и опять же не уверен что 100% объективно «писать css» отделять от «верстать»
мы не имеем отдельной должность CSSщик
для нас это верстальщик
и это другой человек чем программер
с другими навыками и умениями.
Далеко не всегда желания дизайнера можно реализовать только изменением CSS готовой структуры.
Да, может отличаться, но не сильно.
Ведь технологии все те же, просто надо знать, что такой элемент нужно верстать такими-то блоками, с такими-то классами.
Ведь технологии все те же, просто надо знать, что такой элемент нужно верстать такими-то блоками, с такими-то классами.
Давненько я уже пришел к выводу, что при разработке на друпале эффективно работать с верстающими программистами (пусть и разной квалификации).
Проходили вариант программист и верстальщик — это был ад. Слишком мого проблем и ругани.
Проходили вариант программист и верстальщик — это был ад. Слишком мого проблем и ругани.
т.с.: забыли добавить, что стиль комментирования // Your code here — не очень хорош. После включения сжатия бывает, что скрипты из-за этого отваливаются.
2 Punk_UnDeaD > «А потом проклятия сыпятся на тех, кто вывод перемешивает с оформлением, зашивает меню и информационные блоки в шаблоны ...»
— нас ждет твиг! :)
2 Punk_UnDeaD > «Можете представить сколько ненависти вызовет вёрстка, у которой не те классы и не та структура.»
При грамотном подходе и нормальной первичной вёрстке — практически ничего не вызовет. 2 из последних последних проектов, которые уже были свёрстаны практически не потребовали доработки.
2 Abyasov «Давненько я уже пришел к выводу, что при разработке на друпале эффективно работать с верстающими программистами»
Ну, да что-то есть в этом :). Но imho полезнее с программирующими верстальщиками лучше. Обычно на уровне перекрытия стандартного вывода — вполне достаточно.
Опять же если кто-то из 2-х «генеальных» личностей глуп(да ещё с кучей понтов и амбиций) — то ни что уже не поможет.
2 Punk_UnDeaD > «А потом проклятия сыпятся на тех, кто вывод перемешивает с оформлением, зашивает меню и информационные блоки в шаблоны ...»
— нас ждет твиг! :)
2 Punk_UnDeaD > «Можете представить сколько ненависти вызовет вёрстка, у которой не те классы и не та структура.»
При грамотном подходе и нормальной первичной вёрстке — практически ничего не вызовет. 2 из последних последних проектов, которые уже были свёрстаны практически не потребовали доработки.
2 Abyasov «Давненько я уже пришел к выводу, что при разработке на друпале эффективно работать с верстающими программистами»
Ну, да что-то есть в этом :). Но imho полезнее с программирующими верстальщиками лучше. Обычно на уровне перекрытия стандартного вывода — вполне достаточно.
Опять же если кто-то из 2-х «генеальных» личностей глуп(да ещё с кучей понтов и амбиций) — то ни что уже не поможет.
т.с.: забыли добавить, что стиль комментирования // Your code here — не очень хорош. После включения сжатия бывает, что скрипты из-за этого отваливаются.
Да, когда-то на D6, я тоже встречал такую проблему. Но вживую я ее давно уже не видел, поэтому думаю что она неактуальна.
Особенно если учесть, что в скриптах ядра и контриб модулях такой стиль сплошь и рядом, поэтому отступать некуда.
Sign up to leave a comment.
Руководство по написанию JS скриптов для front-end разработчиков под Drupal 7