20 октября 2009 в 12:11
Наконец разработка Drupal 7 дошла до состояния, когда результат можно поставить и попробовать (до этого много раз я пытался установить текущий билд, но ошибки убивали надежду еще до окончания установки). Так что всем интересующимся рассказываю, что нового ждет нас в Drupal.
Прежде всего, немного о цикле разработки. В начале сентября был объявлен Code Freeze: остановился прием патчей, добавляющих или изменяющих функциональность и API Drupal. После этого до 15 октября принимались патчи строго ограниченной тематики (чтобы довести начатое до конца), а теперь в ход идут только багфиксы. До релиза еще несколько месяцев, проблем много, но есть надежда на то, что внедренные к этой версии фреймворки автоматического тестирования помогут быстрее их исправить. В этом году релиза не будет точно, да и бета вряд ли поспеет.
Основной состав изменений для Drupal — это подстройка под хотелки пользователей, интегрирование функциональности очень популярных "апишных" модулей в ядро системы и шлифовка самых отвратительных углов ее программных интерфейсов. Направление "полу-фреймворк, полу-cms" остается неизменным.
Итак, что увидят юзеры:
Новая тема админки. Сменилось как визуальное оформление (оно стало значительно современнее), так и логика работы:
Теперь сверху все время торчит панель со ссылками на популярные разделы меню. Сама админка переконфигурилась, отдельно вынесены разделы "контент", "структура", "пользователи" и "вид".
Мне это показалось логичным, но слегка непривычным для матерых друпалистов (хотя я, кажется, переучусь очень быстро). Расстраивает, правда, что меню сверху не выпадучее: сам-то я всегда ставлю модуль admin_menu, который рисует сверху менее логичное (в старой логике), но более удобное из-за раскрывающихся пунктов меню. Зато второй ряд ссылок (shortcuts) можно настраивать.
Далее. Теперь функциональность модуля Content (CCK) встроена в ядро Drupal, и мы можем создавать виды контента с различными полями:
Среди типов полей есть "файл" и "изображение". Да, файлы и картинки можно из коробки присоединять к контенту. Более того, в Drupal будет встроена функциональность модуля image_cache, подготавливающего различные версии картинок для превью, ресайзов и т.д.
Изнутри нам ужасно важно то, что таксономия и поля профиля пользователя тоже теперь являются полями контента. Все это называется Field API (это главное новое API в новом релизе Drupal) и избавляет нас от одного из модулей, который приходилось ставить почти всем, а заодно и от холивара "Делать на CCK/писать руками".
Кстати, стандартные типы контента чуток изменились: теперь Story зовется более понятным Article, и по дефолту для них добавлено поле тегов. Овордпрессили, ну и замечательно. Для удобства теперь по умолчанию работают модули Path и Search.
Подготавливается автоматическое обновление модулей и ядра. Пользователя будут уведомлять о выходе новых версий по электронной почте. Cron.php нельзя запускать без ключа безопасности (а можно и вообще не запускать — новый Drupal сам запускает его на одном из запросов пользователя, если он не вызывался долгое время), а скрипты установки и обновления, напротив, стали работать из командной строки.
В простыне прав доступа появились пояснения! Уря!
Появился новый раздел с региональными настройками:
Изменения заметны и в интерфейсе самого сайта: например, для всех редактируемых элементов — блоков, меню и контента — появились соответствующие ссылки. Удобно.
Кстати, и сам интерфейс редактирования блока стал намного лучше — во-первых, логичнее, во-вторых, наконец из него можно вытащить блок в нужный регион:
Наконец, одной из самых приятных новостей стал пересмотр огромной формы добавления-редактирования контента. Вот уж и вправду своевременно:
Что убрали: старые темы, настройку темы под каждого юзера отдельно, ограничение по минимальной длине заголовка контента, выбор "включать ли красивые урлы" (спрашиваете!).
Внутри Drupal прошло значительно изменение API доступа к БД (раньше программистам приходилось регэкспами! корректировать запросы других модулей). Стало намного прозрачнее и правильнее. Однако, по производительности улучшений значимых нет. Желающие использовать Drupal для высоконагруженных проектов (а их, к слову, в последнее время всё больше) все еще вынуждены добавлять свои приемчики кеширования и снижения нагрузки. Однако, работа в этом направлении ведется: помимо возможности использовать другие движки СУБД и гибче масштабировать MySQL благодаря новому API, большая работа ведется по интеграции внешних поисковых индексаторов (модуль Apache Solr, как и многие другие, будет готов ко дню релиза Drupal 7), а необходимый многим модуль Views в следующей инкарнации будет иметь расширенное кеширование и поддержку различных источников данных — можно будет доставать данные непосредственно из того же Solr или, например, Sphinx. К сожалению, на новый Views смотреть еще рано.
Конечно, использовать новую версию как платформу для проектов пока рано, даже если цикл разработки достаточно длинный. Но присматриваться стоит начать уже сейчас.
Комментарии
Спасибо за шикарный отчет!
Круто,респект
спасибо
меня смущает что у меня уже есть тип article
не заглючит ли при апдейте
Надо будет пробовать. Апдейты вообще тяжелая тема
Эти типы вводятся в инсталляционном профиле. При обновлении они не проявятся.
Спасибо за обзор! Надо будет посмотреть...
Они к каждому релизу всё обещают и обещают производительностью заняться, да что-то как-то перекладывают постоянно это на плечи акселераторов. Что есть странно и немного глупо. Уж элементарно выбор кеширование в базе/на файлах дать можно, хотя бы...
Вопрос - кеширование алиасов путей там появилось?
а у вас есть алгоритм как это сделать?
Хотя бы в таблицу cache_alias, чтобы можно было безболезнено на файлуху сбросить. Что ни ссылка - то запрос... никуда не годится. Каждый начинает изгаляться, как хочет.
Спасибо за обзор
ЭЭЭЭЭЭЭЭ ????
а для дауна можно подробнее?
Подробнее что? Некие наметки есть тут: http://www.drupal.ru/node/19837
А на файлуху сбросить - этим занимается Cache Alter. Зачем нужно, думаю, можно и не объяснять.
Так, судя по всему - есть.
Ну, будем ковырять дальше...
http://drupal.org/node/456824
Насчет профилей автор погорячился, скорее всего profile там и не будет расширен через fields и ко всему в придачу потеряет ограничение на доступ - не успели...
Замечу, что друпал не стремится к производительности, а стремится к масштабируемости - месячная аренда сервера значительно ниже оплаты труда разработчика.
Но и по производительности сделаны приятные шаги. Заметно сокращено количество запросов к базе, добавлено кеширование для полей.
С путями(path) еле-еле справились, очень важное дополнение все еще не принято - вникаем.
Отдельно стоит обратить внимание на интернационализацию, с новым слоем базы данных она смещается к интернационализации полей, так что переводы нод скоро канут в лету. Язык интерфейса теперь независим от языка контента, наконец-то!
Коменты теперь имеют поле языка, но с интерфейсом пока итальянцы не справлись.
Спасибо за уточнения! По крайне мере, контрибы будут делать поля профиля на Fields API.
А импорт из i18n с шестерки будет? Или если на 6.x используется i18n, то нужно будет его использовать и в 7.x?
Я к чему спрашиваю - собираюсь на сайте делать интернационализацию, но не знаю, начинать сейчас или дожидаться релиза Drupal 7.
интересно, только у меня одного возникает мысль, что развитие новых версий друпала идет уж слишком быстро, и что лучше бы разработчикам сосредоточиться на производительности и гибкости, чем на создании принципиально новых версий, потребность в которых сомнительна?
вот почти создали версию 7. ну и что? кому она нужна, учитывая, что только недавно закончили латать дыры в 6 версии и адаптировать под шестерку модули?
нет, теперь снова начнется этот бардак с переделыванием модулей, с непрерывными патчами, с проблемами перехода, и т.д. и т.п.
такое впечатление, что новые версии создаются не ради реальных запросов пользователей, а просто ради самого процесса.
Тут сразу несколько оговорок. Во-первых, раз в два с половиной года — мне лично не кажется "слишком быстро". Просто была большая проблема с шестым релизом, когда основные модули сильно подзадержались, В этот раз с этим решили побороться, куча модулей будет готова к релизу.
Во-вторых, сосредоточиться на производительности и гибкости без создания новых версий невозможно.
В-третьих, я вижу множество запросов пользователей, которые удовлетворяет новая версия.
этим они и занимаются
посмотрите на кол-во модулей под 7ку http://drupal.org/project/modules?filters=drupal_core%3A103&solrsort=sis... каждый день коммитятся новые изменения.
разработчики перенесут проекты легко, а обычные смертные не делают каких-то супер-пупер сайтов которые нельзя было бы перенести руками.
Блоки-то научились кэшировать или снова модуль писать самим?
п.. не мешки ворочать
ЭЭЭЭЭЭЭ. Ну я так и думал что алгоритма нет.
можно задать совершенно логичный вопрос - ЗАЧЕМ мне нужен кеш путей если я могу таким же образом САМ используя текущее апи закешировать ВСЮ страницу?
Для зарегистрированного пользователя кешировать всю страницу нынешними средствами практически нереально. Подгружать куски, изменённые для пользователя, аяксом - это создавать неоправданные подключения и запросы. Вот и приходится бороться за каждый запрос.
Симпатичньій отчетик...
И вижу очень изменилась семерка со времени моего последнего ее инстала...
Где можно скачать новую версию движка?
такого не писал
Вы сами возвели себе ветряную мельницу, и сами с ней начали бороться.
Ваша проблема существует только для случаев когда количество изменений на странице которую кешируют больше или равно количеству просмотров.
во всех прочих случаях кеширование ВСЕЙ страницы значительно более выгодная стратегия чем ваши попытки минимизировать пачки запросов. Точнее говоря, ее можно использовать как дополнение но не как основную стратегию для борьбы за производительность.
Но и это не все. Вы зря так о о яксе. Или любой техники связанной с джаваскриптми. Конечно, она часто , очень индивидуальна, но позволяет опять же получить значительно больший прирост чем те же миллисекунды на пачках запросов.
Вот вам простой пример, имеем страницу со списком нод. В списке тайтл тизер плюс приписка о добавленных комментариях.
Очевидно, что если количество нод не изменяется, то динамика у нас только в маркере. Который легко создается двумя командами используя jQuery и переданный массив маркеров.
Ну и так далее.
Как у вас всё просто
если на странице динамики хоть немного больше, чем маркеры, то эта прелесть оборачивается ночным кошмаром (флаги, маркеры, блок с новым контентом (для каждого пользователя - свой)). Теперь получается: коннект на забор страницы из кеша, коннект на маркеры, коннект на флаги, коннект на каждый индивидуальный блок. Всё это сопровождается созданием процесса сервера, тоннами подключений к серверу БД и т.д. Естественно я буду стараться минимизировать число запросов и вообще пытаться объединять некоторые вещи.
Что-то мне затея с админкой не очень нравится... Аля битрикс...
1) cck вроде и раньше можно было поставить?
2) над таксономией тоже можно было извращаться и в прежних версиях
3) админку так же можно было переделывать под свой вкус.
в общем, пока ничего принципиально нового я не вижу.
больше того, непонятно, что с таким монстроподобный друпалом версии 7 теперь делать, учитывая, что большинству сайтов не нужны настраиваемые поля в типах, а так же большинство примочек, которые там есть.
серьезное новшество!
LOL
Эх, дождешься! Лично у меня уже терпение на исходе. Умник, бл..ь, нашелся.Только и делаешь, что всем тыкаешь. Не хочешь на другой сайт отправиться и поучать других, а?
Спасибо за статейку, будет время поглядим на семерку.
Mojo, зря лолите - новшества есть. Лично для меня проблема локализации других языков это одна из самых больших, если она будет решена на семерке в коробке, то новые сайты будут делаться исключительно на ней.
penexeЧто же касается "легкости" переезда с 6 на 7 (да хоть с 5 на 6), это вообще глупость сморозили.
По поводу новых тем - автор забыл сказать про stark! Это голая тема, которая создана для отлова багов в css контриба и как шаблон для изучения внутренних css стилей ядра.
PS: забавный флейм вышел... вместо того, чтобы помочь в разработке хотя бы ревью готовых патчей - сыплется критика...
Назвревает вопрос: что ТЫ сделал, чтобы drupal стал лучше?
Первый тоже - /admin/structure/menu-customize/management. Тема меню не раскрыта.
Уже встроена - /admin/config/media/image-styles
hook_db_rewrite_sql программистам не помогал?
Жаль. Хотя может и к лучшему - content_profile станет лучше
Это у "них". У "нас" - друпал пытаются ставить на джино-хостинг и обходиться без программистов
когда на сайте больше 20к уников, вариантов тарифных планов у хостеров не так уж и много
Чай не Амазоновское облако
у нас сплошные кудесники
пора бы и свой сервер купить
ну пока будем заниматься оптимизаций
а то даже мемкэша нема
(я к тому, что все равно приходится выходить за рамки "включить сжатие CSS")
Думаю ещё стоит упомянуть возможность установить роль администратора (/admin/config/people/accounts) - для пользователей с этой ролью автоматически устанавливаются разрешения вновь включаемых модулей. Вещь незаменимая для коллективной разработки: спец-пользователи могут спокойно включать/выключать модули, но не иметь возможности, например, устанавливать права. К тому же теперь незачем всем открывать пароль юзера №1 - достаточно включить в эту роль. Эдакий псевдо-sudo аналог.
Также появился спец регион "Help", в котором будет размещаться контекстная справка системы - мелочь, а приятно.
Ну и забыли в обзоре упомянуть про выбор профиля инсталяции - теперь их два - стандартный и минимальный, при котором включены только обязательный модули - сокращает установку друпала на полминуты
Благодарствую за обзор.
А что слышно про файловые обёртки? (s3://, etc)
2kyky: в ядре.
Пора наверное уже переводить начинать
Процесс идет. Можно присоединиться - быстрее пойдет.
Чего?
Очередная весть с фронта - profile останется в том виде, в котором он есть сейчас, смотрим 63й комент...
А день так хорошо начался...
Жаль конечно, что с профилем не будет изменений, задумка была хорошая..
Презенташка...
ошибка водяных знаков
Небольшие изменения по сравнению с предыдущей сборкой.
Вроде Highslide элемента к изображению когда кликают по нему для увеличения.
Path: /seven/file/ajax/field_image/zxx/0/form-6cbd961998d792e81363ed87318d5e65". Ни чего не показывает, но
изображение исправно загружает и в конечном итоге все нормально показывает. Не понятно одно где взя Ajax, куда прикручивать, и нужен он вообще по умолчанию.
Решили сделать загрузку изображений через Ajax или он тут совсем не причем?
В предыдущей версии этого не было и скорее всего этого не избежать в финальном релизе,
главное чтобы все оптимизировали. Насчет блока настройки то же выпадает меню - понравилось.
Очередное интересное изменений - тема minelli выброшена из ядра, вместо неё garland научился быть фиксированной ширины!
Итого в ядре осталось 3 темы
ничего не слышно про дату релиза?
Еще одно весьма жесткое изменение, несмотря api-freeze довольно обширное переименование функций...
http://drupal.org/cvs?commit=304916
Спасибо за обзор
Вопрос по теме: может кто-то спрогнозировать минимальные требования к платформе при базовой комплектации с учетом 100 активных посетителей в час?
Официально требования перечислены тут -- http://drupal.org/requirements
Неофициально покажет время.
Я видел, вчера установливал. Радует оперативность
Спасибо.
Что, понравилась?
Никто не запрещает. Посмотри ещё rubik и cube (подтема rubik).
купил висту лицензионную???
Спасибо огромное!
Семерка стоит сразу, как только умельцы портировали русский язык с висты. Потом ставил RC1, всем доволен, никаких проблем. Хотя вру, одна есть ... с драйверами starforce косяк, но это все пройдет
7-ка стоит, нравится
p.s. еще один топик ушедший в оффтоп
Покупка винды - это звоночек. Пора бросать пить ))))
я бы даже купил 7-ку, баксов за 100
Ну да, только проф версия за 100 не продается, увы
так... 60% так и осталось?
Не потом поздно будет
2 года юзали на халяву, а сроки уже к концу подходят 
Жалко конечно, хоть оно и не надо там всякие обновления, но чёрт подери, приятно, когда не надо дрова искать по всему нету... Тыц на пимпу и всё стоит ровно. Даж не представляю как потом на хрюшу возвращаться ... Жду крека xD
не понял, зачем возвращаться на хрюшу. Речь о 7-ке? так давно уже есть анальгин
Аналигин-то есть, только он лишит некоторых полезных вещей вместе подаренной халявой.
а каких?? если не секрет
Господа, не отвлекайтесь от темы, пожалуйста.
Valeratal, подобные вопросы можно задать приватным сообщением.
К тому же разговор о кряках и иже с ними на сайте не приветствуется.
Dan, исправимся, не ругайтесь пожалуйста
Для меня новость то что Семерка пока что еще альфа версия. Я уже думал бетка.
Хотя за темой не слежу, поэтому и незнал.
А вообще года два можно честно о семерке не думать и юзать шестерку.
имхо конечно.
То есть к выходу 8-ки?
ну я думаю к релизу семерки)
а если восьмерка и будет, то только пре альфа какаято.
вон сколько семерку делают, не думаю что восмерку сделают за пол года.
7-ку делают два года. К лету на ней можно будет вполне делать сайты. Чисто технически. Практически программисты освоятся с полями, новой темизацией и начнут давать адекватные рекомендации на этом сайте к концу году.
хм.
как бы сказать правильней.
Вот именно, семерку делают два года.Но, до сих пор еще не известно когда будет бета тест. А до этого, врядли какой серьезный человек будет юзать не провереную вещь. Даже если это друпал.
Да и не надо забывать, шестерка уже два года как зарелизилась, а многие до сих пор юзают пятерку.
Многих модулей досих пор не портировали.
В общем как минимум два года еще можно юзать шестерку, а потом уже потихоньку перелазить на семерку.
я лично так и сделаю.
Читайте блог дриса про акивию, очень скоро (недели) публичная бэта появится и до конца года будет бесплатной... вмодификации от аквии
1. Ну дык чтобы сайт на версию поднять, надо напречься. А зачем, когда и так работает?
2. И не будут портрированы никогда, ибо они или заброшены или не нужны в 6-ке или написаны модули получше.
http://drupal.org/project/usage/drupal - тысяча несерьёзных на альфе уже есть
О боже.
я говорю про то что шестерку можно юзать еще года два спокойно.
а не о том что семерка гавно.
Тогда надо определиться что значит "юзать". Я под этим словом подразумеваю "делать новые сайты".
имено делать новые сайты.
интересно, когда вьюс будет под 7-ку
Релиз? "Когда будет готово". А потестить и сейчас мона, cvs или http://drupal.org/node/608852
спасибо
ожидал что решат проблему с производительностью и кешированием (хотя бы запросов), проблемы с интеграцией некоторых дж криптов на базе ui..
мда..
по апи тоже ничего нового и военного.
архитектура обработки семантики ядром та же?
портация модулей = побочные баги + время на патчи, которые еще ++ время на интеграцию в релизы модулей.
посмотрим.
вообще, а юзабили где?
(лол, вы действительно думаете, что хороший мастерхост будет обходиться дешемле толкового прогера? мда... )
P.s.интересно, а кто нибудь риски оценивал? я понимаю что опен сорц, но проекты весьма реальны, и риски тоже. Как с стабильностью? Как ведет себя при 10 к трафика в день (не уников)? Как вебет себя при включении 10 и более модулей и портации из внешних источников инфы (файлы, обращения к рсс/парс данных), не падает, как с оптимизацией обработки массивов хранения данных? как по работе с сессиями, улучшения есть?
Ибо перечисленные нововедения... наверно я тупой, что не понимаю, как же это здорово, что они появились
Посмотрим в общем. А пока будем сидеть на 6ке дальше и ждать новостей с фронта. И тестить тестить тестить..
10 к трафика в день (не уников) это много? Вообще проблемы больше от зарегенных, чем от гостей (на гостей натравливается нжинс)
p.s. Полагаю в буржунете проект с 10к трафиком может позволить себе сидеть на собственном сервере (и проводить оптимизации этого сервера) - там и хостинг дешевле и денег больше у пользователей и у рекламадателей (ну или какая там модель монетизации)
2t1mm1: охота потролить?
Изменения весьма существенны, Ваши вопросы говорят о том,что Вы "не в теме".
причем тут троллинг?
релиз подразумевает существенные, прежде всего, улучшения, и исправления багов.
как по мне лучше было бы оптимайзить 6ку.
дело не в том, в теме я или нет, и уж тем более мне как прогеру интресны изменения. Вот я о них и спрашивал.
семантика -- правила истолкования сообщений тем, кому они адресованы. короче говоря, логика синтаксиса в нутри определенной иерархии или в данном случае архитектуры. относительно друпала - один из примеров - построение названий исполняющих функций, или вызов определенных хуков относительно пути.
А мне интересно чего товарищ t1mm1 так придрался к семантике и что он под этим словом подразумевает, за прошедшие сутки я это слово от него прочитал как минимум три раза
придрался потому, что это больная тема при программировании или построении архитектуры модулей, особенно когда проект пишут не один человек (именно пишут, используя за основы уже готовые модули). И мне было просто интересно - как дела с интеграцией трех К основ ООП в самой основе? (да да, на пхп есть реализация ооп, например, продукт xCore)
лан, забили/проехали
Откуда такое масло-маслянное определение? Синтексис - это уже "определённая иерархия". Логики у синтаксиса быть не может, т.к. синтаксис - это основа, набор правил-аксиом языка или ещё чего-нить. Синтаксис может быть неудобным или избыточным или просто непонятным, но нелогичным - вряд ли.
Как это? Какого пути?
Больная тема - это совместная работа с БД, так как изменения в ней отслеживать сложно. А программирование модулей хоть всем табором - не проблема, cvs,svn,..., тестовый сервер - и вперёд.
Энди писал, специально для программистов: http://prodrupal.ru/ru/node/58
А насчёт багов - это про что? Баги для 6-ки исправляются в шестой ветке. У 7-ки - новая архитектура, новые баги
http://prodrupal.ru/ru/node/58
спасибо за ссылку, кое что понятно стало
по поводу семантики. это правила. синтаксис больше относится к удобству выполнения логики и этих самых правил. и синтаксис к семантической языковой модели не имеет никакого отношения. потому как не важно на чем ваять в итоге - сишник, шарп, ява или что-то еще. Логика и удобство - решающий фактов. Я же спрашивал о изменениях логики работы в ядре, да и в целом по апи работы с базой, клиентами, логики обработки данных с базы и т.д.
в приведенной ссылке написанно, что изменения коснулись прежде всего с учетом приоритетов пожеланий пользователей и программистов. хз. может быть для пользователей, не связанных с приспособленностью в вебе аякса (хотя бы этой части) и как вы заметили - проблема работы с двумя и более базами (хотя в реале я лично с такими проектами не сталкивался, обычно дополнительный модуль и отдельный коннект, не связанный с обработкой данных через ядро друпала - спасал не раз) - данные изменения и есть хорошо.
Понимаете. 7я версия как я понял - есть продолжение основ и начатого (как и любая другая версия во всей линейке уже девять лет) - и есть улучшения.
Но опять же.
Лично я ождал, что решиться на уровне ядра проблема с кешированием, решиться проблема с удобством коддинга и приведением внутренней стандартизации к общим стандартам ООП, а не оставаясь на нечто среднем, что бы можно было править не только модули, а при и необходимости - ядро, что бы был наконец-то выработан единый стандарт написания кода внутри обработчиков.. То есть, меня прежде всего интересовали изменения в производительности, а не в UI.
Порадовало, что наконец-то появился разговор о сущностях, а не основах - узлах. Это радует.
Да и в целом - относительно крона, тестирования (кстати, тут действительно +100 - нужный момент) - это плюсы.
"...система готова, изменения в архитектуре и API производиться не будут, фактически сейчас ..."(с)Конец цитаты.
но честно говоря..когда в каментах говорят, что в ооп нет удобства.. эм... как бы странно звучит это.0_0
поставлю сегодня. посмотрим. интересно узнать о стабильносте работы при большой нагрузке трафа..
P.s.я ни в коем случае не критикую. Любая работа хороша над проектами в любых проявлениях, видно что проект живет, особенно включая во внимание награды за 2009 год. просто было интересно как программисту, какие нововведения были, оправданны ли они за счет изменений, и каких подводных камней стоит ожидать теперь. Троллингом я занимаюсь на других ресурсах
Спасибо за ответы.
1. ООП и семантика. Я так понимаю, Вас не устраивает система хуков и Вы предпочитаете ООП. Да, объекты часто удобны, но они далеко не панацея и совсем не универсальное средство програмирования, ииначе другие направления, типа функционального программирования умерли бы за ненадобностью. Дабы не казатьсятеоретиком, могу добавить, что у меня восьмилетиний опыт объектного программирования на С++, но АПИ друпала мне очень даже по душе и считаю его более о коротким и эффективным по сравнению с ООП. Кроме того, ООП в окружении друпала используются, если эта тема Вам близка - пользуйтесь и пишите мануалы для новичков о том как писать модули для views, паналей и т.д. - это востребовано.
2.БД. Я имел ввиду не работу с двумя БД, а коллективную работу с одной БД - синхронизация и откаты правок.
3. Как раз нет. Это переходная версия к новому. В 8-ке возможно откажутся от узлов (node), которые в 7-ке оставили для совместимости, то есть логические сущности в системе сменились крренным образом, хотя пока это внешне и незаметно. Это 6-ка была "продолжением основ" 5-ки.
4. Производительность. Могу гарантировать, что каждая следующая версия системы будет медленнее предыдущей. Меня это не сильно беспокоит, скорее для меня важно чтобы можно было гибко управлять кэшированием, и вроде в 7-ке с этим лучше, чем в 6-ке. Пока я не в теме.
спасибо за подробное толкование
впрочем, уже пролистал и на офф сайте что и к чему. улучшения есть.
да, переход к сущностям (и отход от узлов) есть плюс...
пысы. наверно я так за три года и не привык к методам хуков... все тянет к ооп. но друпал - по крайней мере 6ка - это то что долго искал до этого по удобству настройки, и гибкости. это самое важное. да и немалое комюнити в сапорте есть огромный плюс.
по поводу 7ки растолковали что к чему. просто я думал иначе - что есть улучшение 6ки. а оно вот как оказалось.
Как мне надоели дискусы по ООП... все расписано http://drupal.org/node/547518
Еще была попытка http://drupal.org/project/handler (подробнее http://www.garfieldtech.com/blog/drupal-handler-rfc)
Но практика показывает, что проще иметь 20-40 api функций, чем 20 классов со своими методами и свойствами.
Дан грамотно подметил - люители ООП могут кодить под ctools, views, panels
Но сравните количество полезных модулей, которые написаны без ООП и сним
Предлагаю закрыть эту тему (ООП).
По поводу javascript: все чего нехватало 6ке - это подключения внешних JS файлов на уровне api уже реализовано, также расширены методы formAPI для ajax операций. Остальное на совести разработчиков и только потребности реально покажут, что востребовано, а что нет.
О семантике, на сегодня подавляющее большинство php программеров не пользуются namespaces и при соблюдении http://drupal.org/code-standarts почему-то у всех разработчиков модулей не возникает проблем с именованием...
Системы кеширивания - зачем в коробке тащить что-либо кроме кеширования в базе? Много ли хостингов с memcache или доступом к функциям кеширования в apc, не говоря уже о более экзотичных продуктах?
Соответственно, если есть возможность ставить кеширующие сервера-сервисы, то нет никаких проблем доставить и настроить под них нужный модуль, причем с учетом конкретной задачи ибо здесь не может быть универсальных решений.
Для интрересующихся есть http://drupal.org/project/entitycache а также наконец началась работа над портированием http://drupal.org/project/cacherouter
По поводу сущностей - сначала они будут обкатываться в контрибе http://drupal.org/project/entity
Пользуйтесь гуглом, все поднятые вопросы обсуждались и за 2 года работы над 7кой именно Developer Experience в большинстве своем был учтен, юзабельность и интересы контриба также были учтены, но в значительно менбшей степени... почему? наверно большинство это устраивает... http://www.d7ux.org/ было достаточно времени высказать свои предложения и обсудить их.
дискутов нет *)
как и холивара на предмет что лучше а что нет
я думаю что время покажет степерь удобства реализации тех или иных методов.
но пока что остаемся на 6ке
как то привычнее, и.. безопаснее (обкатаннее с собственными наборами модулей, их изменениями и тд)
спасибо за ссылки. будем читать и вникать более существенно.
ясно, спасибо за разъяснения - то есть излишние усложнения, которые к тому-же необходимы только поскольку-постольку ради перехода на 8-ю версию и к тому-же тормозящие систему,
похоже то что было нужно в друпале "из коробки" - views cck fckeditor и т.д. - этого так и нет, за то теперь есть непонятные сложности вроде очередей под pgsql и начатки чего-то под грандиозные проекты... того и глядишь - в 8-ке перелопатят весь код, напишут кучу прослоек для коннекта с базами, поменяют весь api - и все ради совместимости с какой-нибудь версией Oracle
- в древнем PostNuke 6-ти летней давности был почти мегабайт кода для коннекта с базой который написан в друпале в нескольких строках, не хотелось бы возвращения монстров
в общем пока я так и не увидел существенных улучшений по сравнению с 5-м друпалом, а если модулей под 6-й останется больше - то существует риск разделения друпала на простой 6-й и сложный для больших (непонятно каких) проектов - 7-й
cck, вроде, есть.
Views 3 тоже будет лишь под 7ку, как я понимаю. И вот именно в нём обещают улучшение производительности в связи с каким-то там кешированием.
WYSIWYG — вообще не уверен, что должно быть в ядре…
А может кто-нибудь рассказать концепцию Entity API? Если не сложно, конечно. И чем она так отличается от концепции Node.
Правильно ли я понимаю, что Node + CCK ≈ Entity + Bundle?
Однако тоже любопытно.
WYSIWYG я бы поставил в ядро, хоть буедитор
А то пока въедешь куда, в какую папку запихнуть собственно редактор..
а кому не надо, могут отключить/поставить другой
Там же всё ОЧЕНЬ подробно написано...
А для bueditor ничего и пихать не надо.
То, что надо пихать - это то, что нельзя распространять вместе с модулем. Но тогда и с Drupal это распространять нельзя будет.
я не говорю что не подробно, я говорю что ставить неудобно
для других CMS как то есть в готовом виде
Спорно. На д.орг только GPL, а компоненты могут быть ещё по целой куче лицензий.
ССК в ядре. Views в ядре не нужен - он сам по себе хорошо живёт, а выпуск ядра оттягивал бы нехило. fckeditor - на нём что, свет клином сошёлся? Вот не понимаю я этой проблемы - отсутствие кучи модулей в ядре. kiev, ты сколько сайтов в день делаешь, что потратить несколько минут на установку модуля - это проблема? Воспользуйся drush, кстати, время сократиться ещё сильнее. Насчёт WYSIWYG в принципе поддерживаю, но он ещё сырой, рано для ядра.
Я имел ввиду, что и Drupal, и модули (по крайней мере, те которые удобно ставить — на друпал.орг) имеют одну и ту же лицензию GPL. Именно поэтому CKEditor не входит в состав CKEditor">http://drupal.org/project/ckeditor]CKEditor[/module]
дампер? и gzip на хостинге
Да, если не вдаваться в подробности.
Под семёрку уже есть русификация?
Предлагаю начать обсуждать перевод, много строк перехало из 6ки, но появились новые модули и терминология
http://drupal.ru/node/43162 и непосредственно http://drupaler.ru/node/5507
Ну зачем же закрывать, в Д7 ее как раз только открывают, новый DB API к примеру. Правда он все еще примитивный, но это уже что то. Ведь основное преимущество, которое даёт ООП по сравнению с процедурным программированием - возможность выводить обобщенные алгоритмы для самых разных предметных областей. Полиморфизма как раз в новом DB API мало ощущается, почему то не желают программисты мыслить в ООП дальше обьекта с методами и свойствами. И что прикольно, в случае с Node архитектурой Друпала имеем как раз тот самый полиморфизм, только реализованный процедурными средствами.
Поклонникам ООП посвящается:
Architectural Plan
Architecture: round 2
группа http://groups.drupal.org/butler
Views UX workflows and ideas
Ну это скорее нормализация существующих идей. Хотя должен сказать что механизм хуков в сочетании с контент тайпами вполне полиморфный. Я же говорю про саму инфраструктуру хранилища, такой себе узкий аспект. Наконец то пришло понимание того что инлайн SQL должен уйти из модулей, в Д7 попытались вывести обобщенный уровень запросов данных, получилось вполне гибко хотя иногда все таки без плейсхолдеров не обошлось, операторы передаются в строке, но даже при существующей абстракции вполне реально выводить конечные запросы под разные диалекты SQL. Я же предлагаю взглянуть на эту инфраструктуру шире, в одном случае мы можем попросить данные у MySQL:
<?php$query = db_select('users', 'u'); $query
->condition('u.uid', 0, '<>')
->fields('u', array('uid', 'name', 'status', 'created', 'access'))
->range(0, 50); $result = $query->execute();?>
А в другом случае это может быть поиск в xml:
<?php$query = xml_select('users', 'u'); //ini_select(), fs_select(), whatever_select() $query
->condition('u.uid', 0, '<>')
->fields('u', array('uid', 'name', 'status', 'created', 'access'))
->range(0, 50); $result = $query->execute();?>
Либо будет написан db провайдер который поставляет данные из облака Амазон, хмл провайдер будет поставлять данные из Гугль Докс, дописан провайдер для Веб Сервис дата абстракшн леер, и так далее и тому подобное. Оторвать нужно друпал от конкретного хранилища. Сюда же аггрегировать стратегии кеширования:
<?php$query = local_cache_select(db_select('users', 'u'));
$query
->condition('u.uid', 0, '<>')
->fields('u', array('uid', 'name', 'status', 'created', 'access'))
->range(0, 50);?>
где local_cache_select будет возвращать некий обьект который в себе будет аггрегировать абстрактный тип селекта (ДБ, ХМЛ), с точно таким же интерфейсом, но со стратегией статик кеширования:
<?php
class LocalCacheSelect{
public $inner_select;
protected static $local_cache = array();
public function condition(...){
... prepare data for local_cache request ...
//delegate condition to the inner select
$this->condition(...);
//bla bla
}
public function execute(){
$data = $this->executeLocal();
if(!$data)
return $this->preserve_data($this->inner_select->execute());
return $data;
}
};
?>
Или этот static $local_cache будет в обьекте RecordSet который возвращается из execute. Тоже самое можно применить для
memcache, apc, etc, причем кеши могут нахлобучиваться друг на друга:
<?php$query = mem_cache_select(local_cache_select(db_select('users', 'u')), mem_cashe_config);?>Каждая запись, которая возвращается из RecordSet будет иметь методы для апдейта:
<?php$result = $query->execute();
foreach($result as $record){
$record->name = "Vasya";
$record->update(); //make storage request for update data
}
?>
Точно такой же метод может быть и у RecordSet, для построения пакетного запроса апдейт для всего сета записей:
<?php$result = $query->execute();
foreach($result as $record){
$record->name = "Vasya";
}
$result->update();
?>
И все это в сочетании с абстракцией типа данных. Идей и приёмов на самом деле куча, задача всего этого мероприятия - избавить программиста от всех подробностей хранения, передачи, кеширования (каждый раз изобретается велосипед со статиками и ресетами), возможно все эти запросы можно закомитить в параметризируемые хранимые процедуры (там где сервер поддерживает хранимые процедуры), и т.д. и т.п.
bratello Все правильно! Рекомендую посмотреть как реализованы MongoDB MemCache как раз реализуется перегрузка класса кеша.
Еще важно заметить что с таким унифицированным подходом к запросом очень приятно делать всевозможные _alter() операции в зависимости от тегов addTag(), которыми помечены запросы.
Например теперь стал возможным динамический перевод данных, для этого а опредении поля в hook_schema() добавляется 'translatable' =>TRUE и в запрос тег, например http://api.drupal.org/api/function/contact_category_list/7