19 октября 2006 в 0:21
На http://www.drupal.ru/node/2644 идет обсуждение "Как вставить обычную страницу (html, php) в окружение (блоки, шапка, подвал) Друпала?"
Если речь идет о своей html-странице, то в таких случаях я обычно создаю в корне сайта нужный html-файл. Его можно отлаживать в локальной версии с помощью любимого HMTL и JavaScript-редактора. Все вставленные картинки будут правильно отсчитываться от корня сайта.
Когда отладка html-файла закончена, делаю ноду, куда вставляю PHP-скрипт. Он считывает нужный файл и выводит все что внутри тэга body. Картинки будут стоять на своих местах.
В таком варианте всегда остается возможность быстро поправить HTML-файл и быть уверенным, что он правильно будет показан в ноде. Эдакий mini-template.
В более продвинутом варианте php-скрипт создается отдельно и кладется в корень сайта. В ноде его только вызывают. Перед вызовом в скрипт передается название файла, который необходимо вывести в ноде и метку, которой будет окружен нужный кусок кода. Это позволяет на одной HTML-странице-доноре задать много кусков, каждый из которых можно будет выдергивать и показывать в отдельной ноде.
Формат вызова PHP-скрипта в ноде:
$FileName = “my_article.html”;
$Metka = “metka_article”;
include(“_html_print_inc.php”);
Открывающая метка “metka_article” это обычный HTML-комментарий, внутри которого находится указанная метка. Закрывающая метка выглядит точно так же, только внутри HTML-комментариев находится текст “/metka_article”
clubwave.ru пишет: Ctrl+C, Ctrl-V не удобней?
От задачи зависит.
Если вставляется простенький статический текст, который потом год не будет меняться, то можно использовать copy-paste.
Если вставляемое содержимое часто меняется, сильно завязано на html-коде и JavaScript и требует для отладки более серьезных инструментов, чем TinyMCE, то стоит посмотреть в сторону того, чтобы вынести содержание на отдельную html-страницу, где и отлаживать как обычную html-страницу своими любимыми инструментами. А очередная отлаженная версия с помощью php-вставки автоматом будет вставляться в нужную ноду при очередном обновлении сайта по ftp.
Например, если встраивать свою форму заказа в ноду, то удобнее ее сделать и отлаживать в виде html-страницы, чем генерировать php-скриптом.
inc пишет: Что вы имеете ввиду? Word и Dreamweaver или что-то другое?
Не хочу навязывать свой выбор. У каждого свои любимые инструменты. Для Друпала нужно лишь лишь, чтобы инструменты корректно работали с файлами в UTF-8.
clubwave.ru пишет: Простите, но бред конкретный...
Понимаю Ваше затруднение. Многим сложно осознать, что можно с комфортом писать вписанные в Друпал ноды без самого Друпала.
В этой технике нет ничего необычного. Например, есть много сторонних программ для ведения блогов. В них любой пользователь Друпального сайта может с комфортом оформить текстовую статью, а Друпалом воспользоваться лишь для публикации статьи.
Фактически, речь идет о том, Друпал не требует обязательно работать с содержимым ноды только через него самого. Хозяин сайта может с помощью php-вставки можно вставлять в ноду нужный кусок отдельной html-страницы. Саму страницу же править привычным для веб-мастера инструментом.
Для обычных посетителей сайта создание ноды идет через фильтры или визуальный редактор, как например, TinyMCE. Если им очень хочется, то они могут создать содержимое в любом своем редакторе и через copy-paste вставить в ноду. Исправление тоже потребует copy-paste содержимого из ноды в редактор. А после правки в редакторе - обратно в ноду. Очень продвинутые пользователи могут создавать текстовые ноды через программу для ведения блогов.
Хозяин же сайта может ваять нетривиальные страницы на Друпальном сайте с гораздо большим комфортом. Он может тем же Dreamweaver-ом править отдельную html-страницу, включающую в себя содержимое ноды, оставив Друпалу лишь отображение содержимого этой страницы в ноде. Отлаживать такую страницу можно полностью в локале. Нода будет меняться без всяких copy-paste при очередном обновлении сайта по ftp.
Другими словами, хозяин сайта имеет возможность при редактировании ноды вместо TinyMCE использовать более серьезный редактор, например Dreamweaver. Весь комфорт обеспечивается маленьким php-скриптом, который портирует заданную html-страницу вовнутрь нужной ноды.
Этот php-скрипт я кидаю в корень каждого своего сайта. И он может обслуживать хоть сотни html-страниц, только успевай менять при вызове скрипта имя нужного html-файла.
В несколько измененном виде эту же технику можно применять для отладки сложного php-скрипта, которого нужно вставить в ноду. Можно кинуть его в корень сайта и вызывать в ноде через php-вставку include. Для отладки можно запускать этот скрипт напрямую без ноды прямо из корня сайта. При вызове PHP-скрипт "оглядывается", и по URL-у определяет, вызван он в ноде или самостоятельно. В случае самостоятельного вызова скрипт подставляет параметры по умолчанию для переменной $user и подобных, которые зависят от Друпала. А дальше исполняется в обычном режиме. Это позволяет отлаживать PHP-скрипты в Друпале с помощью любимого PHP-редактора, например, Zend Studio.
Итог.
TinyMCE прекрасная вещь. Мне нравится создавать текстовые сообщения с его помощью.
Но как только содержание ноды требует хоть чуть-чуть более серьезного кода, я тут же перелезаю на наработанные инструменты для html, JavaScript и PHP кодинга. Для переноса кода между редактором и нодой и обратно использую не изматывающие copy-paste, а небольшие php-скрипты в ноде. Благо Друпал их прекрасно поддерживает.
Использование серьезных инструментов для отладки ноды позволяет с легкостью вписывать в Друпал даже сложные динамические страницы с вызовом базы, ЯваСкриптами и сложным html-кодированием. Для посетителей результат будет выглядеть как обычная нода, вписанная в дизайн сайт. Для веб-мастера не составит труда исправлять и развивать содержимое страницы.
Это не совсем техника шаблонов. Template задает только шаблон для сборки, а сама сборка делается отдельно и шаблон во время сборки сильно дополняется. Здесь же содержимое ноды полностью вынесено в отдельный файл, где редактируется, развивается и поддерживается. А Друпал только публикует его.
Макс Кириленко
Razgonka.ru - Подбор названий сайтов и программ
Комментарии
Да, в то время как космические корабли...
а мы все пытаемся добыть огонь трением двух деревяшек.
Дочего же устойчивы древние инстинкты.
А вы вообще в курсе, что Dreamweaver это не редактор в обычном понимании этого слова. Dreamweaver это инструмент разработки сайта, чувствуете разницу? Одно дело подправить страничку, а другое дело спроектировать сайт. Ну примерно то же самое, что атомной бомбой мух убивать.
Уважаемый "Автор-изобретатель", а вы вообще слышали по концепцию разделения оформления и содержания? Вы разве не знаете, что это порочный опыт, вставлять оформление в содержание? Весь мир уже до этого допер.
Ах да, вам же нужно вставлять всякие там джава скрипты ...
Ну а как это делается стедствами Друпала Вы естественно не знаете.
Это конечно вообще ни в какие ворота, Вы что собрались отлаживать "содержимое"?
Ага, написали статью и давай ее отлаживать, так?
Диагноз: Уважаемый, изучайте новые технологии, хватит находиться в каменном веке.
Все ваши задачи можно решить средствами друпала, не привлекая ФТП и файлы. Category, CCK, Veiws, actions и т.п.
Сразу видно теоретика.
Решение задачи определяется не тем, как ее лучше решать в теории, а бюджетом, который клиент выделил решение задачи. Перечислю случаи из практики, когда выделение содержания в отдельный файл было оправдано.
Случай 1. Переводили сайт со статики на Друпал. На старом сайте у клиента была страница, где посетитель мог ввести:
- размеры площади,
- задать угол укладки кафеля
- выбрать размер плитки
- фактуру (однородная, с рисунком, симметричная,...)
- ...
На выходе скрипт выдавал количество плиток, которые нужно было купить. Скрипт был написан местным умельцем и время от времени дорабатывался (добавлялся учет прямоугольных дверных проемов, обсчет криволинейных арок, ...).
Когда с клиентом обсуждали переезд на Друпал, он попросил меня сделать такую же страницу на Друпале. Я написал скрипт, который брал старую страницу и вставлял ее в ноду Друпала. Местный программист как ваял свою html-страницу, так и продолжает ее ваять. А все результаты прямиком отражаются в ноде.
По теории мне надо было бы самому подписаться на портирование этого скрипта на Друпал. Но тогда на меня свалилось бы развитие скрипта.
Грузить же местного программиста-любителя изучением Друпаловского API - зачем мне вешать на парня заботы, когда у него зарплата как была, так и остается.
Плюсы моего решения. Портирование калькулятора было сделано быстро. Клиент за это не заплатил ни одной лишней копейки. Местный программист спокойно продолжает наращивать скрипт на своей html-странице. При обновлении ее через ftp Друпал показывает в ноде очередную версию калькулятора.
Случай 2. Сделал сайт на Друпале, набили статьи. Когда дело близилось к расчету, клиент говорит: "Нужно еще пунктик меню добавить, у конкурентов он есть и нам тоже надо". Глянул я на то, что он увидел у конкурентов и впал в великую грусть. Под этим пунктом у конкурента лежал каталог из 800 наименований товара с описаниями, превивами и полноразмерными фотографиями, разбитые на несколько рубрик.
Теоретическое решение. Объяснить клиенту, что он просит витрину Интернет-магазина и что это будет стоить столько же, сколько весь сайт. Если клиент согласится оплатить, то создать 800 нод, в каждой из которой будет фотография и описание товара. Каждому товару дать короткую ссылку (все названия товара изначально идут на английском языке), чтобы менеджеры могли на память набирать URL-товара.
Практическое решение. Спросил клиента, как он относится к тому, что картинки будут взяты с другого сайта. Он сказал, что он знает хозяина, они сидят в разных регионах, друг другу не мешают и картинки можно брать спокойно. Я скачал картинки и описания. Картинки раскидал на несколько каталогов, описания загнал в файл. Написал скрипт, который тянул из URL страницы номер товара и подставлял его описание.
Минусы моего решения. Ссылки получились не сильно дружелюбные к поисковикам и посетителям. На одной странице показывалось 800 единиц товара в зависимости от конструкции после "?".
Плюсы.
1. Клиент через сутки получил то, что он назвал "пунктик в меню". Заказ был благополучно закрыт.
2. Клиент дополнительно не платил ни копейки.
3. За прошедшие полгода этот клиент привел ко мне еще двух клиентов. С них я тоже не брал ни одного лишнего рубля сверх оговоренной цены. Поднял им сайты быстро и хорошо.
Если бы меня кормили папа-мама/жена/любовница (нужное подчеркнуть), то я бы только и делал, что сидел и изучал новые технологии, а в свободное время ходил бы по форумам и учил бы, как прекрасна теория. Но моя жизнь такова, что мои клиенты не хотят платить за то, что они не понимают. Им все равно, какими технологиями я добиваюсь результата. Им важно, чтобы я не вышел из бюджета ни на рубль.
Ни один клиент мне не заплатит больше только за то, что я все задачи решаю средствами Друпала, "не привлекая ФТП и файлы". Они вообще от меня слова "Друпал" не слышат, потому что я никогда не гружу клиента теми словами, которые он не понимает без дополнительного объяснения. Если бюджет ограничен, то я делаю как придется. Пусть не совсем чисто с точки зрения теории, но зато вполне работоспособно и быстро. И совесть меня не мучает.
Профи тем и отличаются от новичков, что не считают нужным слепо следовать теории. Если Вам будут лепить уголовное дело, то Вы не будете обращаться к адвокату-теоретику со степенью доктора юридических наук. А поклонитесь в ножки к адвокату-практику, который к тому же тесно знаком с судьей.
Если мой опыт Вас не убеждает, то вот еще пример того, как работают профи.
Один из участников Drupal.ru прикрутил fudforum к Друпалу. Вместо использования API Fudforum он использовал прямые обращения к БД Fudforum. По ходу дела исправил родной модуль fudforum с Drupal.org http://drupal.org/project/fudforum . Да еще осмелился выставить такое "некошерное" решение на Drupal.ru.
С точки зрения теории, нужно выдрать этого участника. И посоветовать ему "в наше время, когда корабли бороздят просторы Вселенной..." учить API Fudforum и не плодить свои версии модулей с Drupal.org.
С моей же точки зрения, как практика, этот участник все сделал правильно. Сайт некоммерческий, бюджет прикрутки FUDforum к Друпалу был нулевой. Для такого бюджета его решение великолепно. В результате счастливые посетители сайта прекрасно общаются на FUDforum http://lfe.roleplay.ru и через сайт и через E-mail. И они совсем не переживают по поводу того, что в этом решении не использовалось API FUDforum, да при этом еще был задет родной модуль fudforum.
Хорошо также посетителям Drupal.ru, которые смогли присмотреться к чужому опыту прикрутки FUDforum к Друпалу. Всегда приятно, что кто-то проработал вопрос и можно идти дальше, отталкиваясь от достигнутого.
Если кто-то считает, что Fudforum был прикручен грязно, без использования API Fudforum и с переделкой оригинального модуля fudforum и подобному решению нечего делать на Drupal.ru, то сказать свое "фи" он может на странице, где выставлено это прекрасное бюджетное решение:
http://www.drupal.ru/prj/modules/fudforum
Что, слабо поучить этого участника, как нужно правильно прикручивать форумы?
Макс КириленкоRazgonka.ru - Подбор названий сайтов и программ
Дневник
Вот только не надо на Акселя стрелки переводить, каждая его публикация несет массу полезной информации.
Одно дело улучшить модуль и интегрировать чужую разработку, а другое дело писать о том, что дескать есть такая чудо-команда : "include" и, мол ее используют настоящие профи. А новички пускай, мол, изучают API, если им так нравится.
Кхе-кхе, ну а раз вы сами себя кормите, то и изучать ничего не надо?
seaji пишет: "Вот только не надо на Акселя стрелки переводить"
Понятно, Вам не хочется драть Акселя за его практический подход. И это правильно.
Теперь, после того как мы оба выразили личную преданность хозяину Drupal.ru, продолжим нашу беседу.
seaji пишет: "Одно дело улучшить модуль и интегрировать чужую
разработку, а другое дело писать о том, что дескать есть такая
чудо-команда : “include” и, мол ее используют настоящие профи.
А новички пускай, мол, изучают API, если им так нравится."
Когда человек приходит после института в фирму, ему часто говорят "Забудь все, чему тебя учили в институте". Ни в одном институте не учат, что решения в любом проекте принимаются только в зависимости от размера бюджета. В институтах все 5 лет учат "как надо делать", предполагая, что выделенный бюджет на решение задачи неограничен.
А в практической жизни есть клиент, он выделяет какие-то деньги и нужно вписать все его желания в оговоренную сумму. Чистая (с точки зрения теории) реализация проекта встанет клиенту в хорошую копеечку.
Интернет развивается очень быстро. Часто клиенту вообще непонятно, оправдаются ли его затраты на создание или переделку сайта или нет. В таких случаях единственным выходом будет выкидывание всего лишнего и установка только того, что жизненно необходимо. Если кто-то думает, что клиентам некуда девать деньги и они готовы заказать сайт просто так, от нечего делать, то он заблуждается. Бизнесмены как раз очень хорошо считают деньги.
Обычно после запуска сайта мы с клиентом расстаемся на полгода-год, клиент пользуется сайтом и в нем рождается понимание, куда ему хочется развивать сайт. Мы снова встречаемся, выкидываем практически все, что было сделано при запуске сайта и в новом направлении делаем уже все нормально.
Вот так и получается, что большинство проектов делается и запускается "на коленке". Дизайн упрощенный, потому что не понятно, каким будет содержимое сайта. Модулей ставится только жизненно необходимый минимум. А если проект выживет и докажет свою целесообразность, то только тогда в него начинают вкладывать серьезные усилия - делают редизайн сайта под накопленное содержимое, меняют временные решения на постоянные, ставят нужные модули и т.д. Многоэтапная разработка сайта обходится клиенту намного дешевле, чем пытаться предугадать развитие сайта на много лет вперед и заказать все сразу.
seaji пишет: "Кхе-кхе, ну а раз вы сами себя кормите, то и изучать ничего не надо?"
Как только у меня появится проект, который будет требовать изучения API, я его пролистаю и применю. Причем буду читать только в той части, которая необходима для задачи. Но учить просто так все подряд - увольте. Работы у меня много, а свободного времени мало. Может быть я с Вашей точки зрения не настоящий профи, но в свободное время предпочитаю отдыхать.
Мой профессионализм не в том, что мои коллеги изучают мой код и согласно кивают головой: "Да, круто". Мой профессионализм в том, что я получаю деньги от клиента, а клиент получает удовольствие от моей работы. Я конечно умею все делать "по науке", но тогда мои цены станут высокими, а мне не хочется наказывать клиента деньгами из-за моих высоких принципов.
Немцы не склонны бастовать, отказываясь от работы. Слишком законопослушны. А бастовать им иногда приходится. Поэтому "немецкая" забастовка заключается в том, что сотрудники начинают делать все правильно, как написано в нормативных актах и инструкциях. В результате жизнь в организации замедляется в несколько раз. Формально работодатель не может предъявить претензий к своим сотрудникам, они ведь всего лишь дотошно исполняют свою работу.
У нас с Вами разные способы применения Друпала. Я его использую как инструмент для малобюджетных проектов (если клиент готов вложится хорошо, то ориентирую его на платные CMS из коробки, Куби, Битрикс,...). Вы, судя по Вашему желанию изучать API, обладаете массой свободного времени, которое является следствием того, что у Вас нет достаточного количества клиентов.
Если бы Друпал требовал бы только использование его API, я бы не стал с ним связываться. Если бы у Друпала не было API, я бы тоже не стал с ним связываться. Но слава богу, Друпал гибок. И можно начинать использовать его без всякого знания API. И есть возможность в будущем изучить API.
Я согласен с Вами, что API хорошая штука. Единственная цель моего постинга была показать, что в Друпале возможны и быстрые решения, без применения API и модулей. Применять "грязный" include или "благородный" API - каждый решает сам в зависимости от свободного времени и бюджета, выделенного на задачу. Клиент никакой разницы между этими двумя способами не видит, оба способа дают с его точки зрения совершенно одинаковый результат.
Хотя, самый главный наш клиент - это мы сами. Бюджет свободного времени на проживание жизни каждому отмерян не очень большой. И приходится думать, как правильно исполнить свой проект "Свободное время".
Каждый раз, решая чем занять свободное время, можно использовать старый добрый способ. Подкинуть вверх коробок спичек. Ляжет коробок лицевой стороной вверх - значит нужно сходить с подружкой (семьей) в кино. Оборотной стороной - встретится с друзьями. Встанет коробок на ребро - оторваться без друзей и подружки (семьи).
Ну а уж если коробок в воздухе повиснет - то здесь да, учить API, "однозначно". IMHO.
Макс КириленкоRazgonka.ru - Подбор названий сайтов и программ
Дневник
Разговор идет о высоких материях. Но вынужден приземлить его до банального употребления тэга pre.
Он обычно используется для оформления текстов с кодами программы, строки которых разрывать. Вы его используете для цитат. Так тоже можно делать. Но тогда нужно вручную разрывать строки, иначе обсуждение на всей странице будет растянуто по длине самой длинной строки, оформленной тэгом pre.
Сейчас в моей странице появилось горизонтальная полоса прокрутки из-за того, что Вы обрамили тэгом pre слишком длинную строку, сразу пополз дизайн страницы. На Вашем мониторе шириной 1280 пикселей ее не видно, но посетителям с монитором 1024x768 пикселей приходится пользоваться горизонтальной прокруткой, чтобы увидеть весь текст сообщений.
Пожалуйста, прежде чем продолжить беседу, разбейте на две строки цитату в Вашем сообщении "Не далекого ума людям посвящается".
Спасибо.
Макс КириленкоRazgonka.ru - Подбор названий сайтов и программ
Дневник
Относительно свободного времени:
я веду четыре интернет-проекта, задачи совершенно разные и без изучения просто никуда.
Относительно Вас складывается совсем другое впечатление, раз у вас есть возможность флудить такое количество мало полезной информации.
Теперь относительно того, что считать профессиональным решением:
Мало того, что это должно быть сделано быстро, это должно быть красиво и удобно.
Возьмем пример с калькулятором плиток.
Пчему бы не дать возможность вашему "умельцу" выгружать новые версии через его учетную запись и делать пометки для каждой версии относительно того, что в новой версии изменено. Хотя бы для того, что бы он сам не запутался в своих версиях.
Далее, все версии сохраняются, а переключение между версиями происходит установкой или снятием флажков на специальной странице управления. Кроме того для "разработчика" можно установить одну версию, для всех остальных другую и производить отладку прямо на сайте не беспокоясь о том, что посетители используют "бету".
Вот это я понимаю, красивое и удобное решение.
2006 год, а как приятно читать ))) Да же не заметно, что идет какой-то спор )))
тоже интересно было прочитать. я свой проект тоже с необходимым минимумом запустил, даже сырым, если бы я делал все сразу на 100% процентов правильно, то он никогда бы и не запустился.
и запуская остановив выбор на модуле имейдж(фото у меня играют очень важную роль) сразу решил, что если потребуется - буду хакать его безпощадно, лучше так чем никак
Макс Кириленко - молодец! Клиенту по-фигу чем и как будет сделан его сайт, главное, чтобы работало так как клиенту хочется.
Клиенту даже не авжно как оно работает, главное чтобы было красиво (как у соседа).
что ни говори, а Дрим удобнее - в режиме сплит, когда и код и содержание сразу видно
Технология описываемая Максом похожа на метод iframe
у меня например, с помощью iframe отображается баннер рекламодателя - на своей стороне он сам меняет и баннер и ссылку