Форум Joostina

boston сказал: акой вот философский вопрос

Если по теме, то
- вариативная работа "из коробки" как с apache так и изолировано с nginx
- возможность поддержки "из коробки" кросс-доменных ajax
- возможность "из коробки" работать с CDN
- автоподгрузка из репозиториев js (тот же jq), при отсутствии - выбор на локальное хранилище
- поднос пива к клавиатуре :)

Оставить только ядро и управление. Всё остальное, абсолютно всё(!) вынести как расширения. Вот не нужен мне файловый менеджер - нет, не нужна мне регистрация - нет.. и т.д. и т.п :)

и полностью переходить на HTML5 + CSS3

doctorgrif сказал: - вариативная работа "из коробки" как с apache так и изолировано с nginx

- возможность поддержки "из коробки" кросс-доменных ajax

- возможность "из коробки" работать с CDN

Шикарно )))

GoDr сказал: Оставить только ядро и управление.

Во, в этом мы схожи :)

Недавно мне повезло, и я познакомился с такой замечательной штукой, как Yii Framework. Расскажу, что мне в нем понравилось.
---------------------
1. Полноценный ActiveRecord. Думаю, что не стоит много расписывать о том, что это хорошо. ActiveRecord должен быть, и он должен быть не такой, как в Joostina 1.3, раз его обсуждать, то в отдельной ветке нужно.
2. Приложение отделено от ядра. Полностью отделено, то есть, к своему приложению можно подключить любое совместимое ядро Yii и положить его в какую угодно папку на сервере. Преимущества: а) Если все сайты компании на Yii, можно использовать общее ядро для всех. б) Если разработчики ядра внесли фиксы - ты просто скачал себе новую версию ядра, например, yii-1.1.6.r2877, подключил его, и у тебя свежее ядро на твоем сайте, ну или на всех сайтах, которые работают на этом ядре.
3. Графический генератор кода. Создал табличку в БД, зашел в генератор, сгенерил модель, потом на основе модели сгенерил код для CRUD. Все, управление статьями готово.
4. У Joostina низкий уровень абстракции. Вспомним про Inversion of Control, одним из правил которого является то, что модули должны зависеть от абстракций, а не от реализаций. Банальным примером нарушения этого правила является класс database, который не зависит ни от какой абстракции. Ну захочу я юзать свой класс MongoDatabase для работы с MongoDB, кокой интерфейс мне реализовывать в этом классе? Нет такого интерфейса...
5. ЧПУ. Получать ссылки из БД - это как-бы не сладко совсем для производительности. Нужно так: зашел в конфиг, описал правила, ЧПУ работает. Естественно, что расширение, отвечающее за работу ЧПУ должно поставляться в комплекте с Joostina. Именно расширение в комплекте, а не зашивать в ядро. Функции ядра - подключать и выполнять нужные расширения, а не ЧПУ реализовывать.
6. Autoloader файлов.
7. Поставщики данных (Data provider). Создал объект ContentDataProvider, передал его в какой-то объект класса JoosList, этот объект отобразил список статей с пагинацией. Опять же, зависимость класса JoosList должна быть от абстракции, не должен JoosList зависеть от какого-то конкретного ContentDataProvider-а, он должен зависеть от DataProviderInterfece, а ContentDataProvider должен реализовывать этот интерфейс.
8. Switch в контроллере - это очевидно, что его быть не должно.
9. В компоненте должна быть возможность реализовать полноценную MVC модель. Если для какого-то "сопливого" и маленького компонента вроде JoosOpenMarket еще можно запихнуть управление категориями, товарами, типами товаров и т.д. в один контроллер, то если делать что-то более солидное - контроллер будет ну ооочень большим и не удобным, это не правильно.
10. В Yii сделали классное API для построения системы управления прав на основе RBAC, а хороший человек из Финляндии написали классный графический интерфейс на основе этого API.
11. Юзабилити. Мы делаем сайты на Joostina, и наши клиенты визжат о том, что админка не удобная. Я сейчас, к сожалению, не расскажу всех нюансов юзабилити, это нужна оценка юзабилистов. Советовал бы пригласить эксперта в данной области, и проконсультироваться, если есть возможность. Из того, что могу вспомнить - это ну просто очень много нареканий на редактор было, он банально не работал иногда (это я про дэфолтный tinyMCE, который идет в комплекте с Joostina 1.3)
---------------------
Вот так вот, это такое краткое видение нуба, я могу ошибаться, так как многого не знаю...
---------------------
Раз уж принимаются варианты вроде "Переписать на RoR", ну тогда я бы переписал на Yii, так как там уже все написано, если бы это делалось только для собственного использования.
Но так как, на сколько я понимаю, Joostina делается для того, чтоб построить собственную платформу для разработки, тогда вариант переписать на Yii не подходит. Но думаю, что 100% стоит изучить архитектуру других, более мощных систем, того же RoR, и взять оттуда лучшее, что можно взять.
---------------------
Надеюсь, что мое получасовое изложение мыслей принесет какую-то пользу )))

AndreyGeonya всё правильно сказал!

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

Давайте всё же делиться мыслями, а не обсуждать их :)

ОК, тогда добавить возможность подключения к шаблонизации сайта css фреймворков :)
Сам знаешь мою паранойю ;)

doctorgrif сказал: озможность подключения к шаблонизации сайта css фреймворков

и вообще, хотелось бы чтобы можно много чего подключать и в соответствии со спецификацией...