Самый отвратительный фреймворк/цмс, или чего в готовых решениях быть не должно?

cms != framework

Мне сойдут оба представителя, да и грани между ними порой стираются

http://omploader.org/vM250cg/matrix.html - еще списочек цмс, только в другом виде

Чудовищная сложность фреймворка, которая не помещается в мозг собственных разработчиков и очень сложно контролируется. Не будем тыкать пальцами, но был такой веб-фреймворк под Java, который на определенном этапе своей жизни потребовал собственную пакетную систему сборки. Причем система сборки оказалась в результате такой сложной и навороченной, что отделилась в отдельный проект, и сейчас много где используется. (От того что она много где используется, она не стала менее тяжелой и монструозной, у некоторых людей от общения с ней мозг вытекает через уши и портит воротничок новенькой рубашки).

дай угадаю, вы не про OSGI случайно?

А что же тогда система должна уметь? Если придерживаться KISS-принципа по максимуму, то от системы останется только пагинатор и 2 десятка страниц роадмапа, как правильно писать код, больше там ничего не будет. А как только юзерская база станет больше (сразу, откуда она у системы, которая ничего не умеет?), так сразу и репозитарии с пакетными системами нужны будут, куда от этого уйти? Разве что только в сторону сборок CoolCMS_by_Vasia_InCLuDeD_ALL_UlTIMatE_Editi0N

битрикс. Все возможные недостатки в нём есть

Joomla же

>А вот чего быть НЕ должно, какие самые отвратительные моменты есть в имеющихся фреймворках, что можно выставлять за пример отвратительнейшего быдлокода?

Фреймворк должен быть модульный, с продуманной внутренней идеологией, предельной инкапсуляцией компонентов, расширяем, работать по принципу IBM «машина должна работать, человек - думать». Не должен иметь сайд-эффектов, размазанного функционала, платформенных проблем, жёстких ограничений в структурах и т.д.

http://www.ohloh.net/p/drupal/analyses/latest 122,308 строк чистого PHP

http://www.ohloh.net/p/joomla/analyses/latest 499,455 строк чистого PHP

http://www.ohloh.net/p/wordpress/analyses/latest 87,701 строк чистого PHP

Доля коментов примерно одинакова.

Перед основательным погружением в ту или иную CMS полезно представлять общую глубину.

>http://www.ohloh.net/p/joomla/analyses/latest 499,455 строк чистого PHP

$ find /var/www/bors/bors-core -iname '*.php'|xargs cat|wc -l
32405

Чёрт. Мне стыдно. И я ещё считаю, что это сильно жирно и уже второй год собираюсь разносить ядро и расширения :)

А вот самый жирный проект на нём, www.aviaport.ru:

$ find /var/www/bors/bors-aviaport/ -iname '*.php'|xargs cat|wc -l
22757

Блек-Джек^W новости, дайджесты, форумы, рассылки, вакансии/резюме, куплю/продам, события, архивы, фотогалереи, справочники по предприятиям, технике, изданиям, аэропортам, сотни тысяч разнородных связей между сотнями тысяч объектов сотни видов...

...

Страшно представить, что можно бы было написать в 500 тыс. строк. Наверное, систему для Императора Мира :)

Зато в Joomla можно втыкать прямо на ходу. Хотя самописная конечно лучше. Хотя я не теряю надежду распарсить-таки все полтора лимона джумловских строк чтобы обстругать под свои нужды.

Я к тому что она адово модульная и можно смело перекраивать одну часть, даже не втыкая, как работает другая.

Так у меня тоже так. Более того, я, как раз, не понимаю, как модульная система может быть большой :) Большими обычно выходят немодульные, размазанные системы с огромным дублированием кода.

> Фреймворк должен быть модульный

Дык я спрашивал наоборот, чем он НЕ должен быть!

с продуманной внутренней идеологией, предельной инкапсуляцией компонентов

Дык и получаем в результате пагинатор + роадмап на 2-десятка-сотен страниц + пользовательских набор плагинов, не? А кто это будет использовать?

Не должен иметь сайд-эффектов, размазанного функционала

Иногда задача сводится как раз к получению сайд-эффектов, дабы имея куцое апи (где ничего лишнего) достигнуть своих целей, как быть в этом случае?

платформенных проблем, жёстких ограничений в структурах и т.д.

Например, если есть жесткая завязка на апач - это платформенная проблема? Ведь всегда трафик можно проксировать через. Жесткие ограничения: как быть, если у меня логи пишутся в стандарте вида «дата - модуль - сообщение», а автору приспичило еще и «важность» впихнуть? Допустить изменение структуры и тем самым сломать апи, а вместе с ним еще 100500 плагинов?

> Страшно представить, что можно бы было написать в 500 тыс. строк. Наверное, систему для Императора Мира :)

Скорее велосипеды, дабы не зависить от имеющихся модулей (соблюдать инкапсуляцию) и апи, ломая его по своему усмотрению внутри себя.

>Дык я спрашивал наоборот, чем он НЕ должен быть!

Ну так подразумевается, что он НЕ должен соответствовать тому, что написано в начале :)

не?

Не :) Я нигде не вводил ограничение на количество и возможности компонентов :)

Иногда задача сводится как раз к получению сайд-эффектов, дабы имея куцое апи (где ничего лишнего) достигнуть своих целей, как быть в этом случае?

Вот нормальный фреймворк и должен иметь такой API, чтобы при его простоте не возникало такой потребности. Соответственно, переформулируя в определение «отвратительного фреймворка» получаем, что это такой, который требует от программиста сайд-эффектов.

Например, если есть жесткая завязка на апач - это платформенная проблема?

Безусловно.

Жесткие ограничения: как быть, если у меня логи пишутся в стандарте вида «дата - модуль - сообщение»

Отвратительный фреймворк - это такой, где всё прибито гвоздями. В хорошем, если нужно добавить «важность», то это должно решаться считанными строками кода. При чём, естественно, подразумевается, что без ковыряния исходного варианта, только на уровне штатного расширения.

> Безусловно.

А товарищ Сысоев уже в курсе, что пишет костыль для решений с платформенными проблемами?

При чём, естественно, подразумевается, что без ковыряния исходного варианта, только на уровне штатного расширения.

Ну вот и получаем 500 000 строк кода, когда штатные «плагины с гвоздями» не используются, а дописываются свои собственные расширения, используемые только в модулях одного автора.

>А товарищ Сысоев уже в курсе, что пишет костыль для решений с платформенными проблемами?

А он тут каким боком? Linux более мультиплатформенна, чем Windows. И это хорошо. И это, естественно, не делает костылями x86 железо. В общем, в Киеве - дядько.

Ну вот и получаем 500 000 строк кода, когда штатные «плагины с гвоздями» не используются, а дописываются свои собственные расширения

Нет. Опять не катит. Расширить нормальную структуру - это единицы. В худшем случае - десятки строк на компонент. Так что там, десятки тысяч компонентов? :D

> Расширить нормальную структуру - это единицы. В худшем случае - десятки строк на компонент.

Ну пример я привел, покажи пример, как без ломания апи что-то можно изменить

Так что там, десятки тысяч компонентов? :D

Если каждый автор запилит свою логилку... Ой, там и больше будет

Ну пример я привел, покажи пример, как без ломания апи что-то можно изменить

Я не видел чётко сформулированного пожелания. Только «хочу, чтобы было пи$%ато». Опиши задачу конкретнее, покажу, как я решаю такие.

Если каждый автор запилит свою логилку... Ой, там и больше будет

Тысячи авторов одного продукта? Не кури столько больше или меняй дилера :)

Спасибо, почитал википедию. Оказывается, framework - «скелет» будущего сайта, который можно «обвешать» содержимым. CMS - «редактор для идиотов» - программка, помогающая бездарям «создавать» сайты.

А я-то думал, что это одно и то же...

> Опиши задачу конкретнее, покажу, как я решаю такие.

Окок, распишу помедленней:

Нужно как-то писать логи, автор фреймворка (предположим меня) написал плагин TheLogger, который сохраняет текст от всех других плагинов, возможно индексирует, архивирует, предоставляет доступ для плагинов с обработчиками статистики, короче занимается всей работой, которая связана с ведением логов. И программисту не нужно думать про складывание файлов, и у пользователя все в одном месте, да еще статистику запустить можно.

Изначальное API на запись просто как 3 копейки: это logger.save(«plugin_name_state»,«error while open $!»);, таким образом все остальные плагины (как от автора, так и от стороннего разработчика) размазывают по себе зависимости от этого плагина.

И тут появляется программист, желающий расширить API, до скажем logger.save(«plugin_name_state»,«error while open $!»,Logger.HIGH_PRIORITY);, указывая еще и приоритет, ибо он для него ну жизненно необходим.

Вижу варианты:

1. пропатчить оригинальный logger, добавить пару строчек по обработке приоритета, при этом сломав совместимость с остальными плагинами, получив классический dll hell. И если свои собственные модули можно исправить самому, то мейнтейнеров других плагинов будешь долго искать.

2. написать свой логгер, по принципу «все свое ношу с собой»

2.1. Не просто написать свой, но и выбрасывать в системный лог записи в старом формате

3. Прикрутить систему версионирования плагинов (заменить dll hell на version hell)

Придумываются и другие возможные костыли, но про них лучше не писать.

Особенно интересно будет, когда появился еще один программист, желающий ЕЩЕ расширить это апи.

покажу, как я решаю такие.

Очень жду.

Тысячи авторов одного продукта? Не кури столько больше или меняй дилера :)

Тысячи (хорошо, сотни) авторов плагинов, работающие над мелкими дополнениями в течении 10 лет для своих нужд, отправляющие свои плагины в репозитарий, а в следствии составляющие один продукт. При этом порой конфликтующие между собой.

> А я-то думал, что это одно и то же...

Редактор для идиотов порой позволяет писать нативный код, превращаясь в фреймворк, а фреймворк порой содержит генераторы кода для типичных случаев, где мышкой можно получить нужный функционал, превращая фреймворк в цмс. Грань тонкая.

И тут появляется программист, желающий расширить API

Ты так как следует и не сформировал задачу, описав её без ряда важных уточнений. Так что предлагаю такой только вариант:

class project_xxx_logger extends base_logger
{
    function table_fields()
    {
        return array_merge(parent::table_fields(), array('priority'));
    }

    static function save($state,$message,$priority)
    {
        return object_new_instance('project_xxx_logger', array(
            'state' => $state,
            'message' => $message,
            'priority' => $priority,
        ));
    }
}

Где-то так. Обратная совместимость - наличествует.

Тысячи (хорошо, сотни) авторов плагинов

И чё? Все плагины сторонних авторов должны включаться в продукт? :D

Всё же, ты гонишь. Или троллишь.

> Ты так как следует и не сформировал задачу, описав её без ряда важных уточнений

Хорошо, задай мне те вопросы/нюансы, которые я пропустил

Обратная совместимость - наличествует.

Ну почти как я и предполагал по 2.1, только отдельное поле завел. Заметь, в базовом плагине, который еще в апстрим воткнуть надо (случаи, когда это поле может занять кто-то еще, но в другом формате приоритеты кидать, не берем)

И чё? Все плагины сторонних авторов должны включаться в продукт?

Конечно нет, но разве ты никогда не видел сборок вордпресса или еще чего-то подобного Included_700_plugins_by_C0oL_Vasya?

Да тут если идти по пути юникс-вея, т.е. делая плагины «только с 1 функцией, но хорошей», то на примитивный блог уйдет 2-3 десятка плагинов, а когда пользователь захочет что-то изменить/улучшить новыми плагинами, то количество подключенных плагинов может сильно вырасти (имхо конечно, но на http://wordpress.org/extend/plugins/ более 10000 плагинов предлагают, все такое вкусное)

>битрикс. Все возможные недостатки в нём есть

Плюсую. Комментировать даже не хочу, из-за этого продукта я стал мизантропом.

>Плюсую. Комментировать даже не хочу, из-за этого продукта я стал мизантропом.

Я Битрикса не видел. Но однажды пытался поработать с WebAsyst'ом. Мизантропом не стал, я в своё время в русской команде поддержки iPB был, мне после этого ничего не страшно, но всё равно, эмоций от этого продукта было много. И ни одной положительной :) В итоге от заказа отказался и зарёкся впредь с такими связываться. Самому проще написать, чем этого Франкенштейна укротить :D

>Я Битрикса не видел. Но однажды пытался поработать с WebAsyst'ом. Мизантропом не стал, я в своё время в русской команде поддержки iPB был, мне после этого ничего не страшно, но всё равно, эмоций от этого продукта было много. И ни одной положительной :) В итоге от заказа отказался и зарёкся впредь с такими связываться. Самому проще написать, чем этого Франкенштейна укротить :D

Я, кстати, работал и с битриксом, и с webasystom. Вебасист кривой, но хотя бы работал шустро, и видно было, что его авторы стараются что-то нормальное написать, пусть даже и не всегда получается. А так да, захардкоденный html вне темплейтов, 3 API для работы с БД (видимо старый, современный и планирующийся будущий). Это была версия где-то годовой давности.

В первый раз пришлось освоить рекурсивный grep по исходникам - всё достаточно непонятно и сходу не находится. Единственно - работает он достаточно шустро. А вот битрикс по сравнению с ним - ад.