Git для новой Joostina - https://github.com/joostina/joostina , там можно собрать актуальную сборку, запостить ошибку или прислать патч для рассмотрения. Форки и комментарии приветствуются.
Тут в категориях понемногу размещаем описания и документацию, а так вообще в коде много комментариев с описаниями что для чего и примерами использования.
Joostina X развивается по плану, на текущий момент возможности все почти созданы и принятие новых прекращено. Дальше только отладка и оптимизация. Приём и добавление новых фич - не раньше 2.0.2 версии.
Новая Joostina на 100% НЕ совместима с Joostina, Joostina 1.1.*, Joostina 1.2.*, Joostina 1.3.*, Joomla 1.0.*, Joomla 1.5.*, Joomla 1.6.*, Drupal, Yii, Wordpress и другими системами, это полностью новая версия без оглядки на старые и перетягивание зависимостей.
Требования: php 5.3>, mysql 5.1>, нормальный веб-сервер.
Обсуждения не касающиеся кода - в этой теме, всё остальное - строго в соседних.
Николай, наверно эта версия будет таки стержнем и иметь преемственность? А то развитие компонентов не поспевает за версиями самой Жустины. Выйдет версия X и можно забыть про 1.3 :)
Долгосрочная приемственность очень важна, когда годы площадка может жить на платформе и к ней будут доступны разные платные и бесплатные компоненты.
Джустина Х в плане совместимости даже не будет как Джумла 1,0 и 1,5. Это совершенно две разные системы (хоть и имеют частично похожую структуру и функционал). Николай решил кардинально разобраться со всеми недугами которые присущи Джустине/Джумле. А на счет компонентов - то их и не так много и было портировано под Джустину 1,3,0,*. А вот с выходом этой версии у разработчиков появляется огромное поле для маневра. При этом никто не забрасывает Джустину 1,3. Самый простой пример Джустина 1,2,* до сих пор поддерживается одним энтузазистом. Так и здесь найдется парочка людей. Это как с пристройками в доме, вроде и работает - а все равно это не монолитное строение. При этом новая система получает огромную гибкость, легкость. Ну а импорт пользователей/статей можно сделать всегда.
Новая версия это основа, на ней дальше уже будем строить дополнительные фишки и расширения. В ней постарались сделать всё так, как нравится, считаем правильным и оптимальным. Так что хватить её должно на долго :)
От 1.3 не отказываемся, для неё так же будем выпускать критические правки, может часть функционала новой версии туда портируем.
Ответьте мне пожалуйста на главный вопрос, который меня мучает вот уже 3 года. Будет ли в новой жустине расширенная работа с профилями пользователей? :)
>зависит от того что подразумевает по собой "расширенная работа с пользователями" имеется в виду настраиваемый профиль как минимум :) ну типа знаменитого Community Builder
если будет по типу Community Builder то любые плигины можно написать.. По крайней мере под него уже писал, достаточно просто... Но это очень большой монстр :) пришлось отказаться в новых проектах
По "расширенному" профилю - как только мы придем к четкому пониманию того, как должна работать система плагинов в новой версии (сейчас этот вопрос еще в стадии обдумывания) - сразу же появится удобный инструмент для расширения функционала компонентов. Так что, это просто вопрос времени. Что касается настроек компонентов - то да, это всё будет в оптимальном объеме (под оптимальным объемом я подразумеваю "золотую середину" между простотой настроек, логичностью кода и скоростью работы приложения)
Vladzimir, если ты про мультиязычность контента - то, скорее всего, для небольших проектов я бы реализовала отдельными таблицами для каждого языка. Т.е. для основного языка все остается, как было, а для английского (например) - создается таблица, в которой хранятся данные вида "component - id - attr - text".Или же, как вариант - хранить все переводы в одном и том же поле, через разделитель Для больших проектов такая структура, считаю, не совсем оптимальна, нужно изучить тему поглубже...
Именно контента. Если хранить в разных таблицах, то возникает вопрос как отслеживать взаимосвязь переведенных статей. Т.е. что эта статья есть перевод этой статьи? А не проще ли изначально заложить в систему мультиязычности? Т.е везде в таблицах присутствует поле - язык и все выборки делать с учетом этой переменной? Или как вариант чтобы каждая таблица дублировалась для каждого языка, но тогда возникает вопрос а как их между собой синхронизировать.
Главная табличка (jos_content) где id (автоикримент), дата добавления и другое, без тектста... Доп таблички для языков (jos_content_lang), где связь с первой по jos_content_lang.content_id = jos_content.id, в ней поля уже - Вводный текст, Основной и другое...
Для небольших проектов подойдет и одна таблица для абсолютно всего контента. Связь по `component` (компонент, которому принадлежит запись), `type` (в некоторых компонентах могут быть разные типы данных), id (идентификатор объекта, который переводим), `attr` (атрибут объекта, поле в таблице БД, который переводим). В `text` - помещаем непосредственно сам перевод. `component` и `attr` могут быть заменены на конкретные `таблица` и `поле` (тогда надобность в `type` отпадает), но это порождает высокую связность.
Для нагруженных - даже не могу сейчас сказать что-то конкретное, так как не реализовывала подобное. Все способы, кроме дублирования таблиц, создают массу сложностей в случае, если по данным требуется производить поиск/выборки. Попробую подумать на досуге... Нужно тему создать по этому вопросу)
А как тогда соотнести пост из английской таблицы к посту из русской??? Переводы то должны быть связанными по id языка. Поэтому изначально предлагаю добавить в таблицы где есть текст который гипотетически может переводится идентификатор языка и все запросы делать с учетом текущего языка. @ZaiSL - можно посмотреть как реализовано в open-cart.com
Соотнести по иду нет проблем, устанавливать им одинаковые иды и все, допустим в основную таблицу записали, взяли новый ид и с ним уже в другие записали.
вообще не вижу проблем с мультиязычностью.. Есть основная таблица с контекстом. Создаём вторую таблицу с контекстом, где есть только поля с "буквами" (краткое содержание, полное содержание....) + поле идентификатор языка + поле идентификатор (связь) основного контента..
Тогда можно будет делать хоть все языки планеты хоть для всех статей, хоть выборочно
То что ты предлагаешь - не поддается унификации. Основная таблица - это хорошо, а если вдруг сменить дефолтный язык на другой - как здесь быть? А для реализации моего предложения нужен всего одно поле в каждой таблице - идентификатор языка.
никаких проблем нет... если сменили язык то можно найти его сначала в дополнительной таблице.. а все данные получить уже из основной.. Почему так, да потому чтобы меньше места занимали таблицы и всегда есть привязка к основной статье и без разницы какой у неё язык