12 августа 2007 в 20:56
Часто на сайте должна накапливаться на какая-то информационная база данных - база артистов, недвижимости, библиотека, видеокаталог,...) с описаниями, ссылками на скачку и т.д.
Есть сторонние модули Друпала, которые решают эту задачу. Но они создают свой собственный тип данных, который не поддерживается Друпалом. Когда поддержка стороннего модуля прекратится, то накопленные данные повиснут в воздухе.
Можно накапливать информационную базу только стандартными типами данных Друпала. Это будет так называемое "зеленое" решение.
Создание материала
Заведите новый тип информации, например "Описание книги". В описании типа задаете инструкции, по которым посетители должны заполнять этот тип материала. Эти инструкции будут выводится при наборе описания книги.
В заголовке указываются авторы через запятую и в кавычках название книги. В теле - описание книги и вся дополнительная информация (ссылка на скачку и т.д.).
Словари
Для удобства работы с библиотекой заведите несколько словарей и "повесьте" их на тип "Описание книги".
1. Словарь из 33 пунктов, в каждом пункте по одной букве. Этот словарь используется для указания первой буквы фамилии автора книги.
2. Еще словарь из 33 букв, для указания первой буквы названия книги
3. Словарь из 10-20 терминов для задания жанра книги
4. Словарь, задающий вес файла с книгой (варианты: нет файла, до 100 Кб, до 1 Мб, до 10 Мб, до 100 Мб, свыше 100 Мб).
5. Рейтинг книги от 1 до 5 звезд по мнению создателя описания
6. Другие словари по желанию
Посетители, создающие материалы данного вида, будут выбирать нужные пункты из словаря.
Поиск
Искать нужные книги можно через таксономию (под каждый пункт словаря будет отдельная ссылка, которая собирает все книги, помеченные этим пунктом). Или через встроенный поиск. Он выдаст в заголовках найденных сообщений всех авторов и названия подходящих описаний книг.
Для более продвинутой работы с накопленными описаниями можно использовать модуль Views.
Для какого-то особого изощренного поиска можно заказать скрипт, который будет искать подходящие сообщения "Описания книги", удовлетворяющие заданным критериям поиска.
Например, скрипт сможет выдать всех авторов книг:
- у которых книги набрали только 3 или 5 баллов по оценке заполнителя описания книги
- и 2-ое слово книги начинается на букву "д"
- или слов в названии книги ровно 4 но авторов не больше двух.
Преимущества "зеленой" информационный базы данных
"Зеленое" решение гарантирует сохранность накопленных данных. Примерно половина сторонних модулей не переживает смену версий Друпала или его API. Но Друпал всегда поддерживает все данные, накопленные с помощью его стандартных методов.
Даже если во время очередного апргейда Друпала прекратится поддержка модуля Views или сменится API, то накопленные данные останутся живы. И это главное. Данные можно будет продолжать накапливать и делать среди них поиск с помощью стандартных способов Друпала (поиск и таксономия).
А позже можно будет поставить какой-нибудь модуль-аналог Views, который умеет показывать стандартные данные Друпала разными способами.
И даже снова написать изощренный скрипт поиска.
Комментарии
Такие записи лучшая реклама razgonka.ru
PVasili says: Такие записи лучшая реклама razgonka.ru
К сожалению, у меня не получается сразу писать такие статьи. Приходится сначала на десятках разных тем обкатывать одну и ту же мысль, объясняя ее всем подряд при каждом подходящем случае. Пока наконец не приходит понимание, как эту мысль выразить кратко.
Так что спасибо всем постоянным посетителям Drupal.ru, которые своими возражениями помогают мне докопаться до сути.
И как же эту "зеленую" базу данных пополнять? Через копирование и вставку HTML'я в формы и вечным тыканьем кнопки "Обзор" для прикрепления файлов по одному с помощью одного всем известного модуля (upload) - нет уж, увольте!
Уважаемые друпаллеры, есть ли для Друпала какие-либо интерфейсы для сгребания материалов с других сайтов, с локальных копий сайтов, а не такими варварскими способами. То есть, чтобы мышкой выделил контекст - и отправил его в Друпал (можно, и не отходя от кассы браузера, разметить его по словарям-категориям).
Ну что-то типа Scrapbook для Drupal?
-------------
Vadbars, спасибо вам за информацию, будем продолжать поиски, вот посмотрим, на что способен BlogJet.
интересная статья, примерно так себе и предпалагал
вопрос только технический, как с помощью views выводить конкретную ноду (например Фамилия на "А" и название на "А")
ага, только это ерунда, это расчитано на заполнение только ответственными лицами. Ничего не мешает мне при добавлениеи, например, книги Трегубовой "Кремлёвские диггеры" пометить автора буквой "Б", а книгу буквой "Г" - это может быть моё законное отношение к данному произведению. И всё, фиг найдешь. Тема должна быть в том, чтобы автоматом все авторы на букву "Т" появлялись при фильтрации по этой букве. К тому же, так и остаётся нерешенным главный вопрос - как ОДНОВРЕМЕННО фильтровать например по первой букве автора, названия книги и жанру, а не по очереди - это предлагается достигнуть мифическим поиском, который никто никогда не видел, не делал и не писал, тем не менее это уже стало готовым решением. А поиск написать, господа - это нетривиальная задача, тем более с такими жёсткими ограничениями - я бы , например, не взялся бы за такой модуль. Хотя например портировать тот же CCKна новую версию Друпала в том же мифическом случае отказа его разработчиков от его дальнейшей поддержки - не отказался бы
И что же прощё, какой вариант? Так что сообщение Макса, при всём к нему уважении - очередное переливание из пустого в порожнее с игнорированием неудобных вопросов и с подчёркиванием мифических преимуществ.
Примерно половина сторонних модулей не переживает смену версий Друпала или его API.
Обоснуйте, откуда циферки, приведите примеры, а то голословно можно утверждать всё, что угодно. Это Ваши простые домыслы и попытка придать больший вес своим словам. И это легко доказуемо. Например, в настоящее время на оффициальном сайте http://drupal.org/project/Modules/name количество модулей под пятую версию 928 штук, под 4.7 версию - 769,а всего модулей обоих видов - 1191 ( модули по 6-ку можно учитывать как арифметическую погрешность). Таким образом, получаем число не портированных модулей под 4.7 - порядка 250,что менее трети от общего числа, причём если вкратце посмотреть, то подавляющее кол-во этих модулей реализовано в других более продвинутых модулях или же в самом ядре 5-ки, притом что "Красные модули"(в вашей терминологии) вообще очень редки. Плюс учесть, что новых модулей под 5-ку - более 400, то все стоны про ужасность использования сторонних модулей выглядят странно - в этом то и сила Друпала - в модульности, а не наоборот...
Вот сайт недвижимости: http://www.metp.ru/. CCK+View + автогенерация заголовка. Не самый сложный вариант, но как пример пойдет. Сайт не мой, но сделать аналогичное не сложно. А теперь, пожалуйста, покажите мне реально работающий сайт с "зеленой" БД с хотя бы аналогичными возможностями. Бог с ним, даже не работающий, даже просто недоделанный сойдет.
Вот допустим я заказчик и прошу сделать мне такой же сайт по недвижимости: что будет ваша студия мне предлагать? Надеюсь, это не закрытая информация, верно?
beer_destroyer says: "А теперь, пожалуйста, покажите мне реально работающий сайт с "зеленой" БД с хотя бы аналогичными возможностями. Бог с ним, даже не работающий, даже просто недоделанный сойдет."
Как я Вам покажу подобный сайт с "зеленой" установкой, если:
- половина Drupal.ru при словах "зеленая" установка крестится и говорит "свят-свят"
- вторая половина Drupal.ru молчит
- а "зеленую" установку делает только студия Razgonka.ru, да и то если клиент не возражает?
"Зеленые" решения дают эффект после нескольких лет эксплуатации сайта. Большинство друпальщиков с Drupal.ru узнало про Друпал всего 1-2 года назад. Наивно ожидать, что они сразу скажут "Да, зеленое решение это круто".
"Зеленые" решения как минимум требуют знания от и до всех стандартных возможностей Друпала, чтобы с их помощью пытаться построить информационную структуру и не потерять в ее функционале.
Но даже самый стандартный модуль Book мало кто использует из друпальщиков (30 запросов на Drupal.ru). Зато гораздо чаще появляются сообщения о модуле wiki (60 запросов на Drupal.ru).
Нужен опыт
По мере накопления опыта ведения сайтов на Друпале в сообществе Drupal.ru будет приходить понимание, что сайт это не куча функционала сегодня. Хороший сайт тот который безболезненно будет существовать годами и не терять накопленных материалов.
Когда Drupal.ru перейдет на 6-ую (7-ую, 8-ую,..) версию Друпала и у него отвалится http://wiki.drupal.ru/ , возможно тогда часть народа задумается о преимуществах "зеленого" модуля book перед "красным" модулем wiki.
beer_destroyer says: Вот допустим я заказчик и прошу сделать мне такой же сайт по недвижимости: что будет ваша студия мне предлагать?
Если клиент просит "CCK+View + автогенерация заголовка", то он получит "CCK+View + автогенерация заголовка". Клиент имеет право получить за свои деньги все что хочет. Предупредить о "зеленой" альтернативе предупрежу, но настаивать не буду.
Клиенту ситуация виднее. Может быть, завтра он собирается продавать проект и ему нужно чтобы было красиво. Или послезавтра он собирается увольняться с фирмы и ему хочется сдать руководству фирмы красивый проект и без лишних вопросов. Ситуации разные бывают.
Но если клиент оставляет выбор мне, то я предпочитаю "зеленую" установку. С ней поддерживать сайты просто. Также можно в любой момент уйти с сайта и быть уверенным, что другой друпальщик с легкостью возьмет сайт на поддержку и сохранит весь наработанный материал при смене очередных версий Друпала.
Ну и где вы ее реализовали? Потому как пока все это смахивает на теоретизирование. И хренова туча вопросов без ответов. Вот я показал сайт: того же зеленой установкой вы добьетесь?
Вики надо делать не модулем, а отдельным сайтом на поддомене. тогда ничего бы не отвалилось. То же относится к форумам. Надо писать модуль с SQL перекидкой базы юзеров по крону, и забыть о проблемах. Не надо пихать в Друпал несвойственные ему функции.
Да потому что понимают, что фигня это. "Гладко было на бумаге...", а тут даже и на бумаге не гладко...
Вы уже написали придвинутый модули поиска и вывода информации для вашей зеленой концепции? Потому что без этих составляющих говорить о чем-то просто смешно. А заносить можно хоть в CSV - не вопрос. Вопрос как это все вывести.
Я не говорю, что это невозможно. Я говорю, что вы этого не сделали. Что есть только теоретическая концепция зелени, и эта концепция не реализована ни разу. Зато "половина Drupal.ru" прекрасно видит грабли. На которые вы непременно наступите в случае реализации.
beer_destroyer says: Вы уже написали придвинутый модули поиска и вывода информации для вашей зеленой концепции? Потому что без этих составляющих говорить о чем-то просто смешно.
Или я Вас не понимаю или Вы меня не понимаете.
При чем здесь продвинутый модуль поиска и вывода информации? Если таковой нужен, то его придется писать как при хранении данных стандартным для Друпала образом, так и для CCK. Или Вы считаете, что CCK сам включает в себя "продвинутый модуль поиска и вывода информации"?
Зеленая установка говорит только о хранении данных стандартным для Друпала способом. Как эти данные мять, вертеть, использовать - этого зеленая установка не ограничивает. Можете тот же Views использовать. Даже если он вдруг через пару лет отвалится, все данные в "зеленой" установке останутся целыми. И с ними можно будет работать с помощью других модулей-аналогов Views, которые неизбежно появятся к тому времени.
В Вашем примере все объявления по недвижимости можно легко хранить в стандартных для Друпала нодах, достаточно посмотреть на страницу набивки объявления http://www.metp.ru/node/add/content-add . Все нужные параметры квартиры можно реализовать через таксономию.
А как будут показываться данные, хранимые в стандартных нодах Друпала, зеленую установку этот вопрос не касается. Или Вы считаете, что стандартно созданные Друпалом данные показывать сложнее, чем нестандартно хранимые данные, созданные модулем CCK?
jason32 says:"Ничего не мешает мне при добавлениеи, например, книги Трегубовой "Кремлёвские диггеры" пометить автора буквой "Б", а книгу буквой "Г" - это может быть моё законное отношение к данному произведению. И всё, фиг найдешь."
Это не минус зеленого решения. Это общая проблема. Например, авторы статей в блоги могут указывать не те рубрики. И что теперь, таксономией не пользоваться совсем?
Модуль CCK эту проблему не решает. Если у человека нет желания заполнять правильно, то он и в полях CCK все сможет заполнить неправильно.
jason32 says:"К тому же, так и остаётся нерешенным главный вопрос - как ОДНОВРЕМЕННО фильтровать например по первой букве автора, названия книги и жанру, а не по очереди - это предлагается достигнуть мифическим поиском, который никто никогда не видел, не делал и не писал, "
Что там писать-то? Пробежаться через API по базе Друпала, найти материалы нужного вида, проанализировать заголовки и оставить только те которые подходят под поиск. В качестве заготовки можно использовать один из сторонних модулей, который показывает список нод тем или иным способом.
jason32 says:"А поиск написать, господа - это нетривиальная задача, тем более с такими жёсткими ограничениями - я бы , например, не взялся бы за такой модуль."
Нужно писать не модуль, а PHP-кусок, который вставляется в текст страницы.
Причем применение CCK Ваш вопрос не решает. CCK не обеспечивает "ОДНОВРЕМЕННУЮ фильтрацию например по первой букве автора, названия книги и жанру, а не по очереди". Так что без разницы, как Вы храните данные - в стандартном виде или в через CCK - сложность написания Вашего поиска примерно одинакова.
jason32 пишет:"Таким образом, получаем число не портированных модулей под 4.7 - порядка 250,что менее трети от общего числа,"
Вы берете срез между 4.7 и 5.0 и делаете вывод, что с вероятностью 2/3 данные накопленные сторонними модулями будут целы. Это правильно, но только для одной смены API. Каждая смена API будет уменьшать этот процент сохраненных данных. Если бы Вы видели какой процент сторонних модулей 4.6 был портирован на 5.0, там много меньше половины. А если какой-то модуль был поставлен в версии 4.0 Друпала, то скорее всего его поддержка уже давно не осуществляется. На добровольных началах никакой автор не будет поддерживать модуль по 5 лет. За это время другие друпальщики сделают другой, более функциональный вариант модуля, на который перейдут все.
Скажите Вашим клиентам, что Вы будете накапливать данные сторонним модулем, который переживет смену API с вероятностью 2/3. А смена API случается каждые полгода-года. Думаю, не все клиенты не захотят играть в Вашу рулетку и каждые полгода переживать, сохранится в очередной версии Друпала поддержка накопленных материалов или нет.
Только использование стандартных способов Друпала для создания данных гарантирует 100% сохранность данных независимо от частоты смены API Друпала.
jason32 пишет:"в этом то и сила Друпала - в модульности, а не наоборот..."
Такое ощущение, что Вы только что вчера поставили первый сайт на Друпале. Или у Вас очень короткая память.
Создателям Друпала глубоко плевать на сторонние модули и на тех, кто ими пользуется и на Вашу любовь к сторонним модулям в том числе. Летом 2006 года создатели Друпала выпустили версию 4.7 с новым API. Друпальщики крякнули и стали переделывать старые модули и темы под новое API.
Создатели Друпала дождались, когда все, кто не потерял еще интерес к своим модулям и темам, обновили их. И зимой 2006-2007 года выпустил 5-ую версию Друпала. С новым API, разумеется. И для модулей и для тем.
Народ еще раз крякнул и на этот раз не спеша стал обновляться. В итоге прошел год, а модули и темы для 4.6 портированы в 5-ую версию меньше половины, остальные исчезли.
На носу 6-ая версия Друпала. Как думаете, создатели Друпала оставят в ней API для модулей и тем от 5-ой версии Друпала или сделают еще одни API?
А Вы пытаетесь опереться на сторонние модули, с которыми Друпал не особенно считается и регулярно выкашивает часть сторонних модулей с помощью смены API.
Сила Друпала - в стандартных модулях. Только с их помощью и нужно хранить данные. А сторонние модули использовать для украшательства и обработки данных, сохраненных в стандартных типах Друпала.
Угу, только в случае CCK я просто возьму вьюшку и никаких поисков писать не стану. Согласитесь, разница довольно большая. Как по скорости разработки, так и по потенциальным глюкам.
спасибо за статью. полезная почва для размышления
. капляопыт у меня ещё мал, но я за родное решение, зелёное
чую в таком русле возникать вопросов будет меньше в перспективе
Модуль CCK эту проблему не решает. Если у человека нет желания заполнять правильно, то он и в полях CCK все сможет заполнить неправильно.
Модуль CCK эту проблему РЕШАЕТ. Просто отпадает необходимость делать дополнительные словари по буквам, а готовых решений по фильтрации через Views по полям - куча, вон beer_destroyer чуть выше привёл пример, как можно просто и функционально сделать фильтр.
Причем применение CCK Ваш вопрос не решает. CCK не обеспечивает "ОДНОВРЕМЕННУЮ фильтрацию например по первой букве автора, названия книги и жанру, а не по очереди". Так что без разницы, как Вы храните данные - в стандартном виде или в через CCK - сложность написания Вашего поиска примерно одинакова.
Вообще, подобного грубого передёргивания я от Вас, Макс, как-то не ожидал. Никто не говорил, что ССК фильтрует - фильтрует Views по полям, которые делаются через ССК. И никакой поиск соответственно не нужен.
Скажите Вашим клиентам, что Вы будете накапливать данные сторонним модулем, который переживет смену API с вероятностью 2/3. А смена API случается каждые полгода-года.
Знаете, даже уже и обсуждать становится скучно. Ну плевать клиентам на обновление, обновление безопасности - да, а обновление ради обновления - это другое дело. Насколько я понимаю, версия 4.7 до сих пор поддерживается, а с момента выхода прошло достаточно времени. Если же и понадобится кардинальное обновление версий, то под это обычно выделяется бюджет. за который и решаются подобные проблемы, и я думаю, если там будут непортированные модули, то он ненамного увеличится - всё равно все программеры обычно закладывают решение подобных проблем в стоимость обновления.
Я вот посмотрю на обратную ситуацию - когда ВЫ скажете своим клиентам, что не будуте делать сайт счас, потому что через два года его сложно будет обновлять, и поэтому "вместо портала возьмите, мол, пож-ста систему поскромнее и попроще, эти функции вам не нужны, эти лишние, эти я из принципа делать не буду, и вообще, слушайте , что вам говорит разработчик, а не мелите отсебятины".
Я уверен, что после этого у вас с клиентами проблем не будет , так же как и самих клиентов.
Такое ощущение, что Вы только что вчера поставили первый сайт на Друпале. Или у Вас очень короткая память.
Создателям Друпала глубоко плевать на сторонние модули и на тех, кто ими пользуется и на Вашу любовь к сторонним модулям в том числе. Летом 2006 года создатели Друпала выпустили версию 4.7 с новым API. Друпальщики крякнули и стали переделывать старые модули и темы под новое API. и тд.......
Вообще попахивает уже переходом на личности, но я отвечу. ДА, Я считаю, что сила Друпала - в МОДУЛЬНОСТИ. Друпал из коробки обеспечивает очень вялую функциональность и надо очень много в нём копаться, чтобы понять , как с ним работать. Но сила Друпала - это то, что на нём можно сделать проект ЛЮБОЙ сложности , не используя патчи, и всё благодаря очень продуманному и мощному API. А запросы у клиентов могут быть ОЧЕНЬ разные - мне например приходилось писать модуль, чтобы обеспечить новую админку для Друпала - чтобы в ней не было ничего лишнего - того, чего не надо, и было всё в единой теме оформления и нигде не пересекалось с темой оформления сайта. И я это смог сделать без патчей.
Возможности Друпала из коробки перекрываются той же Джумлой или Wordpress, если не все, то большинство. Но когда у меня в наличии более 1000 готовых работающих модулей - то очень сложно найти, если не выёживаться, чтобы ещё захотеть.
jason32 says: Насколько я понимаю, версия 4.7 до сих пор поддерживается, а с момента выхода прошло достаточно времени
А модуль 4.6 уже не поддерживается, хотя еще чуть более года назад все ставили его за отсутствием 4.7. И поддержка 4.7 прекратится как только выйдет Друпал 6. Получаем, что данные со старыми модулями живут примерно год. Потом неизбежно должен произойти апргейд Друпала на свежую версию (иначе сайт начнут ломать). А после апргейда прощайте данные, накопленные на сторонних неподдерживаемых модулях.
jason32 says: "Я вот посмотрю на обратную ситуацию - когда ВЫ скажете своим клиентам, что не будуте делать сайт счас, потому что через два года его сложно будет обновлять,"
Я уже писал, выбор делает клиент. Я лишь претворяю его выбор. Хочется клиенту 50 модулей на сайте - можно их поставить. Нужно только предупредить клиента, что поддерживать такой функционал будет сложно.
jason32 says: "Но сила Друпала - это то, что на нём можно сделать проект ЛЮБОЙ сложности , не используя патчи, и всё благодаря очень продуманному и мощному API. "
которое меняется раз в полгода.
Так что все написанное с использованием API примерно с той же частотой надо переписывать.
jason32 says: "А запросы у клиентов могут быть ОЧЕНЬ разные - мне например приходилось писать модуль, чтобы обеспечить новую админку для Друпала - чтобы в ней не было ничего лишнего - того, чего не надо, и было всё в единой теме оформления и нигде не пересекалось с темой оформления сайта."
Очень интересный пример. И где сейчас Ваш клиент? Сидит с Вашей админкой под версией 4.7 Друпала и с ужасом ждет, когда прекратится поддержка версии 4.7? Или Вы собираетесь пожизненно бесплатно переписывать Вашу админку на все новые и новые API Друпала? Вы бессмертны?
Вы написали хорошую админку, но это одноразовая вещь. На полгода-год. А дальше клиенту снова придется искать программера на другую админку. И так пожизненно, пока эта суперадминка не отвалится при очередной смене версий Друпала. Вы хоть предупредили клиента, что Ваша супер-админка будет жить всего лишь полгода-год?
Тезисно:
Клиент, как правило, все это прекрасно понимает. Через 2 года, возможно, нужно будет вообще свою СМС писать, либо перейти на что-то, что мы сейчас даже знать не знаем еще.
А может клиент захочет какой-нибудь Битрикс, и вся ваша зеленка пойдет отдыхать, если не сказать грубее.
А может через 2 года Друпал так разрастется, вберет в ядро массу модулей и даже из коробки станет крут немерянно. Все возможно.
Господа , мы присутствуем при старом ораторском приемё - "здесь вижу, здесь не вижу". Смысл в том, чтобы в упор не видеть неудобных вопросов и педалировать удобные. Например:
Макс
CCK не обеспечивает "ОДНОВРЕМЕННУЮ фильтрацию например по первой букве автора, названия книги и жанру, а не по очереди". Так что без разницы, как Вы храните данные - в стандартном виде или в через CCK - сложность написания Вашего поиска примерно одинакова.
Модуль CCK эту проблему РЕШАЕТ. Просто отпадает необходимость делать дополнительные словари по буквам, а готовых решений по фильтрации через Views по полям - куча, вон beer_destroyer чуть выше привёл пример, как можно просто и функционально сделать фильтр.
Макс
Причем применение CCK Ваш вопрос не решает. CCK не обеспечивает "ОДНОВРЕМЕННУЮ фильтрацию например по первой букве автора, названия книги и жанру, а не по очереди". Так что без разницы, как Вы храните данные - в стандартном виде или в через CCK - сложность написания Вашего поиска примерно одинакова.
Вообще, подобного грубого передёргивания я от Вас, Макс, как-то не ожидал. Никто не говорил, что ССК фильтрует - фильтрует Views по полям, которые делаются через ССК. И никакой поиск соответственно не нужен.
Угу, только в случае CCK я просто возьму вьюшку и никаких поисков писать не стану. Согласитесь, разница довольно большая. Как по скорости разработки, так и по потенциальным глюкам.
Макс
При чем здесь продвинутый модуль поиска и вывода информации? Если таковой нужен, то его придется писать как при хранении данных стандартным для Друпала образом, так и для CCK. Или Вы считаете, что CCK сам включает в себя "продвинутый модуль поиска и вывода информации"?
То есть разговор зациклился -человек в упор не видит приводимого аргумента, что при использовании CCK не надо ПИСАТЬ никакого дополнительного модуля - можно сделать через Views безо всякого программирования. НЕТ, автор с упорством , достойным лучшего применения, пытается доказать, что надо использовать его мифический поиск, который то очень прост
- Что там писать-то? Пробежаться через API по базе Друпала, найти материалы нужного вида, проанализировать заголовки и оставить только те которые подходят под поиск. В качестве заготовки можно использовать один из сторонних модулей, который показывает список нод тем или иным способом., то превращается в сниппет - Нужно писать не модуль, а PHP-кусок, который вставляется в текст страницы., корочё, теоретизировать - не мешки ворочать, всё всегда легко и гладко, с таким же успехом можно и про Views сказать - ХА!, что там писать, проанализировал API и всего делов.
ну и дальше стандартные передёргивания....
Так что все написанное с использованием API примерно с той же частотой надо переписывать.Ага, только апшрейдиться нужно раз в два года, а не полгода, пототу что предыдущие версии поддерживаются.
которое меняется раз в полгода.
Очень интересный пример. И где сейчас Ваш клиент? Сидит с Вашей админкой под версией 4.7 Друпала и с ужасом ждет, когда прекратится поддержка версии 4.7? Или Вы собираетесь пожизненно бесплатно переписывать Вашу админку на все новые и новые API Друпала? Вы бессмертны?
"зелёный" - отвечает за правильный вывод данных, так что при его отсутствии просто будет стандартная админка . Причём в данном случае есть некоевидимо недопонимание - клиент в данном случае - это не хозяин сайта, а директор студии, который на этой админке делает пару десятков сайтов, и ему это вполне окупаемо.Впрочем, как и мне 
.
А с чего решили, что на 4.7 ? Админка под пятой версией, есть и под 4.7 - и что с ужасом то ждать, когда уже есть под пятую? Кроме того, если надо будет, то будет переход и на 6-ю, и для этого он наймёт следующего программиста, если я к тому времени отойду от дел. Что с того? Мало того, что это просто дополнительное излишество заказчика, так ещё и данный модуль
Или Вы считаете, что стандартно созданные Друпалом данные показывать сложнее, чем нестандартно хранимые данные, созданные модулем CCK?
Да,и к тому же я считаю, что при использовании CCK одновременно и проще работать и проще сделать более сложные вещи, чем без него. Один пример уже приведен, на который ответ так и не получен.
jason32 says: при использовании CCK одновременно и проще работать и проще сделать более сложные вещи, чем без него.
Вы правы. Я с Вами полностью согласен. Я всегда был есть и буду одного с Вами мнения, что с "использовании CCK одновременно и проще работать и проще сделать более сложные вещи, чем без него.". Как впрочем, согласен и с тем, что с использованием любого стороннего модуля можно делать более сложные вещи, чем него.
Теперь надеюсь что Вы скажете, что тоже понимаете о чем я говорю. Иначе это будет разговор с глухим.
О чем речь
"Зеленая" установка ориентирована не на то, чтобы проще делать сложные вещи. "Зеленая" установка заботится о том, чтобы была гарантия сохранности наработанных материалов.
Дают Ваш CCK и туча модулей создающие свои типы материалов, удобство в создании сложного сайта? Да, дают.
Дают Ваш ССК и туча модулей, создающие свои типы материалов, гарантию сохранности накопленных ими материалов? Увы, не дают. Зато такую гарантию дает "зеленая" установка.
Вы упорно не хотите видеть нацеленность "зеленой" установки на гарантированное долговременное использование накопленной на сайте информации. И пытаетесь потоптать "зеленую" установку на поле удобство создания сложных сайтов.
У меня такое ощущение, что Вы не поддерживали ни одного сайта больше года, если Вы ни разу не сталкивались с потерей материалов, созданных сторонними модулями.
Поправьте меня и скажите, что Вас тоже немного волнуют гарантии сохранности наработанных материалов. Слова что "ССК будет поддерживаться всегда" не признаются за полноценную гарантия. С поддержки отваливались еще и не такие плоды человеческого труда, как ССК.
Дают Ваш ССК и туча модулей, создающие свои типы материалов, гарантию сохранности накопленных ими материалов? Увы, не дают.
"Зеленая установка" это страховочный шаг от исчезновения стороннего модуля, так? Причем в наших дебатах, чаще всего, под сторонним модулем имеется в виду ССК (хотя говорить такое в отношении ССК просто смешно!) . Итак, предположим что я сильно ошибаюсь и поддержка ССК (или любого другого модуля) прекращена. Что же делать? "Все пропало, шеф"? Нет. Не пропало совсем ничего.
Скрипт для конвертации контента из CCK в простые текстовые ноды и таксономию пишется за час. Добавим на создание словарей и терминов еще 1-2 часа. Итого 3. Так что, Макс, проблемы я не вижу.
+1 Или Макс лукавит, или не в теме.
Данные из БД никуда не пропадут при любом, даже самом фантастическом раскладе. Могут, чисто теоретически, возникнуть проблемы с выводом/конвертацией. Но на самом деле конвертация действительно пишется весьма быстро. Это и в самом деле вопрос на несколько часов.
Но это теоретизирование. Куча сайтов с ССК и непременно кто-то напишет и выложит апгрейд этой системы моделей. Так что не придется даже напрягаться. Но если вдруг... см выше.
ultraboy@drupal.org says: Скрипт для конвертации контента из CCK в простые текстовые ноды и таксономию пишется за час. Добавим на создание словарей и терминов еще 1-2 часа. Итого 3.
Что-то Вы себе какие-то детские примеры подбираете. Сделали с помощью ССК ноду из заголовка и тела, накопили полон сайт информации и хвалитесь, что за 3 часа все сконвертируете наработанный материал в стандартные ноды.
А как насчет http://wiki.drupal.ru/ ? Когда она загнется, Вы тоже возьметесь за 3 часа все сконвертировать в стандартные ноды и таксономию?
Каждая накапливаемая информация имеет структуру. Если информация накапливается в структуре wiki, то ее автоматическая конвертация в стандартные ноды и таксономию невозможна. Кто должен будет сидеть и ручками раскладывать 10 тысяч статей по новой древообразной структуре таксономии, которую еще предстоит создать.
Заглянем в название вашей статьи: "Зеленая" база данных на Друпал (база артистов, недвижимости, библиотека, видеокаталог,...)". Скажите, зачем вы уже который раз ни к селу ни к городу вики упоминаете?
Вики - вообще другая программа со своей организацией контента. И если уж что-то куда-то переносить, то из одной вики в другую вики, благо таких скриптов достаточно на любой вкус.
Я чуть выше Вам персонально написал: Вики, Форум и т.п. надо делать отдельными, не связанными с основным сайтом и вообще с Друпал программами. Максимум, что может понадобится - модуль переноса пользователей, чтобы не заставлять их дважды регистрироваться. Что не понятно в этой концепции?
И "ручками" ничего раскладывать вообще не надо на "10 000 статей" - надо писать конвертер.
Но речь, вообще говоря, совсем о другом идет. Не надо уводить в сторону.
Вот развели дискуссию, а про мой вопрос все забыли. Никто не слышал про Drupal tools? Это что такое, инструмент для захвата контента? Есть хоть что-нибудь такое для Drupal?
Скрапбука для Drupal нет - это вам, скорее, к отдельным программам-грабберам или к браузерам.
В Drupal можно получать информацию с других сайтов через ленты RSS и даже конвертировать их содержание в материалы собственного сайта (модуль Leech).
От себя добавлю, что если поддержка CCK авторами прекратится - выстроится огромная очередь программистов, лишь бы им позволили портировать и поддерживать модуль в дальнейшем - я бы сам бы этим бы с удовольствием занялся бы, ибо это гарантия имени и гарантия заказов, знаете - "разработчик модуля CCK" - это звучит круто, а портировать модуль под новую версию занимает день, от силы два, и то, если сильно не напрягаться
.
И возникнет куча модулей переконвертации. Потому что столь востребованный модуль просто так в никуда пропасть не может.
Макс, кстати, и тут лукавит: "и не такое отваливалось" - что, простите, отваливалось уровня ССК, без появления публичного модуля конвертации в аналог?
Давайте проведем эксперимент: пусть разгонка.ру объявит тендер на модуль конвертации контента ССК в стандартные ноды за 200 баксов, напрмер. Готовы пожертвовать 200 баксами? Это и покажет, кто из нас прав. Или же вы согласны, что за 200 баксов это можно сделать?
Макс, вопрос задан прямо и требует прямого ответа. Для апгрейда серьезного проекта 200 баксов это вообще не бюджет, но остановимся на этом.
Если же вы согласны, что за 200 баксов все светофорные проблемы решаются, то зачем городить "зеленые" огороды и пугать читателей/заказчиков выдуманными страшилками?
jason32 says: От себя добавлю, что если поддержка CCK авторами прекратится - выстроится огромная очередь программистов, лишь бы им позволили портировать и поддерживать модуль в дальнейшем
Очередь говорите?
Drupal.ru стоит у Акселя на квартире, выстроилась огромная очередь желающих помочь, лишь бы им позволили перенести Drupal.ru на нормальный хостинг и настроить все как надо, а сервер сайта Drupal.ru как стоял у Акселя на квартире так и стоит.
Так что обломится и Вашей огромной очереди желающих порулить модулем CCK.
jason32 says: я бы сам бы этим бы с удовольствием занялся бы, ибо это гарантия имени и гарантия заказов, знаете - "разработчик модуля CCK" - это звучит круто,
В Вашем лексиконе появилось слово "гарантия". К сожалению, гарантировать Вы хотите только себе заказы. И умалчиваете, как Вы собираетесь обеспечивать гарантию данных, созданных с помощью ССК.
А обеспечить гарантию данных, накопленнных с помощью модуля CCK невозможно. CCK-данные будут теряться:
- просто так из-за глюков CCK
- из-за того что какой-то сторонний модуль решил подраться с CCK
- во время апргрейда Друпала новая версия CCK может не подхватить данные от старой версии CCK
- во время апргейда Друпала на поддержке сайта может оказаться друпальщик, никогда не работавший с CCK
- автор CCK может быть оторван от поддержки CCK, но с оставшейся надеждой продолжить его поддерживать, так что ключи от CCK он никому не передаст
- Друпал вберет в себя основную часть возможностей CCK и продолжение его выпуска станет нецелесообразным
- появится модуль NewCCK, который будет делать все то же самое, что и CCK, но только на голову лучше и CCK захиреет за отсутствием вливания новых пользователей CCK
- Друпал запретит сторонние модули, которые создают свои типы информации
- ...
Только данные, сохраненные стандартными модулями Друпала, будут гарантированно сохраняться годами, только успевай апргейдить Друпал.
Нестыковка наших позиций
Вы ищете гарантию Вашей занятости, я ищу гарантии сохранности данных клиента.
Для гарантии Вашей занятости ставьте каждому клиенту на сайт CCK, а еще лучше самописный аналог модуля node, через который будет накапливаться всю информацию на сайте. Для полной гарантии занятости организуйте хитроумную шифрацию всех данных, хранимых этим модулем. Тогда клиенты будет пожизненно обязан держать Вас на сайте для периодического апргрейда Вашего самописного варианта модуля node.
Если Ваш клиент вздумает взять на поддержку сайта другого друпальщика, то после первого же апргейда Друпала отвалится поддержка всей накопленной информации. Это даст Вам возможность сказать строптивому клиенту: "Ну вот видите, от какого бриллианта в виде меня Вы отказались. При мне годами все было нормально."
Я же иду от интересов клиента. "Зеленая" установка позволяет клиенту гарантированно сохранять данные независимо от апргейда Друпала и смены друпальщиков на поддержке сайта. Когда клиент на поддержке сайта заменит меня на другого специалиста, все материалы сайта остаются в сохранности и после апргейда Друпала. Моя занятость не гарантирована, зато гарантирована сохранность всех материалов на сайтах моих клиентов. Для меня это важно.
Прошу прощения у всех, у кого другие приоритеты в профессиональной деятельности, чем мои. Я сам раньше был как и вы, все заботился о своей занятости. Но нашлись умные люди, подсказали нужно смотреть в другом направлении. И когда я стал заботится об интересах клиентов, заказов стало гораздо больше.
Окройте страшную тайну: как эти "ключи от CCK" выглядят? Простите за вопрос, но вы там ничего изменяющего сознание не употребляли накануне?
Любые данные сохранятся вечно при регулярном бэкапе. Вам предложено выделить 200 баксов и вам наглядо покажут, как данные ССК перегнать в стандартную ноду. Что-то я ответа не вижу... Игнорируем неудобные вопросы?
Макс, видите себя достойно. В том числе умейте достойно проигрывать. Подобные нападки на коллег, причем не спрвоцированные, совсем не украшают вашу студию. Это вообще не этично - вести конкуренцию такими методами.
Вы сейчас как знахарь в диспутах с медиками. Они вам про науку, вы им про кармические за*бы. Зашлакованность организама, очистку ауры и прочую белиберду. В вашем случае любимый конек - "зеленая" установка.
Это противно читать. Если ваши клиенты настолько идиоты, что на это ведутся - флаг и вам и им в руки. Хорошо бы нашлись другие умные люди, кто объяснил бы вам - так вести конкуренцию не этично.
Знаете что вы сейчас сделали? Вы обвинили человека и ни приведя ни единого доказательства. Вы сознательно оклеветали конкурента.
Да, я его не знаю лично, но судя по постам, человек этот грамотный и весьма достойный. Да, мы с ним конкуренты, я тоже хочу хороших заказчиков. Но я против конкуренции через клевету. В конце концов надо быть мужиком, хоть это сейчас и не модно.
Знаете, Макс, что такое разгильдяй? Это чмо, которое выгоняют из гильдии за неэтичное поведение. Ну там слово не сдержал... Жаль, нет гильдии установщиков Друпала.
Знаете, что я бы сделал на месте Акселя? Отключил вас пожизненно. Тусуйтесь на своей разгонке, вешайте любую лапшу клиентам, но это не должно иметь отношение к официальному сайту русской поддержки Друпал.
Остальные еще не высказались, но если это не только мое мнение - думаю, стоит написать Акселю для принятия соотв. мер.
Мне за вас стыдно, Макс.
Не обоснованно.
Любая речь должна иметь обоснование.
Иначе ты становишься треплом.
Покажи мне твои сайты умник.
Чем ты можешь похвастаться? ЧТо ты приведёшь в защиту своего мнения, кроме трёпа?
Я уверен на 110% в том, что все твои зелёные сайты на столько убоги, насколько это возможно в принципе.
Что оправдывает кстати вашу цену -- 200-500 долларов.
А я так скажу. Когда есть задачи которые нельзя решить стандартными способами, а такое встречается сплошь и рядом, как ни крути - внедрять свои программные решения придётся. Вот тут то, весь твой монолог, про пользу "двухсотбаксовой" работы идёт в тар-тара-ры.
я готов за 200 баксов этим заняться
И я, и я!!! Ладно, не буду сбивать цену.
У Макса осталось или пожертвовать баксами, или сразу согласиться, что проблема не стоит выеденного яйца.
200 (допустим) баксов, и "потерянный" конктент становится стандартной нодой. Конечно, при этом возникнет куча "зеленых" проблем с поиском, но Макс обещает их легко решить.
На самом деле с поиском он прав: такой поиск в принципе можно написать. НО! Такой поиск будет обходить ВСЕ ноды и настолько сильно грузить сайт, что ну его нахрен такую зелень.
Представим, хотя бы 20 посетителей одновременно запустят поиск, который просмотрит весь контент... Выделенного сервера может не хватить.
Можно сделать индексирование, еще как-то извратиться, но грузить все равно будет, хоть и меньше.
Все это зеленое рещение суть переборка двигателя через выхлопную трубу. Можно теоретически, но глупо практически.
Все это зеленое рещение суть переборка двигателя через выхлопную трубу. Можно теоретически, но глупо практически.
Вот с этим мнением я полностью согласен. У меня это вызвало ассоциации с удалением гланд через зад. К чему эти цветные решения, если есть модули. Если бы любую задачу удобнее всего бы было решить именно стандартными модулями друпала, то на кой чёрт потребовались бы модули? Зачем сотни разработчиков пишут весь страшный и запутанный код?
Модули вроде CCK и Views будут жить! По крайней мере до тех пор, пока их функционал не войдёт в стандартную поставку друпала. И как уже где-то выше мелькала мысль, если одни разработчики уйдут, то останутся другие.
С поддержки отваливались еще и не такие плоды человеческого труда, как ССК.
А Drupal - это вечный проект, ему отвалиться не суждено. И если вдруг drupal перестанет обновляться, то мир рухнет.
Дают Ваш ССК и туча модулей, создающие свои типы материалов, гарантию сохранности накопленных ими материалов? Увы, не дают.
Такого заявления я ещё не читал. А куда, позвольте узнать, все данные из БД исчезают? Интересен ваш взгляд на эту проблему. Будем искать пропавшие биты и байты вместе. Следствие ведут колобки.
Зеленая установка говорит только о хранении данных стандартным для Друпала способом.
А сторонние модули хранят данные в отдельной коробке в шкафу. Ахтунг.
У меня такое ощущение, что Вы не поддерживали ни одного сайта больше года, если Вы ни разу не сталкивались с потерей материалов, созданных сторонними модулями.
У меня почему-то сложилось впечатление, что этот человек просто понимает, что он делает. И понимает откуда на сайте берутся и как выводятся данные.
Макс, раз уж ваше творение именуется "студией", то вам, как мастеру, следовало бы заботиться не о "зелёных" установках, а о выполнении конкретной задачи наилучшим способом с точки зрения заказчика. Неужели заказчиков так волнует номер версии друпала? И вообще неужели его так сильно волнует что именно за CMS будет использована? Или заказчики - фанаты drupal?
Сайт должен работать, им должно быть удобно управлять, а остальное - дело программистов и тех. поддержки. Дыры в безопасности (коих афишируется не так и много) регулярно закрываются. А "непробиваемых" сайтов нет.
http://fsb.ru/ ? По их заявлениям, минимум 10 раз в день ломать пытаются.
Ясень пень, живет он на совсем отдельной машине и никакие внутренние сети к нему не подходят. Во избежание, так сказать... Но сам сайт неломаем, но мне удалось его положить! Но это совсем другая история, тут оффтопик.
А обеспечить гарантию данных, накопленнных с помощью модуля CCK невозможно. CCK-данные будут теряться:
Вы уже который раз утверждаете, что данные будут теряться. Ну куда, куда скажите мне они потеряются??? И неужели вы считаете, что используя CCK разработчики пытаются обеспечить себя работой до конца существования проекта? ))
Считает-считает. По кр. мере так пишет.
неожиданный поворот беседы - я то думал, что после приведенных аргументов дискуссия заглохнет, но Макс решил перейти на личности - так всегда бывает , когда доводов не хватает. Итак :
jason32 says: От себя добавлю, что если поддержка CCK авторами прекратится - выстроится огромная очередь программистов, лишь бы им позволили портировать и поддерживать модуль в дальнейшем
Drupal.ru стоит у Акселя на квартире, выстроилась огромная очередь желающих помочь, лишь бы им позволили перенести Drupal.ru на нормальный хостинг и настроить все как надо, а сервер сайта Drupal.ru как стоял у Акселя на квартире так и стоит.
Так что обломится и Вашей огромной очереди желающих порулить модулем CCK.
Видимо, немного неэтично обсуждать других людей, тем более в их отсутствие, но тем не менее... Перенести сайт на Другой хостинг - извините, я вас правильно Макс понял? Для вас это подвиг? Перезалить файлы и базу? Я могу перенести его на любой хостинг, если будет нужно, за пару часов, и то только потому так долго, что интернет канал слабоват. Просто,насколько я понимаю, drupal.ru , плюс к тому, что он является сайтом русского сообщества Дурпала, к тому же коммерческий проект. Этот сайт приносит владельцу деньги. По крайней мере, при такой раскрученности и посещаемости он должен их приносить. Что это вообще за передёргивание? Кто вообще говорил об альтруизме вообще и при написании CCK в частности? Говорилось о том, что портировать модуль на новую версию легко, и если вы смотрели изменение API с четверки на пятерку, то обратили внимание, что в основном там идут изменения при выводе - немного поменялось form API, немного LINK API, но в общем то мелочь.
CCK-данные будут теряться:
- просто так из-за глюков CCK
- из-за того что какой-то сторонний модуль решил подраться с CCK
- во время апргрейда Друпала новая версия CCK может не подхватить данные от старой версии CCK
- во время апргейда Друпала на поддержке сайта может оказаться друпальщик, никогда не работавший с CCK
- автор CCK может быть оторван от поддержки CCK, но с оставшейся надеждой продолжить его поддерживать, так что ключи от CCK он никому не передаст
- Друпал вберет в себя основную часть возможностей CCK и продолжение его выпуска станет нецелесообразным
- появится модуль NewCCK, который будет делать все то же самое, что и CCK, но только на голову лучше и CCK захиреет за отсутствием вливания новых пользователей CCK
- Друпал запретит сторонние модули, которые создают свои типы информации
Это по пунктам , хотя даже как-то комментировать смешно.
тут тоже можно посмеяться, но для начала вспомните, по какой лицензии всё это делается... но про ключи это пять!!
- просто так из-за глюков CCK - просто так - будут и будут, мало ли, это ж программирование, страшная штука, там всякое может быть
- из-за того что какой-то сторонний модуль решил подраться с CCK - не иначе, что на мечах...
- во время апргрейда Друпала новая версия CCK может не подхватить данные от старой версии CCK - аналогично первому пункту, может и может, дело тёмное, лень ему в тот день будет подхватывать, вот и не подхватит
- во время апргейда Друпала на поддержке сайта может оказаться друпальщик, никогда не работавший с CCK - уборщица баба Маша за работой вместо программера? Тогда да, а ещё лучше пугаться, что на поддержке сайта может оказаться человек, никогда не видевший компьютера - вот где ужасы то
- автор CCK может быть оторван от поддержки CCK, но с оставшейся надеждой продолжить его поддерживать, так что ключи от CCK он никому не передаст
- Друпал вберет в себя основную часть возможностей CCK и продолжение его выпуска станет нецелесообразным
ДА!!! Здорово!!! Это всё давно хотим!!!! Это значит, что Друпал обеспечит авто конвертацию при переносе данных, и никак иначе, или же добрые люди сварганят сами этот перенос!!!
- появится модуль NewCCK, который будет делать все то же самое, что и CCK, но только на голову лучше и CCK захиреет за отсутствием вливания новых пользователей CCK - Дык кто же против, только он не сможет перебить CCK без конвертации из его формата в свой
- Друпал запретит сторонние модули, которые создают свои типы информации - если с предоставлением замены своим стандартным, то не проблема, а иначе с Друпалом случится то же самое, что с мамбой и Джумлой- люди не будут идти на поводу у таких идиотов и на основе нормальной версии Друпала создадут NewDrupal - вспоминаем опять про лицензию, на которой разрабатывается Друпал.
Ну и под конец про большой абзац , озаглавленный Нестыковка наших позиций. Это как то даже комментировать противно.
Свои же слова приписали мне, их обхаяли и обмазали гавном, заодно и со мной всех остальных, кто использует этот страшный модуль CCK и ,по-вашему,плюёт на интересы клиентов. В общем, перефразируя сказанное, "Вы все тут идиоты( или эгоисты) - один я Д'Артаньян".
Прошу прощения у всех, у кого другие приоритеты в профессиональной деятельности, чем мои. Я сам раньше был как и вы, все заботился о своей занятости. Но нашлись умные люди, подсказали нужно смотреть в другом направлении. И когда я стал заботится об интересах клиентов, заказов стало гораздо больше.
так что , господа Друпальщики , "неправильной дорогой идём товарищи"
Разговор начинает переходить немного на личности.
Рациональное зерно есть в словах моих уважаемых оппонентов. Равно как и в моих. Я прекрасно понимаю ваши доводы, я сам был таким как вы (см. "Веб-программирование, 7 ступенек в рай").
Давайте попробуем подняться от конкретных деталей как CCK, wiki,... и посмотреть на все сверху.
Техническая статья
Начнем с того, что эта статья не концептуальная, а техническая. Она показывает один из способов ведения информационных баз данных.
Подобная статья уже есть в моем дневнике "Модули ссылок, обзор и "зеленое" решение", там всего пара отзывов, как это и должно быть у технической статьи. Серию "Практика зеленых решений" планирую продолжить.
Мало кто из клиентов целенаправленно заказывает "зеленую" установку. Вряд ли ваши заказы дрогнут и спадут хоть на миг и от этой технической статьи.
Неосознанность "красной" установки
Не думаю, что специалисты с Drupal.ru тяготеют к "красной" установке осознанно.
У одних установщиков слишком короткий срок ведения веб-проектов или их малое количество. Сегодняшние возможности радуют, что будет завтра мало кого волнует потому что завтра у большинства еще не наступило.
У других установщиков большой опыт, но их никогда не волновало что происходит с проектом после того как они перестают получать деньги за поддержку проекта.
Целенаправленная "красная" установка
Целенаправленная "красная" установка больше типична для некоторых больших веб-фирм. Там сидят профессионалы и они целенаправленно привязывают своих клиентов на самописные движки от фирмы. Это гарантирует, что клиент долго еще не сможет уйти от такой фирмы.
Вытащить сайт у такой фирмы крайне сложно. Движок они не дают под предлогом того что это "авторский код". Данные без движка представляют странную смесь, разбираться в которой сложно. Часто единственным способом перехода сайта на поддержку к новому специалисту является скачка сайта через офф-лайновый браузер, парсинг и импорт в новый движок.
"Красное" удерживание клиентов
Я не осуждаю такие фирмы, которые нацелены на удерживание у себя клиентов любой ценой. Каждый делает бизнес на том, в чем он силен.
Одно время похожий бизнес был у хостингов. Они за деньги клиента регистрировали домен на свое имя. Когда через несколько лет клиент собирался уходить, ему говорили: "Забирайте HTML-содержание сайта, оно Ваше. А домен не Ваш. Но мы не против, чтобы Вы продолжали размещать Ваш сайт на нашем домене, если будете продолжать платить за хостинг.".
"Зеленая" покупка домена
Время поставило все на свои места. Сейчас все регистраторы доменов крупными буквами пишут: "Домен будет зарегистрирован на Ваше имя". Регистрацией на свое имя грешат лишь некоторые провайдеры. И иногда еще встречаются акции от мелких хостингов "Покупаете хостинг на полгода - домен в подарок", при этом хостинги пишут домен на свое имя. Раз клиент денег за подаренный домен не платил, то у него нет оснований для формальных претензий.
Бизнесы регистраторов доменов и хостингов разделились. Теперь хорошим тоном стало покупать домен у регистратора, а держать сайт у хостера. И есть простой механизм, который позволяет владельцу домена сменить хостинг в течение суток без всякого согласия на то старого хостинга. Владение доменом стало означать владение сайтом. Можно сказать, что "красные" способы удержания клиента через домен сошли на нет.
"Позеленение" способов удержания клиентов
По мере проникновения CMS и прочих массовых движков отойдут в небытие сайты, сделанные на самописных движках. И веб-фирмы будут крупными буквами писать у себя на главных страницах "Мы делаем сайты на стандартном движке таком-то".
Позже большинство уважающих себя фирм будут писать "Мы делаем зеленую установку", что будет означать гарантию полной сохранности информации клиента вне зависимости от того, кто находится на поддержке сайта.
А еще позже никто ничего писать не будет, потому что "зеленая" установка станет нормой.
Будущее
- клиент сможет сменить фирму на поддержке его сайта в течение суток без всякого согласия на то фирмы
- клиент сможет в течение суток найти другого специалиста на поддержку сайта
- у клиента будет сохранено 100% всех его данных при ближайшем апргейде движка.
Это очевидные требования. Лет через 5 большинство веб-фирм будут обеспечивать их. Удержание клиента будет делаться не "красной" привязкой к себе, а хорошей работой по сайту.
Разумеется, в будущем у клиента останется возможность заказать "красную" установку. Когда будете регистрировать очередной домен, попросите хостинг зарегистрировать Ваш домен на имя хостинга. Желание клиента - закон.
Говоря точнее - ни одного. Потому что ни одного зеленого сайта вы так и не смогли показать. Имеются ввиду сайты, где по логике требуются дополнительные поля и дополнительные возможности, где ССК и вьюшка просятся, а не просто установка из пакета - этого везде достаточно.
И Васюки станут центром не только мировых, но и вселенских шахмат. Остапа несло.
Опять с упорством продвигается тезис о потери данных. Теряются они, и все тут. Человек 5 пытаются объяснить, что данные никуда не теряются, что это нонсенс, что не надо пудрить мозги наивным ньюбам и заказчикам. Хоть кол на голове теши.
Знаете кого мне это напоминает? Производителей растительного масла "без холестерина". Домохозяйкам не всегда очевидно, что холестерин - животный белок, и в растительном масле его просто не может быть по определению. Если его туда специально не внести, конечно.
И данные никуда не денутся. Если их специально не уничтожать. Надеюсь, большинство заказчиков это понимает.
Целенаправленная "красная" установка
Целенаправленная "красная" установка больше типична для некоторых больших веб-фирм. Там сидят профессионалы и они целенаправленно привязывают своих клиентов на самописные движки от фирмы. Это гарантирует, что клиент долго еще не сможет уйти от такой фирмы.
Вытащить сайт у такой фирмы крайне сложно. Движок они не дают под предлогом того что это "авторский код". Данные без движка представляют странную смесь, разбираться в которой сложно. Часто единственным способом перехода сайта на поддержку к новому специалисту является скачка сайта через офф-лайновый браузер, парсинг и импорт в новый движок.
А вот и примерчик подоспел - примерчик злобных замыслов либо непрофессионалов, либо злобного привязывания к себе калёным железом. Тут и картинка кощунственная приводится - что ж мире то творится, надо срочно раскрыть глаза Уважаемой газете на то, куда её тащут несознательные разработчики - не иначе, как в пропасть и финансовую могилу.
PS кстати, как можно "по-зеленому" реализовать такой сайт или хотя бы "по-зелёному" сформировать данные так, как показано на вышеупомянутой картинке? Сможете привести рецептик? Думаю, что нет.
"Зеленая" покупка домена
Время поставило все на свои места. Сейчас все регистраторы доменов крупными буквами пишут: "Домен будет зарегистрирован на Ваше имя". Регистрацией на свое имя грешат лишь некоторые провайдеры. И иногда еще встречаются акции от мелких хостингов "Покупаете хостинг на полгода - домен в подарок", при этом хостинги пишут домен на свое имя. Раз клиент денег за подаренный домен не платил, то у него нет оснований для формальных претензий.
Бизнесы регистраторов доменов и хостингов разделились. Теперь хорошим тоном стало покупать домен у регистратора, а держать сайт у хостера. И есть простой механизм, который позволяет владельцу домена сменить хостинг в течение суток без всякого согласия на то старого хостинга. Владение доменом стало означать владение сайтом. Можно сказать, что "красные" способы удержания клиента через домен сошли на нет.
Ну вот, приехали, пошла уже полная подмена понятий. Думаю, логичным продолжением такой линии должно стать утверждение, что Красный цвет агрессии, а зелёный цвет способствует отдыху глазам( что совершенная правда, кстати) и на этом основании Зёленая установка Макса безусловно лучше красной агрессивной установке остальных. Ну не смешите, при чём тут вообще домены, не валите всё в кучу, нечего сказать - не говорите.
Кстати, такой вывод данных можна реализовать css и без CCK (против него ничего не имею
Максу, я в список участников твоей студии не просился, удали меня из него пожалуйста.
romand@drupal.org says: "такой вывод данных можна реализовать css и без CCK"
Да, часто используют CCK, потому что не умеют (или не хотят) пользоваться другими доступными способами работы с содержимым и его показом: css, назначение новых типов материалов средствами Друпала, таксономией,...
Вместо изучения всех стандартных возможностей Друпала многие друпальщики часто склонны по быстрому решить проблему через применение стороннего модуля.
Чем больше практикую "зеленую" установку, тем сильнее убеждаюсь в следующем. Для многих задач можно обойтись данными, созданными стандартными для Друпала способами. Результат будет примерно такой же, как и в случае применения сторонних модулей, создающие свои собственные данные. Но зато в "зеленой" установке появляется гарантия сохранности данных.
romand@drupal.org says: удали меня из него пожалуйста.
Удалил со страницы "Установка сайтов" и "О студии Razgonka.ru". Также переместил твои предложения по новой студии в отдельный топик на форуме Razgonka.ru. Там же ответил пару недель назад.
Гораздо чаще придумывают маркетинговую фигню типа "кремлевская таблетка", "золотая серьга", "зеленая установка", "новый суперсжигатель жира", "амулет от сглаза", "ультразвуковая стиральная машина" и пр. и впаривают это доверчивым покупателям. В основном покупательницам - тем проще впарить.
romand@drupal.org
Задача не в том, что это надо реализовать без ССК - надо реализовать стандартными средствами. Мне интересно, как вы это видите. Приведите пример и описание.
Не совсем понял вопрос. Я имел ввиду, что вывод ноды согласно приведённому выше изображению (http://cyrve.com/screenshots/mccain.jpg) можна оформить (спозиционировать) с помощью css, типа:
.node .byline {...}
.node .image {...}
.node .photocredit {...}
предварительно создав элементы класов в теле материала
...
<span class="photocredit">...</span>
Ну, Вы понимаете. Согласен, что при вводе на каждый елемент своё поле ЦЦК удобнее и далее их можна использовать в видах (хотя в данном случае в этом не вижу смысла).
Если Вы имели ввиду создание такого сайта стандартными средствами, то, конечно, без использования видов это будет глупо. Но они, views, не противоречат цветовым предпочтениям т. Максима
Красный цвет агрессии, а зелёный цвет способствует отдыху глазам( что совершенная правда, кстати) и на этом основании Зёленая установка Макса безусловно лучше красной агрессивной установке остальных.
Автор, ещё! )))
Б*я, Макс, ну вы себя считаете центром вселенной? В своей статье про веб-программирование вы расписываете как вас уважали коллеги, в то время как здесь вы утвержаете что данные мистически исчезают. Да куда же, их мать, они исчезают? Преобладающее большинство участников drupal.ru немощные дебилы? Неужели здесь никто ничего не понимает в сайтостроении и вы первый, кто догадался использовать только стандартные модули? Никто не держит сайты больше года, а только вы один? Да если бы модули стандартной поставки были самыми удобными для реализации всех замыслов, стал бы кто из разработчиков по всему миру тратить своё время на написание и поддержание сторонних модулей? А ведь есть дети, семьи..
Будущее
- клиент сможет сменить фирму на поддержке его сайта в течение суток без всякого согласия на то фирмы
А без хвалёной зелёной установки не сможет... Требуется письменное разрешение техподдержки в двух экземплярах. Без него никак.
- клиент сможет в течение суток найти другого специалиста на поддержку сайта
Без зелёной установки, конечно же, не найдёт. И если найдёт, то займёт это тридцать лет и три года.
у клиента будет сохранено 100% всех его данных при ближайшем апргейде движка.
Ну это уже избитая тема... Напоминает мне афоризм:
Компьютер не поддается законам физики. Только в нем глюки появляеются из ниоткуда, файлы пропадают в никуда; только в нем объем измеряется в метрах и называется весом..
По вашим представлениям данные клиента бесследно исчезнут.
Увы, для серьёзных веб-разработчиков знания только лишь возможностей определённой CMS недостаточно! Как уже и начинает не хватать знания лишь PHP и CSS. Если клиент заинтересован в поддержке сайта (другого термина не подберу) ламером, то это одно дело. Ну писали бы веб-приложения на brainfuck'e (образно) - тогда бы уже стоял вопрос о поиске техподдержки. Ну разве не пишут модули на давно известном PHP? Ну разве код модулей не комментируют разработчики (в том числе и для своего же удобства)? Ну разве квалифицированный специалист, призванный обеспечивать работу сайта, не сможет немного поработать руками и головой и написать пару строчек кода? Уж кого, а разработчиков на drupal сейчас немало.
Ну так можно вместо использования тех форм, которые создаёт CCK при добавлении материалов, сделать разок таблицу в дриме красивую, пихнуть код в инструкцию по добавлению материала и требовать от всех пользователей, создающих содержание копировать/вставлять и заполнять только её. Возвращаемся к удалению гланд через задницу.
Т.е. использовать возможности css по полной - я только поддерживаю. Но в определённых случаях.
А вот я придумал "зеленый" автомобиль!
Дело в том, что некоторые недобросовестные производители привязывают к себе покупателя, заставлют покупать запчасти, менять прокладки, перезаливать масло... А недобросовестные металлурги утверждают, что, де, для каждой движущийся детали требуется, де, только сталь определенной марки и сложная металлобработка.
К тому же, детали обычного металлического автомобиля всегда куда-то исчезают. Я пока не могу сказать куда, но точно исчезают. Вот вчера оставил как обычно под окном - так колеса и магнитолу как рукой сняло.
Если вы задумаете превратить свои Жигули в Бентли, у вас это не получится в случае металлического автомобиля! А зеленый автомобиль можно заапгрейдить хоть до БелАЗа.
Автомобиль из дерева лишен всех недостатков! Для его ремонта вы можете нанять любого, кто владеет топором и долотом. Или даже изготовить любую деталь самостоятельно! К тому же, деревянный автомобиль не ржавеет.
К сожалению, мне такой автомобиль никто не заказал и я пока не могу вам его продемонстрировать. Но идея красивая, правда?
Некоторые недобросовестные автомобилестроители утверждают, что такой автомобиль не поедет. Приводят какие-то формулы, расчеты... Но все это только для того, чтобы еще больше привязать к себе покупателей.
Закажите у моей студии зеленый автомобиль!
PS. Сейчас мы работаем над созданием зеленых сверхзвуковых самолётов, зеленых ракет и зеленых танков по заказу минобороны. Но это пока секретные проекты.
=======================
Ну разве можно эту тему воспринимать серьезно? Куча народа убеждает одного, который принципиально не хочет ничего слышать.
>>Для удобства работы с библиотекой заведите несколько словарей и "повесьте" их на тип "Описание книги".
>>1. Словарь из 33 пунктов, в каждом пункте по одной букве. Этот словарь используется для указания первой буквы фамилии автора книги.
Вам не кажется, что на некоторые буквы нето что фамилий, слов-то нийуха нет и в принципе быть не может?
Ё и Й спорный вопрос.
Ъ,Ь, например...
гляньте, ваша зеленая установка попала в в интернет-мемы на википедию)))
http://ru.wikipedia.org/wiki/Интернет-мем
последняя заметка в разделе "Слова, фразы" - «Зеленая» установка
От прицепились вы к человеку... Он между прочим дело пишет. Я не сталкивался с описанными им вещами в веб-разработке, пока. Но сталкивался в проектировании ( я перепрофилировался недавно) когда в чертёжной проге менялся апи и неподдерживаемые разработчиком проги библиотеки переставлаи работать то встаёт выбор или обновляцца и сидеть без нужных библиотек или сидеть на старой версии. А не обновляться до появления всех этих библиотек не интересно, потому что с новой версией появляется много чего интересного. Но в данном случае этот пример не корректен, потому что данные сгенерированные ими хранились в стандартном фрмате... Но всё таки.
Далее - а не хочу я платить $200 за перенос базы из-за того что модуль не подхватил данные.