TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Дополнительные модули для Kohana
  • Предлагаю обсудить наиболее популярные/актуальные модули, не являющиеся штатными. То есть поддерживаемые сообществом.

    Цель проста: собрать в одном месте модули первой необходимости, развивать их, обновлять под новые версии фреймворка, писать документацию и тесты. Предполагаю, что наиболее удобный способ - создать организацию на гитхабе.

    Первоочередные задачи:

    1. Определиться со списком основных модулей. Возможно, использовать опыт других фреймворков, предлагающих бОльшее количество модулей из коробки. Скорее всего, у многих есть свои наработки - они могут стать фундаментом.
    2. Выделить основных разработчиков (активистов). Присылать патчи могут все, но кто-то должен управлять процессом разработки.
  • По первому пункту.

    1. На форуме часто упоминается кодогенератор.
    2. Возможно, некий модуль для работы со статикой (как минимум, подключение стилей/скриптов, в идеале еще и сжатие, кэширование и тд).
    3. Разработчики ядра не поддерживают модули OAuth и Pagination - я бы их добавил.
    4. Наверное модуль Events
    5. Mailer (честно говоря, есть ли сейчас что-то актуальное, вроде когда-то Shadowhand писал такой модуль)
    6. ACL
    7. Nested Sets для ORM (Jelly?)
    8. Управление табличными данными
    9. Капча
    10. Возможно, какие-то специфичные (но популярные) модули для работы с API крупных сайтов: Paypal, Facebook и тд
  • мм.. Ко своему стыду, у меня с гитом не "на ты"... Есть опыт работы с:

    • mrclay/minify как модулем Kohana,
    • swiftmailer/swiftmailer - использовался просто и незамысловато, создать и отправить письмо
    • Капча (использовалась своя, простенькая)
    • ACL (своя реализация, с автоматизированной генерацией правил)

    По поводу кодогенерации тоже были мысли но дальше их не уходил.

    По поводу участия - за, но времени много не получится выделить, учусь в магистратуре + работа.. :)

  • Все мы занятые люди )) Я предполагаю, что многие смогут участвовать в разработке одного-двух модулей, которые наиболее актуальны для них.

    А с git'ом работать научим. Там несложно. Думаю, все равно придется набросать "джентельменский" набор соглашений для совместной работы.

  • Миграции нужны. Возможно, вот эти лучшие - https://github.com/OpenBuildings/timestamped-migrations

  • @biakaveron, уже учусь. Сейчас переношу проект из родного svn в новомодный git. Поставили gitlab, осваиваемся.. После svn/trac как-то непривычно...

  • С OAuth я бы остановился на написании модуля на основе hybridauth. Сейчас вот как-раз заканчиваю встраивать его в один проект, попутно кое-что под себя подправил.

    По Pagination - родной модуль ужасный. Предлагаю переписать/заменить.

    Events - есть 2 варианта, простой (https://github.com/BRMatt/Kohana-Dispatcher - я его часто юзаю) и "покруче" (наподобии http://laravel.com/docs/events). Надо обсудить.

    Mailer: лучше swiftmailer ничего не знаю (((. Можно на его основе сделать удобный модуль.

    В списке не хватает модуля управления пользователями (думаю, это часто нужно), со встроенным ACL и пр. Не хватает debugtoolbar. Не хватает модулей для баз данных (я бы с удовольствием поработал с NoSQL, c SimpleDB и пр.). Ну и т.д.

    Остальное, из списка, не использую. Вообще, правильнее взять популярные фреймворки и посмотреть их топы модулей. Вот, например: http://www.yiiframework.com/extensions/?sort=downloads.desc

  • С OAuth я бы остановился на написании модуля на основе hybridauth. Сейчас вот как-раз заканчиваю встраивать его в один проект, попутно кое-что под себя подправил.

    ИМХО, тут разные задачи. OAuth - протокол авторизации, а не аутентификации. То есть его задачей не является просто идентифицировать пользователя. Работа с API соцсетей - яркий пример тому, где OAuth может пригодиться. Это не значит, что hybridauth не заслуживает места в подборке, просто это разные задачи, причем OAuth является по сути драйвером - поставщиком данных, а Hybridauth - узкоспециализированным потребителем.

    По Pagination - родной модуль ужасный. Предлагаю переписать/заменить.

    Согласен.

    В списке не хватает модуля управления пользователями (думаю, это часто нужно), со встроенным ACL и пр.

    Не уверен, что можно создать достаточно гибкий модуль, который бы удовлетворил большинство пользователей. Хотя можно попробовать

    Не хватает модулей для баз данных (я бы с удовольствием поработал с NoSQL, c SimpleDB и пр.)

    Вопрос в актуальности, но в принципе ничего невозможного не вижу.

  • Сейчас занимаюсь кодогенератором для CRUD по БД. Верстка на bootstrap для админки должна быть в самый раз. Должно получится что-то на подобие Yii.

  • По возможности, скидывайте сюда ссылки на предлагаемые модули.

  • По поводу ACL.

    Кто-нибудь обращал внимание на shadowhand/bonafide? Весьма интересная вещь, на мой взгляд.

    Кто вообще какие реализации использует?

  • ИМХО, тут разные задачи.

    Значит будет 2 модуля: один для OAuth/OAuth2, второй - HybridAuth. Авторизация через соц.сети уже довольно частая задача. Раз уже планируем собирать полезные модули - надо уделить этому модулю внимание.

    Не уверен, что можно создать достаточно гибкий модуль, который бы удовлетворил большинство пользователей. Хотя можно попробовать

    А не надо сильно гибкий - будет только во вред! Наоборот - чем проще, тем лучше. Не так уж часто нужны специфичные задачи в подобных модулях. Общая задача - подключил модуль, добавил таблицу(ы) в базу и... все. После этого уже должно все работать, включая отображение форм и пр. А доработать - каждый для себя доработает ;)

    Вопрос в актуальности, но в принципе ничего невозможного не вижу.

    Актуально. Как NoSQL, так и замена стандартному Database.

  • Кто-нибудь обращал внимание на shadowhand/bonafide? Весьма интересная вещь, на мой взгляд. Кто вообще какие реализации использует?

    Вроде как A1/A2/Acl должен был его использовать, но не уверен. Вообще, Вуди планировал еще Acl к Bonafide прикрутить, но видимо заглохло все.

  • Вроде как A1/A2/Acl должен был его использовать, но не уверен. Вообще, Вуди планировал еще Acl к Bonafide прикрутить, но видимо заглохло все.

    А это и это что тогда?

  • Хм, значит уже прикрутил ))

  • Да-да, вот по этому что я и спросил. Весьма интересная библиотечка, на мой взгляд.

  • Для меня вот этот модуль полезным был. Может и не первоочередной, но потребность бывает. https://github.com/morgan/kohana-storage

    И я за NestedSets. Свои поделки и доделки существующих есть, но явно не для сообщества. Может вместе соберемся да допилим?

    Вы как зарегистрируете организацию на github скиньте поделитесь ссылкой, можно в личку. Присоединюсь, буду участвовать по мере возможности.

    PS А чем Pagination так плох? :-)

  • Для работы с монгой есть ORM-библиотека MangoDB - https://github.com/Wouterrr/MangoDB В целом оно работает и поддерживается автором, но синтаксис модели немного отличается от кохановского ORM. Можно будет попробовать привести его в соответствие.

  • Вот такое есть, сли кто не знал http://kohana-modules.com/

  • Ага, есть. Только вот у большинства модулей одна проблема - они редко являются актуальными для текущих версий фреймворка, обычно только для одной какой-то. Собственно, это одна из главных задач, которые я вижу.

  • https://github.com/NovickovSergey/kohana-nested-sets - как по мне, лучшая реализация под дефолтный ORM

    https://github.com/MrWEST/kohana-message - сообщения.

  • Еще возможно какой-нибудь для работы в Google API (есть вроде библиотека на php)

  • САБЖ отличная идея.

    По поводу того какие модули поддерживать, то мне больше всего не хватает обычно: 1. NestedSets ORM - Тут для меня лидер Jelly, но как стартую новый проект, то обычно приходится искать форки или пилить её до новой версии 2. Миграции БД без них очень грусно. 3. Часто не хватает модуля для работы со статикой, что бы можно было её вместе с модулями хранить и легко склеивать при деплое.

    Готов участвовать в поддержке и разработке(если таковая будет)

  • Идея нравится...из своего могу предложить модуль хлебных крошек:) не нашел нужного, писал сам, то документации нет, то еще что-то:)

  • По ассетам многообещающе выглядит https://github.com/kriswallsmith/assetic , правда, сыроват и требует допиливания для реализации записи отрендеренных less, sass и т.п. в файл. По дефолту там надо дергать контроллер, который отдает скомпонованные css и js, хоть и с кэшированием он это делает, но лишние две инициализации php на больших нагрузках будет заметны, мне кажется.

    Есть еще вот такая либа, которая аккумулирует в себе работу с кучей внешних API : http://eden.openovate.com/

    Может, запилить организацию на гитхабе и всем туда повступать ? Глядишь, потом и kohana-world родится, со второй попытки. :)

  • Ну, раз пошла такая пьянка... 1. Думаю, TheShock не будет против, если мы позаимствуем у него модуль NestedSets: https://github.com/aktuba/kohana-modules/tree/master/orm-mp 2. Вроде не плохой и простой модуль ACL: https://github.com/aktuba/kohana-deputy 3. Себе сам делал модуль для генерации sitemap, но вот есть функциональнее модуль: https://github.com/ThePixelDeveloper/kohana-sitemap

  • @slider23 это assetic то сыроват?!!!. Данный модуль используется по умолчанию как модуль управления статикой в Simfony. И чуть бы не с первых версий. Не думаю что Фабьен бы его использовал, если бы он был сыроват. Вообще отличный модуль.

    @nazarov, хорошая идея, кстати. У меня тоже есть своя реализация.

    С GAPI тоже работал - библиотека заброшена с 2009 года. Но работает.

  • @rex гуд ньюс, значит у меня руки кривые. Я с ним игрался немного, у меня изменения в less-файлах не обновляли кэш. Тогда его тоже можно взять за основу.

  • Кстати, композер, оказывается, может ставить модули фреймворков: https://github.com/composer/installers . Кохана поддерживается. Можно избранные модули оформить в packagist-е.

  • @slider23, я тоже играл немного и такой-же результат. На тот момент у него не самая лучшая дока была, или я просто не так понял :)

  • В качестве возможной альтернативы assetics'у предлагаю https://github.com/smgladkovskiy/kohana-static-files. Умеет сжимать, вытаскивать из модулей и тд. Его сейчас сопровождает форумчанин @avis.

    Кстати, есть идеи по поводу названия организации?

  • Как бы я не думаю что сильно стоит прямо заморачиваться с вылизыванием названия, по мне так главное чтобы содержало Kohana, было обозначено, что это сборка (модули) поддерживается сообществом (т.е. есть официальный пак). Я ведь правильно понимаю, что там будут вестись модули и периодически делаться сборки коханы с ними? Так, что первое в голову пришло.

    Kohana Bulk Kohana RePack Kohana Community Pack Kohana Community Modules

    Ну или комбинации выше предложенного.

  • @littfed

    Как по мне, сборка сама по себе не нужна. Хотя сделать возможность скачивания пакета из нужных модулей + соответствующая версия фреймворка = крутая фича. Только для этого нужен сайт, на сайте соответственно что-то размещать и тд.

    Сейчас хотя собрать разработчиков, определиться с модулями и причесать их до нужных кондиций для версий 3.2/3.3.

    Кстати, этот пак не может являться официальным, так как мы хоть и часть комьюнити, но официально что-то представлять могут только менеджеры фреймворка.

  • Начальный bootstrap-проект не помешал бы - с авторизацией, ассетами, пагинацией, twitter bootstrap и базовыми контроллерами типа этих - http://forum.kohanaframework.org/discussion/10412/postroenie-arhitektury-prilozheniya. Чтобы стартовать новый проект быстро.

  • Половина из перечисленных модулей предполагает что-то функционирующее, тогда уже простенькую демо-CMSку. Но, ИМХО, это все если и делать, то потом. Не стоит сразу пытаться реализовать все, что хочется. Надо работать поэтапно, и на данном этапе определиться с самыми необходимыми модулями.

    Как вариант, собрать список из всех возможных хотелок и организовать голосование. Я не вижу сейчас необходимости сопровождать сразу 10+ модулей. Надо сперва проверить себя на, скажем, пяти :)

  • Я не вижу сейчас необходимости сопровождать сразу 10+ модулей. Надо сперва проверить себя на, скажем, пяти :)

    Ну это ты зря... Правильнее, имхо, на каждого привлеченного разработчика повесить по 2-3 модуля. Это не много, но полезно для всех. 5-6 разработчиков = 10-18 модулей.

  • @biakaveron Да, конечно, он НЕ официальный будет, потерял я частицу, пока писал ) И да, конечно, для начала нужно взять хотя бы несколько модулей, привести в порядок и начать поддерживать. Про сборки я уже в перспективе говорил. План развития все равно должен быть какой-то.

    Давай уже регистрируй компанию в github и народ туда надо загонять )

    P.S. Если надо короткое название для гитхаб - KoMod ))

  • Пулю "KOHANKA" or "KOHANKO" :)

  • Как насчет Kohana-pack?

  • @ButscH

    Я думаю, имеет смысл создать отдельные проекты для "быстрого старта" и для демо-CMS. В "быстрый старт" включить что-то вроде общепринятых приемов (обработка ошибок, работа со статикой и тд).

    @aktuba Не нравится мне термин "повесить" :) Ладно, создадим все, что можно - а дальше будет видно по активности.

  • По мне так тоже не стоит слишком много брать модулей сразу. Начинать лучше с малого. И если хорошо пойдёт уже добирать модулей. По названию, Kohana-pack вполне нормальное название. И KoMod ничего.

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

  • Предлагаю обсудить для начала список модулей для голосования :)

    1. События (Events) - актуализация Events из Kohana v2 или портирование другого
    2. Пагинатор - актуализация оригинального Pagination или разработка нового
    3. Модуль для работы со статикой. Поиск по каскадной ФС, сжатие, кэширование и тд
    4. Кодогенератор
    5. Капча
    6. Почтовик
    7. ACL
    8. OAuth (вероятно, доработка существующего)
    9. Модуль аутентификации через OAuth (HybridAuth или что-то подобное)
    10. NestedSets. В первую очередь для штатного ORM.
    11. NoSQL
    12. Database (альтернатива стандартному). Правда, я не вижу особой актуальности.
    13. DebugToolbar
    14. Работа с сообщениями. Передача различного рода текстов (сообщения об ошибках и тд) между запросами.
    15. Миграции
    16. Библиотеки для работы с API: Google, Facebook, Twitter и тд.
    17. Работа с табличными данными
    18. Sitemap
    19. Набор для быстрого старта (типа tips&tricks)
    20. Демонстрационная CMS (базовые возможности, больше для ознакомления с фреймворком)

    Ничего не забыл?

  • Kohana-Pack - нормально и модули вроде все. Ну и если что, добавить всегда можно. Предлагаю префикс для названия модулей "kp" (kp-events, kp-pagination и т.д.)

  • События (Events) - актуализация Events из Kohana v2 или портирование другого

    Вроде удобно выглядит... Как это раньше никто не портировал?

    Пагинатор - актуализация оригинального Pagination или разработка нового

    Знаешь, подумал тут... Может все-таки имеет смысл довести до ума оригинальный модуль - по нему уже достаточно много документации, да и не сложный он (хотя местами не удобный).

    NestedSets. В первую очередь для штатного ORM.

    А тут личная просьба к тому, кто займется этим модулем: давайте делать на уровне драйверов к модулю. Ну не использую я ORM ))))

    Библиотеки для работы с API: Google, Facebook, Twitter и тд.

    Вот тут можно пойти по пути http://eden.openovate.com/, т.е. один модуль и куча драйверов для него. Должно быть удобно.

    Работа с табличными данными

    Расшифруйте кто-нибудь, что значит эта строка...

    По названию - я за Kohana-Pack. И да, давай уже организовывай все на гитхабе )

  • @ButscH Нет, у тебя CMS, а я про что-то типа http://forums.laravel.io/viewtopic.php?id=4099

    @littfed Имхо так делать нельзя, стандарт - перед названием модуля должно быть название фреймворка, чтобы поиском по гитхабу искалось нормально.

  • @slider23 В описании репозитория просто достаточно написать "A Kohana module for ..." и все прекрасно ищется. Но если это стандарт, который описан - я не против. Хотя смысл префикса "kp" это то, чтобы не было пересечений с существующими названиями модулей и указания на их общее происхождение.

  • @littfed, slider23 прав - в названии модуля обязательно должно присутствовать слово kohana, т.к. многие ищут только по репозиториям.

  • Ну и все же какое-то обозначение, что этот модуль поддерживается данной группой должно быть.

    Это позволит сразу в поиске видеть отличие kohana-pagination от kohana-pagination, который возможно совершенно по другому будет написан, а человек так и не догадается, что это не форк.

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

  • Можно и kp-kohana-pagination написать ) Если обязательно должно kohana присутствовать.

    @slider23 @aktuba А не могли бы вы ссылку, где эти правила описаны дать? Мне тогда бы стоило почитать стандарты подробнее, раз я не в курсе таких вещей )

    Просто я ориентировался на модули от Zombor ( https://github.com/zombor?tab=repositories ) и Shadowhand ( https://github.com/shadowhand?tab=repositories ) У них "kohana" в названии далеко не у всех модулей присутствует...

  • Можно и kp-kohana-pagination написать ) Если обязательно должно kohana присутствовать

    В таком случае думаю можно и слово pack добавить: kohana-pack-pagination

    Не сильно длинее, но уже не масло масленное =)

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion