Про Joostina X
  • bostonboston Май 2011
    Итак ребятки, потихонечку открываем занавес.

    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>, нормальный веб-сервер.

    Обсуждения не касающиеся кода - в этой теме, всё остальное - строго в соседних.

    Логин / пароль: admin / 123456
    Отредактированно boston в 2011-05-24 10:08:25
  • MaiwendMaiwend Май 2011
    Николай, наверно эта версия будет таки стержнем и иметь преемственность?
    А то развитие компонентов не поспевает за версиями самой Жустины.
    Выйдет версия X и можно забыть про 1.3 :)

    Долгосрочная приемственность очень важна, когда годы площадка может жить на платформе и к ней будут доступны разные платные и бесплатные компоненты.
    Отредактированно Maiwend в 2011-05-24 12:30:09
  • VladzimirVladzimir Май 2011
    Джустина Х в плане совместимости даже не будет как Джумла 1,0 и 1,5. Это совершенно две разные системы (хоть и имеют частично похожую структуру и функционал). Николай решил кардинально разобраться со всеми недугами которые присущи Джустине/Джумле. А на счет компонентов - то их и не так много и было портировано под Джустину 1,3,0,*. А вот с выходом этой версии у разработчиков появляется огромное поле для маневра. При этом никто не забрасывает Джустину 1,3. Самый простой пример Джустина 1,2,* до сих пор поддерживается одним энтузазистом. Так и здесь найдется парочка людей. Это как с пристройками в доме, вроде и работает - а все равно это не монолитное строение.
    При этом новая система получает огромную гибкость, легкость. Ну а импорт пользователей/статей можно сделать всегда.
  • bostonboston Май 2011
    Новая версия это основа, на ней дальше уже будем строить дополнительные фишки и расширения. В ней постарались сделать всё так, как нравится, считаем правильным и оптимальным. Так что хватить её должно на долго :)

    От 1.3 не отказываемся, для неё так же будем выпускать критические правки, может часть функционала новой версии туда портируем.
  • Dolphin Май 2011
    Ответьте мне пожалуйста на главный вопрос, который меня мучает вот уже 3 года. Будет ли в новой жустине расширенная работа с профилями пользователей? :)
  • GoDrGoDr Май 2011
    вот сижу и думаю... стоит ли писать под 1.3 или подождать сразу 2.0 :)
  • bostonboston Май 2011
    >Dolphin
    зависит от того что подразумевает по собой "расширенная работа с пользователями"
  • GoDrGoDr Май 2011
    >зависит от того что подразумевает по собой "расширенная работа с пользователями"
    имеется в виду настраиваемый профиль как минимум :) ну типа знаменитого Community Builder
  • Dolphin Май 2011
    да да да ) и возможность интеграции всяких модулей для профиля, типа одноклассников. И в обяз систему внутренних сообщений :)
  • GoDrGoDr Май 2011
    если будет по типу Community Builder то любые плигины можно написать.. По крайней мере под него уже писал, достаточно просто... Но это очень большой монстр :) пришлось отказаться в новых проектах
  • Dolphin Май 2011
    :) хех... ну будем ждать что скажет boston.
  • ZaiSL Май 2011
    По "расширенному" профилю - как только мы придем к четкому пониманию того, как должна работать система плагинов в новой версии (сейчас этот вопрос еще в стадии обдумывания) - сразу же появится удобный инструмент для расширения функционала компонентов. Так что, это просто вопрос времени.
    Что касается настроек компонентов - то да, это всё будет в оптимальном объеме (под оптимальным объемом я подразумеваю "золотую середину" между простотой настроек, логичностью кода и скоростью работы приложения)
  • VladzimirVladzimir Май 2011
    @ZaiSL, а как ты себе представляешь мультиязычность? Ну в общих чертах.
  • ZaiSL Май 2011
    Vladzimir, если ты про мультиязычность контента - то, скорее всего, для небольших проектов я бы реализовала отдельными таблицами для каждого языка. Т.е. для основного языка все остается, как было, а для английского (например) - создается таблица, в которой хранятся данные вида "component - id - attr - text".Или же, как вариант - хранить все переводы в одном и том же поле, через разделитель Для больших проектов такая структура, считаю, не совсем оптимальна, нужно изучить тему поглубже...
  • VladzimirVladzimir Май 2011
    Именно контента. Если хранить в разных таблицах, то возникает вопрос как отслеживать взаимосвязь переведенных статей. Т.е. что эта статья есть перевод этой статьи?
    А не проще ли изначально заложить в систему мультиязычности? Т.е везде в таблицах присутствует поле - язык и все выборки делать с учетом этой переменной? Или как вариант чтобы каждая таблица дублировалась для каждого языка, но тогда возникает вопрос а как их между собой синхронизировать.
    Отредактированно Vladzimir в 2011-05-26 06:35:43
  • fadefade Май 2011
    Главная табличка (jos_content) где id (автоикримент), дата добавления и другое, без тектста...
    Доп таблички для языков (jos_content_lang), где связь с первой по jos_content_lang.content_id = jos_content.id, в ней поля уже - Вводный текст, Основной и другое...
    Отредактированно fade в 2011-05-26 06:51:04
  • ZaiSL Май 2011
    Для небольших проектов подойдет и одна таблица для абсолютно всего контента. Связь по `component` (компонент, которому принадлежит запись), `type` (в некоторых компонентах могут быть разные типы данных), id (идентификатор объекта, который переводим), `attr` (атрибут объекта, поле в таблице БД, который переводим). В `text` - помещаем непосредственно сам перевод.
    `component` и `attr` могут быть заменены на конкретные `таблица` и `поле` (тогда надобность в `type` отпадает), но это порождает высокую связность.
  • VladzimirVladzimir Май 2011
    А для нагруженных какая должна быть архитектура?
  • ZaiSL Май 2011
    Для нагруженных - даже не могу сейчас сказать что-то конкретное, так как не реализовывала подобное. Все способы, кроме дублирования таблиц, создают массу сложностей в случае, если по данным требуется производить поиск/выборки. Попробую подумать на досуге... Нужно тему создать по этому вопросу)
  • ArkadiyArkadiy Май 2011
    Не вижу никаких проблем при дублировании таблиц контента, подставить ланг в имя таблицы при записи и выборке как два пальца об асфальт.
    Отредактированно Arkadiy в 2011-05-26 09:54:53
  • VladzimirVladzimir Май 2011
    А как тогда соотнести пост из английской таблицы к посту из русской??? Переводы то должны быть связанными по id языка. Поэтому изначально предлагаю добавить в таблицы где есть текст который гипотетически может переводится идентификатор языка и все запросы делать с учетом текущего языка.
    @ZaiSL - можно посмотреть как реализовано в open-cart.com
  • ArkadiyArkadiy Май 2011
    Соотнести по иду нет проблем, устанавливать им одинаковые иды и все, допустим в основную таблицу записали, взяли новый ид и с ним уже в другие записали.

  • GoDrGoDr Май 2011
    вообще не вижу проблем с мультиязычностью.. Есть основная таблица с контекстом. Создаём вторую таблицу с контекстом, где есть только поля с "буквами" (краткое содержание, полное содержание....) + поле идентификатор языка + поле идентификатор (связь) основного контента..

    Тогда можно будет делать хоть все языки планеты хоть для всех статей, хоть выборочно
  • VladzimirVladzimir Май 2011
    То что ты предлагаешь - не поддается унификации.
    Основная таблица - это хорошо, а если вдруг сменить дефолтный язык на другой - как здесь быть? А для реализации моего предложения нужен всего одно поле в каждой таблице - идентификатор языка.
  • GoDrGoDr Май 2011
    никаких проблем нет... если сменили язык то можно найти его сначала в дополнительной таблице.. а все данные получить уже из основной.. Почему так, да потому чтобы меньше места занимали таблицы и всегда есть привязка к основной статье и без разницы какой у неё язык
  • bostonboston Май 2011
    Предлагаю все рассуждения про мультиязычность перенести в другую тему.
Добавить комментарий

Добро пожаловать!

Похоже, что Вы здесь впервые. Если хотите поучаствовать, нажмите на одну из этих кнопок!

Войти Зарегистрироваться

Категории

В теме отметились