Переписываем ядро. Выкладываем на публичный доступ.

Проект CMF/CMS дозрел у меня до такой степени абстрагирования данных и логики от программного решения, что было решено ядро системы переписать с нуля, опираясь на уже работающую систему. Ибо в старой системе некоторые хвосты тянутся ещё с ~2001года. И очень большой груз совместимости со старыми технологическими решениями.

И, наконец, можно будет сразу же, по мере расширения, держать этот проект на публичном SVN для всех желающих. Нынешний не раскрывается именно потому что там много древнего кода, писанного в те времена, когда о вопросах безопасности я только начинал задумываться

А раз ядро переписывается - нет большой разницы, писать его опять на PHP, или же выбрать иную платформу. В первую очередь были выдвинуты Django и Resin.

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

- Всё же не хочется совсем бросать на произвол судьбы некоторые проекты на старой версии системы на сторонних хостингах. А получить сегодня Django, не говорю уже о Resin'е на той же Агаве - это нереально.

- На PHP можно слепить систему уровня "скопировал по FTP на хостинг и тут же запустил" для совсем уже разных ламеров. Для которых о безопасности можно подумать заранее, при составлении дистрибутива. А поднять проект на Питоне или Яве под силам далеко не каждому админу-новичку. Лемеры же оные, могут ламерами только в области программирования и администрирования. Будучи при этом профессионалами в других областях. Вот, знакомый историк таким образом сейчас себе сайт начинает делать. И в случае проекта на PHP он может работать тупо разворачивая систему с FTP, а что ему делать в случае то же Django?

Так что, похоже, новую систему буду писать таки на PHP. Заодно, будет интересный вызов. Может ли в отточенном виде фрейморк на PHP соревноваться в тем же Питоном или РоР

А если через 2..5..7 лет ситуация изменится, и на хостингах массово появятся иные решения - всегда можно будет переписать. Ибо логика уже отработана

На каком РНР?

Mishka> На каком РНР?

На 4-м. Как на самом массовом на сегодняшний день При этом совместимость буду обеспечивать с "родным" PHP5 и с PHP5 под Resin.

Жалко, всё-таки, что на PHP. Из хостеров выбивать надо, а не подчиняться им - кто кому деньги платит-то?

Balancer> А поднять проект на Питоне или Яве под силам далеко не каждому админу-новичку.

Поднять проект на Django - просто, очень просто. А в разработке фреймворка на Джанго я бы и помог, может быть

А зачем деньги из хостеров — они сами РНР дают сейчас. Причём 4 и 5 версии.

Murkt> Жалко, всё-таки, что на PHP. Из хостеров выбивать надо

Так не мне же

Murkt> а не подчиняться им - кто кому деньги платит-то?

Ну, найди быстро хостера уровня хотя бы Агавы (с её ценами, в смысле и, хотя бы, её уровня поддержкой), который бы позволил заюзать Django М.б. тогда перетащу туда пару знакомых, которые на моей CMS сидят. Хотя тут, всё равно, ещё коммьюнити в целом остаётся

Murkt> Поднять проект на Django - просто, очень просто. А в разработке фреймворка на Джанго я бы и помог, может быть

Django, навскидку, это уже довольно жёсткий фреймворк. Конечно, как я понимаю, не RoR, поворачивать на нём можно, не только по рельсам в одну сторону ехать, но... У себя хочу делать очень гибкую систему

Вот можно ли в Django в рамках одного проекта штатными средствами брать данные "размазанные" по MySQL (один объект - несколько таблиц) и, кроме них, данные, хранящиеся в plain/text-файлах разного вида? Наверняка придётся писать нехилую обвязку под всё это, не очень хорошо вписывающийся в исходную идеологию.

Я же стараюсь изначально предельно развязать все компоненты системы. Как по уровню шаблонов/логики/данных, так и по уровню хранилищ, методов перехватки, кешей и т.д.

...

Блин, за последнюю неделю работал над сабжевым вопросом от силы час Не продумал ещё до конца некоторые идеологические моменты.

Balancer> Ну, найди быстро хостера уровня хотя бы Агавы (с её ценами, в смысле и, хотя бы, её уровня поддержкой), который бы позволил заюзать Django

В Украине?

Balancer> Django, навскидку, это уже довольно жёсткий фреймворк.

Джанго - гибкий фреймворк. Ты произвольно можешь не использовать того, чего тебе не нужно.

Balancer> Вот можно ли в Django в рамках одного проекта штатными средствами брать данные "размазанные" по MySQL (один объект - несколько таблиц) и, кроме них, данные, хранящиеся в plain/text-файлах разного вида?

Извращения Такого - нет конечно. Но стандартная ORM сделана именно для стандартных случаев, там не пытаются покрыть все возможные и невозможные варианты. Если надо что-то своё - пишешь своё, благо это просто Если нужно custom-SQL - можно полностью задавать выражение, можно частично. А ещё сейчас есть бранч, где в качестве ORM впихивают SQLAlchemy.

Balancer> Я же стараюсь изначально предельно развязать все компоненты системы. Как по уровню шаблонов/логики/данных, так и по уровню хранилищ, методов перехватки, кешей и т.д.

Как я уже сказал, в Джанге это всё тоже нормально развязано.

Murkt> В Украине?

Нет, в Москве

Murkt> Извращения Такого - нет конечно. Но стандартная ORM сделана именно для стандартных случаев

А у меня цель - сделать "системный клей", позволяющий соединять готовые решения разных проектов. Собственно, именно так и приходится поступать, например, на основной работе Да и на Авиабазе ещё много к чему есть стремиться. Есть ли на Django форум хотя бы уровня punbb? Или фотогалерея, типа Coppermine? Я предпочитаю на первых порах использовать готовые наработки, гармонично "вклеивая" их в систему. А вот форматы данных у этих проектов могут быть совершенно разными. Опыт привязки к punbb показал, что даже имеющихся возможностей моей CMS пока не хватает...

>Если нужно custom-SQL - можно полностью задавать выражение, можно частично.

Нет, SQL должен быть полностью отделён от основной системы. Сам нарушаю периодически это правило, но только от недоработанности до конца модели ядра системы. Глубоко скорблю по этому поводу и готовлю ещё бОльше разделение Собственно, получается два уровня драйверов. Скажем, непосредственно mysql-драйвер и работающие на его основе (тоже сменные) классы sql-хранилища.

Balancer> Нет, в Москве

Как же я тебе в Москве найду?

Balancer> Есть ли на Django форум хотя бы уровня punbb?

Хз. В принципе, можно мой доработать.

Balancer> Или фотогалерея, типа Coppermine?

А что такое Coppermine? Поискать надо, может и есть. А можно, опять же, своё написать, потому что это можно делать быстро

Вообще, структура Джанговского проекта предпологает разбиение/включение в себя application'ов. Но я знаю, что я тебя переубедить не смогу, и ты всё равно будешь на PHP писать