те корпоративы, которые уровня энтерпрайза хорошую CMS на лоре не спрашивают - более того, в реалиях нашей родины единый правильный ответ для энтерпрайза - веб-компонента 1С.
joomla хороша для небольших и средних фирм, которым в вебе визиточку выложить, пару статей, каталог товаров (без вебмагазина), новостную ленту. в общем, покрывает потребности 90% фирм.
> в большинстве случаев лучше взять Zend/Catalyst/django и состряпать нужное самому.
о, еще один ценитель мейнстрима. поймите, не все зарабатывают себе на жизнь на баннерах и размещении контекстной рекламы. для многих сайт - просто визитка в интернете. и если нужна просто визитка - зенд и прочее пустая трата времени.
> простенькая [самописная] цмс-ка, а не монстрокомбайн жрущий ресурсы.
да плевать на ресурсы - нужен типовой хостинг и все. а в комбайне удобный визивиг и прочие приятности - иногда даже чел далекий от CMS в состоянии статью разместить и откорректировать.
Заглянул недавно внутрь джумлы - до сих плююсь. Типичная "радость студента". Корпоратив, буагага. Это корпоратив в стиле "русский бизнес" - когда один ушел искать вагон тушенки, другой чемодан долларов а третий пошел ставить джумлу.
> Это корпоратив в стиле "русский бизнес" - когда один ушел искать вагон тушенки, другой чемодан долларов а третий пошел ставить джумлу.
А как по мне - это когда за копейки можно получить пристойную визитку в инете. И не зачем попусту кормить толпы ненужных девелоперов, которые втирая заказчику страшные слова склепают ему очередной сайт с невменяемой админкой. А потом еще за сапорт будут драть.
вот смотрите, мы потратили месяц на разработку маленькой шустренькой цмс с визивигом, аяксом и прочими плюшечками, с админкой которой справится даже блондинка (в расчете на них и писалось).
ровно столько же было бы потрачено на изучение допиливание джумлы (от шаблонов которой до сих пор тошнит, кстати).
> мы потратили месяц на разработку маленькой шустренькой...
то есть мало того что месяц, так еще и "мы"?
> ровно столько же было бы потрачено на изучение допиливание джумлы (от шаблонов которой до сих пор тошнит, кстати).
у меня на шаблон джумлы уходит день от силы. потом день-три на занесение материалов. все.
я не спорю, может у вас стояла какая-то специфическая задача и очень требовательный заказчик.
но вот скажите мне, зачем этим http://www.oao-ratep.com/ делать свою ЦМС?
или вот - крупнейший в Европе комбинат по обогащению урана (деньгами ворочают неимоверными) - http://vostgok.com.ua/ (дизайн дерьмище еще то - но кому какое дело).
ой не надо. вордпресс вполне мебе неплох. мало того, на днях наткнулся на материалы по поводу того, как его в kohana скрестить - так вообще краса получается.
> ровно столько же было бы потрачено на изучение допиливание джумлы (от
> шаблонов которой до сих пор тошнит, кстати).
Джумла это г., но вы неправы.
Тут идея не в том что бы с нуля изучать Джумлу. И соревноватся в этом с написаннием с нуля CMS. Это бред.
Тут идея в том что если вы взяли некий нормальной FOSS CMS и на нем уже сделали некое количество сайтов, то очередной пройдет гораздо быстрее написания с нуля "своей" CMS.
> взяли некий нормальной FOSS CMS и на нем уже сделали некое количество сайтов, то очередной пройдет гораздо быстрее
+1. я когда впервые мамбу увидал - думал что это очень крутая, сложная и запутанная система. после пары сайтов на ней понял - что это вроде таблицы умножения для айтишника в отрасли сайтостроительства.
а что, друпал не плох. только шаблон в нем верстать тяжелее чем в джумле. между прочим простота верстки джумловского шаблона - одна из причин по которой я ее предпочитаю прочим.
> а что, друпал не плох. только шаблон в нем верстать тяжелее чем в
> джумле.
Там были какие то попытки сделать theme engine что бы темы были как в джумле но по моему его никто особенно не использует и до массового примения дело не дошло. Наверное оказалось ненужным...
А что вам кажется там таким сложным в средних друпаловских темах - три-четыре файла и css :) ?
не то чтобы сложным - излишне запутанным. плюс там файлы шаблона - практически часть движка, а потому при банальном обновлении может потребоваться аудит шаблона.
> Пардон, что вмешиваюсь, но системы не имеющие MVC должны иметь очень
> мало шансов на жизнь :)
А ООП не совсем заховало ваш мозг ? В друпале есть MVC согласно описанию из википедии. Там оно только не отморожено-обьектное и не кристалльно чистой сепарации на M V и C. :)
Там вообще очень практичная система, без доминирования концепции над реальностью.
> не то чтобы сложным - излишне запутанным. плюс там файлы шаблона -
> практически часть движка, а потому при банальном обновлении может
> потребоваться аудит шаблона.
Это какая еще часть движка, в каком смысле ? :)
Там вот API для шаблонов меняется, и это требует аудит шаблона, да. Но так вся идея именно в том что там шаблоны плотно натягиваются на структуру, а не находятся на "отдалении".
Соотвественно если то что темизируют меняется - меняется и шаблон.
А насчет запутанности - так весь друпал немного такой. :) Немного хитрый для продвинутого изучения. Да и альтернативные "простые" энжины популярности не получили.
>В друпале есть MVC согласно описанию из википедии. Там оно только не отморожено-обьектное
О какой отмороженности и объектности может идти речь, когда генерация HTML идёт прямо внутри PHP? И, ладно бы это для скорости особой было бы применено, но, ведь, тормоза подобного Друпалу поискать... В итоге:
- Скорость хреновая
- Модульность хреновая
- Расширяемость никакая
- Шаблоны невразумительные
Что в нём ещё остаётся после этого? :)
>Там вообще очень практичная система, без доминирования концепции над реальностью.
Да нет, там, как раз, в логике системы - доминирование концепции над реальностью, а в коде нет никакой концепции вообще.
Вот за подобные системы нормальные программисты PHP и за язык-то не считают :)
> когда генерация HTML идёт прямо внутри PHP? И, ладно бы это для
> скорости особой было бы применено,
Вот оно, то самое доминирование концепции над реальностью. В php изначально встроена поддержка темплейтов путем применения самого php. Ну и кому это мешает ? Но нет же - надо что обязательно было все раздельно "не внутри PHP", что бы удовлетворить "принципу раздельности" Иначе некошерно. :)
> но, ведь, тормоза подобного Друпалу поискать... В итоге:
В своем классе он быстрее аналогов. Есть независимые тесты. :)
И да - за универсальность расплачиваемся скоростью. Нужно быстрее - кеширование и оптимизация позволяют разогнать друпал на конкретной задаче до нужной скорости. Чему есть много пдтверждений создания на друпале сложных и нагруженых сайтов.
> - Скорость хреновая
> - Модульность хреновая
> - Расширяемость никакая
> - Шаблоны невразумительные
Сплошное 4.2 и "о вкусах не спорют". Скорость такая же или быстрее, модульность вообще одна из лучших. Друпал в отличие от многих других CMS реально позволяет собрать сложный сайт из существующих кирпичиков - что позволяет как гибкость структуры так и количество кирпичиков.
И придать ему необходимый лоск несколькими килобайтами кода, не являющимися обязательными. Это конечно будет не ультрабыстрый "самописный" сайт, ну так это обычно и не нужно для сайта. Это нужно для всяких вебприложений, сервисов и суперфорумов которые планируют держать на тормозном русском хостинге :).
И кстати насчет расширяемости c модульностью - моя телепатия подсказываети что под расширяемостью вы имеете в виду использование друпал даже вообще не как CMS :) Так вот - это хоть и CMF но там CMF для CMS а не для хитро^%$%банных вебприложений. Для этого вперед к питону и прочей яве.
> Что в нём ещё остаётся после этого? :)
Все что вы перечислили только со знаком плюс :)
> Да нет, там, как раз, в логике системы - доминирование концепции над
> реальностью, а в коде нет никакой концепции вообще.
вот это уже интересно - это какая же концепция там в логике которая не в коде ?
> Вот за подобные системы нормальные программисты PHP и за язык-то не
> считают :)
Нормальные программисты последнее время вызывают у меня странное чувство отторжения. Своей тягой программировать там где это не просто не нужно, но и вредно. :) Прямо набигают, тысячи их, и начинают программировать как бешенные. А потом ноют что им не платят денег ;)
>В php изначально встроена поддержка темплейтов путем применения самого php
Как думаешь, зачем придумали Vala, если он занимается трансляцией в GCC и зачем придумали GCC, если он занимается трансляцией в ассемблер? :)
>Но нет же - надо что обязательно было все раздельно "не внутри PHP", что бы удовлетворить "принципу раздельности"
И тут ты не прав. Шаблонизаторы в нормальных системах - отдельные модули. И могут использовать разные компоненты. Даже в рамках одного проекта. Принцип раздельности тут не первичен, а вторичен. Первично - удобство программирование и отладки.
>И да - за универсальность расплачиваемся скоростью.
У Друпала универсальностью и не пахнет. Узкозаточенный, нерасширяемый, неинтегрируемый.
>Сплошное 4.2 и "о вкусах не спорют".
Только если ты не видел нормальных систем :)
>И кстати насчет расширяемости c модульностью - моя телепатия подсказываети что под расширяемостью вы имеете в виду использование друпал даже вообще не как CMS :)
CMS - это конкретное решение. Если речь идёт о расширениях - то мы уже автоматически выходим на уровень CMF.
>вот это уже интересно - это какая же концепция там в логике которая не в коде ?
Таксономия.
>Нормальные программисты последнее время вызывают у меня странное чувство отторжения. Своей тягой программировать там где это не просто не нужно, но и вредно. :) Прямо набигают, тысячи их, и начинают программировать как бешенные.
Это ты видел не нормальных программистов, а быдлокодеров. Нормальные программисты пишут по десятку (одному) строк в день и им этого хватает :)
> Как думаешь, зачем придумали Vala, если он занимается трансляцией в
> GCC и зачем придумали GCC, если он занимается трансляцией в
> ассемблер? :)
И ? Очень намекающе намекаешь, ничего не понять.
> И тут ты не прав. Шаблонизаторы в нормальных системах - отдельные
> модули.
И в друпале отдельные. Но прижился почему то именно этот способ, при наличие прочих.
> И могут использовать разные компоненты. Даже в рамках одного
> проекта.
Тут я тебя потерял. Какие именно разные компоненты ?
> Принцип раздельности тут не первичен, а вторичен. Первично
> - удобство программирование и отладки.
Ага ага. Удобство _программирования_. Понимаешь, удобство программирования первично именно в том случае когда надо много и со вкусом программировать. А это нужно когда тебе не подходит репозиторий в овер 2к модулей и ты пишешь сайт фактически с "нуля". И тебе нужны не модули друпала которые предоставляют функционал сразу пользователю, а всякие "компоненты" и "классы", гибкость которых ты меряешь по степени доступных с ними программистских извращений. Программистский подход ко всему.
> У Друпала универсальностью и не пахнет. Узкозаточенный,
> нерасширяемый, неинтегрируемый.
Я все больше и больше подозреваю что в слова "универсальный", "узкозаточенный", "расширяемый", "интегрируемый" мы вкладываем совершенно разное наполнения. Так как все эти слова они относительно задачи и эти задачи у нас с тобой в вебдевелопменте совершенно разные :)
> Только если ты не видел нормальных систем :)
Приведи пример. Уже боюсь фреймворков на лиспе написанных жестоко overqualified программерами сокращенными из ИИ лаб вследствие budget cut.
Это кстати вообще проблема человечества - когда какой нибудь форум в интернете делает сокращенный из узконавороченой области лисп(форт :) )-уберпрограммист. Он там не на месте. :)
Так как в результате мы получаем не доступный любому для чтения код, а хрень понятную исключительно после прочтения горы талмудов, зубрения жосткого матана и овер 10 лет опыта в индустрии.
> CMS - это конкретное решение. Если речь идёт о расширениях - то мы
> уже автоматически выходим на уровень CMF.
Вот вот. Уже подозрительно.
> Таксономия.
Считаете что если таксономия в дистрибутиве, значит это было "по дизайну" ?
Разочарую - таксономия там как популярный аддон. По этому его "внутри" и нету. Вообще друпал почти весь это "популярный аддон". Из 29 модулей дистрибутива лично я использую 8, все остальное это невходящие в дистрибутив расширения.
Основа дизайна друпала это система хуков подобранная эмпирически с целью максимального удобства текущей коммюнити. Основа это nodeapi и некая невысказанная идеология которой вы, похоже, не признаете :).
> Это ты видел не нормальных программистов, а быдлокодеров. Нормальные
> программисты пишут по десятку (одному) строк в день и им этого
> хватает :)
Это я боюсь не нормальные программисты :) а редкие исключения. Смотря что считать нормальным, как говорится. :)
PS
Да и не уверен что нормальным программистам в вашем смысле место в вебдевелопменте, за исключением мест вроде яндекса(речь про зону .ру).
Поясняю. Люди ленивы. И поэтому сложные решения упрощают.
>И в друпале отдельные.
Да ладно. Т.е. он в качестве шаблонизатора может использовать произвольный движок? Ткни в пруфлинк.
>Тут я тебя потерял. Какие именно разные компоненты ?
Захочу я то, что удобнее слепить на Smarty слепить на Smarty, а то что удобнее на PHP - на PHP. Можно так?
>Понимаешь, удобство программирования первично именно в том случае когда надо много и со вкусом программировать.
Демонстрация полного отсутствия опыта программирования или непонимание вопроса. Удобство программирования первично всегда, когда приходится программировать. Точка. Если тебе для решения одной задачи в одном случае нужно написать 10 простых строк, а в другом 50 сложных, то в первом случае мы имеем более удобную схему при любом раскладе.
>Это я боюсь не нормальные программисты :) а редкие исключения
Не знаю. Вот лет 10 назад видел статистику. Что среднетемпературный по больнице программист пишет в день в среднем 8 строк. Это если число строк проекта разбить на число дней его разработки. При чём эта величина мало меняется от языка к языку - на более выразительных языках просто продуктивность выше получается.
...
Я несколько лет назад подсчитывал - у меня получилось 12 строк в день. Похоже, я пока ещё перерабатываю :) Хотя в последние пару лет постарался сильно урезать эту цифру, но точно подсчитать не могу - веду параллельно ряд проектов, по очереди работая с каждым из них. Но, надеюсь, я сейчас пишу меньше 8 строк в день :) (что не исключает того, что я могу неделю почти ничего не делать, а пото за ночь сделать недельную "норму" :))
Пардон, я так не говорю. А если и вырвалось где-то (перечитывать влом), то гиперболически. Просто считаю его некрасивой и неудобной системой. Но понятия "некрасив и неудобен" и "очень плох" могут быть вообще ортогональны :)
> Поясняю. Люди ленивы. И поэтому сложные решения упрощают.
То есть ты считаешь что применение PHP внутри PHP по прямому назначению это сложно ? Я правильно понял ?
> Да ладно. Т.е. он в качестве шаблонизатора может использовать
> произвольный движок? Ткни в пруфлинк.
Лично я об этом узнал из сорцов - файл include/theme.inc и каталог
themes/engines где один подкаталог phptemplate соответсвующий любимому всеми движку на нелюбимом тобой принципе. Другие произвольные движки реализуются имплементацией вызовов соотв функций в этом самом движке.
Хотя вот, погуглил - сам удивился. http://drupal.org/node/176129
Даже смарти твой есть - чему собственно и удивился.(Да, естественно чтобы любой движок прикрутить надо модуль прикрутки писать и все такое.)
> Захочу я то, что удобнее слепить на Smarty слепить на Smarty, а то
> что удобнее на PHP - на PHP. Можно так?
Можно. Но мне такая потребность в голову не приходила. Даже поломал немного голову как это было бы удобно сделать.
Можно делать разные темы на разные урлы соотвествующем модулем. А где разные темы там и разные темовые движки. Ну и "вручную", да, тогда можно и разные места на странице через разные движки. Но повторюсь - это все у тебя другой подход, отсюда и другие требования.
Ты собрался таким способом недрупальный код встраивать что ли ?
> Демонстрация полного отсутствия опыта программирования или
> непонимание вопроса. Удобство программирования первично всегда,
> когда приходится программировать. Точка. Если тебе для решения одной
> задачи в одном случае нужно написать 10 простых строк, а в другом 50
> сложных, то в первом случае мы имеем более удобную схему при любом
> раскладе.
Неа, не при любом. Если у тебя есть овер 9к модулей которые уже отлажены и неплохо стыкуются друг с другом, то для определенной группы задач не важно 10 строк или 50. Так как ну будет у тебя в другой системе 100 строк связки вместо 500 на неудобной. И 10М строк для написание тех модулей которых в "удобной для программирования" системе нет. А есть в неудобной.
Ну и мерять удобство строками кода это тоже не совсем правильно. Ну напишет там какой perl-изверг или крейзи-хаскель 10 строк больше похожих на tty мусор, и ? Спасибо, лучше уж я в системе поработаю где таких суперпрограммеров нету, а есть 50 срок просто и понятно.
> Не знаю. Вот лет 10 назад видел статистику. Что среднетемпературный
> по больнице программист пишет в день в среднем 8 строк. Это если
> число строк проекта разбить на число дней его разработки. При чём
> эта величина мало меняется от языка к языку - на более выразительных
> языках просто продуктивность выше получается.
А, ты про это ! Я уж подумал что ты про тех программистов что реально садятся и каждый день не больше 10 строк пишут. Напишут там 10 строк и идут в гольф играть :)
А у среднетемпературного программиста 10 строк получаетс когда он сначала много много кодит а поттом они всей больницей баги ловят месяцами.
>того, что я могу неделю почти ничего не делать, а пото за ночь
> сделать недельную "норму" :))
Я все таки думаю что у тебя твои 8 строк статистически получаются. Или вес таки 8 строк а потом гольф ? ;)
> Захочу я то, что удобнее слепить на Smarty слепить на Smarty, а то что удобнее на PHP - на PHP. Можно так?
А зачем? Смарти избыточен. Ничего ровным счетом не даёт, то есть вообще ничего. Только отжирает ресурсы.
Существование смарти вообще опровергает твой тезис по поводу стремления людей к упрощениям :) Зачем писать пхп на пхп и вызывать его из пхп, когда можно просто использовать пхп? :)
>А зачем? Смарти избыточен. Ничего ровным счетом не даёт, то есть вообще ничего. Только отжирает ресурсы.
Поскольку у меня сейчас и Smarty, и Pure PHP используются равнозначно, есть, как бы, приличный опыт использования и того, и другого на одной задаче.
Smarty в подавляющем большинстве случаев компактнее и нагляднее (и, в отличии от PHP, является валидным с точки зрения синтаксической подсветки, он не требует писать невалидных конструкций вида alt="<?=$alt?>"). А дальше - самое смешное. Я PHP-шаблонизаторы вводил для особо критичных по скорости мест. Оказалось - фигня. Потеря производительности редко превышает 10-20%. Всё же, Smarty не интерпретируется, а компилируется. Так что на PHP сейчас пишу только там, где реально получается проще (когда логика представления _очень_ сложная) или когда скорость важна настолько, что даже эти 20% - существенны.
>Зачем писать пхп на пхп и вызывать его из пхп, когда можно просто использовать пхп? :)
Зачем писать Python на Си и вызывать его из Си, когда можно просто использовать Си?