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
  • @littfed правило эти негласное, конечно, но очень многие модули для других фреймворков содержат в своем названии название фреймворка. Если поискать в гитхабе yii, fuel, laravel и т.д. это хорошо видно.

  • ИМХО, в качестве названия вполне достаточно и просто pagination. Ну а в случае с форком существующих модулей (а такие скорее всего будут) вообще стоит использовать то имя, что уже есть.

    И да, давай уже организовывай все на гитхабе )

    Дык надо сперва придумать, что туда внутри пихать.

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

    А что там может быть удобного? Для Твиттера требуется одно, для ФБ/ВК - другое, для Пейпала третье. Kohana от 2.3.4 к 3.3.0 шла по пути облегчения ядра и выноса всего необязательного в отдельные модули, чтобы не заставлять пользователя держать "на борту" лишнее. Так зачем строить монстра, когда можно создать отдельные модули для каждого провайдера? Максимум - сделать один общий проект (ядро) и несколько отдельных модулей с драйверами (Гугл, ФБ и тд).

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

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

    Имею в виду что-то вроде виджета для отображения табличных данных. Дал ему на вход массив - он показывает таблицу. Что-то вроде http://kohana.keyframesandcode.com/docs/modules/table/

  • А что там может быть удобного? Для Твиттера требуется одно, для ФБ/ВК - другое, для Пейпала третье.

    В абсолютном большинстве случаев, нужна только основа (отправка запросов, обработка исключений и пр.). Все остальное через указание методов API. Т.е., примерно так:

    $twitter = new Social('twitter', $key, $secret);
    if ($twitter->auth())
    {
        $twitter->get('search/tweets', array('q'=>'kohana'));
    }
    
    $facebook = new Social('facebook', $key, $secret);
    if ($facebook->auth())
    {
        $facebook->post(NULL, array('message'=>$message));
    }
    
    $lastfm = new Social('lastfm', $key, $secret);
    if ($lastfm->auth())
    {
        $artist = $lastfm->get('artist.getInfo', array('artist'=>'Rihanna', 'autocorrect'=>TRUE));
    }
    

    Не более того. Не усложняет интерфейс, но удобно и просто.

    Имею в виду что-то вроде виджета для отображения табличных данных.

    Тогда я настаиваю, чтобы любой модуль, который хоть что-то делает по интерфейсу, использовал twitter bootstrap! Во-первых, что практично и удобно. Во-вторых - для большинства привычно.

    P.S.: но вообще, я против модуля для таблиц. Уж слишком глобальный модуль получится, если пытаться предусмотреть все. Если только вывод и пагинацию - слишком ущербный.

  • @aktuba

    В абсолютном большинстве случаев, нужна только основа (отправка запросов, обработка исключений и пр.). Все остальное через указание методов API.

    Как-то все очень просто в твоем примере )) Как минимум, авторизация идет в несколько этапов, с редиректами, подтверждениями и тд. Плюс, еще нужно учитывать всяческие scopes для доступа к различным ресурсам на чтение/редактирование. Это в общем-то самая сложная часть. Обычные OAuth-запросы легко осуществляются с помощью соответствующего модуля OAuth, остается только распарсить ответы.

    Тогда я настаиваю, чтобы любой модуль, который хоть что-то делает по интерфейсу, использовал twitter bootstrap! Во-первых, что практично и удобно. Во-вторых - для большинства привычно.

    С этим полностью согласен.

    P.S.: но вообще, я против модуля для таблиц. Уж слишком глобальный модуль получится, если пытаться предусмотреть все. Если только вывод и пагинацию - слишком ущербный.

    Сам никогда такими не пользовался :) На всякий случай включу в голосование, а там уж как народ воспримет

  • Как-то все очень просто в твоем примере ))

    Так и должно быть - минималистичность рулит )))

    Как минимум, авторизация идет в несколько этапов, с редиректами, подтверждениями и тд.

    Это обрабатывает конкретный драйвер (т.к. заранее нельзя предсказать редиректы и пр.). HybridAuth показателен, в данном случае.

    Плюс, еще нужно учитывать всяческие scopes для доступа к различным ресурсам на чтение/редактирование.

    Конфиги для чего придуманы? ) Можно вот так, например:

    $facebook = new Social('facebook', $key, $secret, array('scope'=>'email'));
    if ($facebook->auth())
    {
        $facebook->post(NULL, array('message'=>$message));
    }
    
    Обычные OAuth-запросы легко осуществляются с помощью соответствующего модуля OAuth, остается только распарсить ответы.

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

  • Это обрабатывает конкретный драйвер (т.к. заранее нельзя предсказать редиректы и пр.). HybridAuth показателен, в данном случае.

    Скатываемся в оффтоп, на самом деле, но я не могу молчать :) После $facebook->auth() последует редирект на страницу ФБ для подтверждения. Соответственно дальше выполняться ничего не будет. Либо я чего-то не знаю (например, тут не пахнет OAuth, зато есть какая-то родная библиотека, которая выполнит пару cUrl-запросов безо всякого шума).

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

    В общем, твои мысли я понял, возможно ты и прав.

  • После $facebook->auth() последует редирект на страницу ФБ для подтверждения. Соответственно дальше выполняться ничего не будет.

    Но после-то вернется ;). Задача всего-лишь сохранить промежуточный статус и продолжить после авторизации. Чем мой пример кардинально отличается от HybridAuth?:

    $provider = UTF8::ucfirst($provider);
    try
    {
        $hybridauth = new Hybrid_Auth(Kohana::$config->load('hybridauth')->as_array());
        $adapter = $hybridauth->authenticate($provider);
        if ($adapter->isUserConnected())
        {
            $user = $adapter->getUserProfile()->as_array();
            if (!empty($user['identifier']))
            {
                if ($this->_auth($user, $provider))
                {
                    Notify::success(Kohana::message('oauth', 'success'));
                    $this->redirect(Route::url('profile').'/');
                }
                else
                {
                    Notify::error(Kohana::message('oauth', 'error.auth'));
                }
            }
            else
            {
                Notify::error(Kohana::message('oauth', 'error.missing'));
                $adapter->logout();
            }
        }
        else
        {
            Notify::error(Kohana::message('oauth', 'error.error'));
        }
    }
    catch(Hybrid_Exception $e)
    {
    ...
    

    Тут дело реализации, хотя может я не всю картину вижу, конечно...

  • Со списком определились? Нужно разбить роли и продумать что будем делать с модулями онли сапорт или развитие. Если развитие надо тогда как нить все договориться в скайпе обсудить. Так что б найти усреднений вектор развития.

  • Может опять конференцию в джаббере зафигачить?

  • А тем, кто не пользуется джаббером - что делать? (

  • Ну как бы со скайпом такая же фигня )) Кроме того, со скайпом вроде как такие постоянные чаты не сделать (могу ошибаться). А джаббер-чаты сейчас практически во всех аськах есть.

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

  • Накопал только инфу https://support.skype.com/ru/faq/FA860/cto-takoe-publicnye-caty?frompage=search&amp;q=публичный+чат&amp;fromSearchFirstPage=false, по которой вроде как эта функция упразднена. Не нашел в своем клиенте возможности создать публичный чат и получить ссылку на него.

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

  • В скайпе есть инструменты управления чатами, можно назначать модераторов, и назначать администратора. Самое не удобное что нужно именно руками добавлять в него людей. http://habrahabr.ru/post/97561/

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

  • IRC уже не модно?

  • Блин, проблему такую устроили ) Может проще форум у кого-то на хостинге из присутствующих поднять? )

  • Вот для этого чатег и нужен - то, что на форуме выглядит флудом на 20 страниц, в чатике - обсуждение рядового рабочего момента.

  • можно и ирц, можно джабер, можно что угодно и скайп можно))) кстати ИРКа будет лучше ;)

    И только не надо что "ой, а я не могу" и т.п. все люди взрослые раз РНР осилили любой клиент ИРКи нам поставить не сложно :) Пилите канал где и оф. канал кохани ток аля кохана_рус или тип. того.

  • Создал [email protected] Посмотрим, попробуем - не понравится, значит на что-то другое перейдем. А то мы еще неделю будем чаты обсуждать

  • Отлично. Значит так. В пятницу-развратницу в 13_00 по Мск собераемся в конфе. Кто не будет но хочет просьба отписать почему и когда будет удобней. Я думаю всех сможем убедить "насальников" дать 30 минут может час для полезного дела :)

  • Нужно будет опеределиться с:

    1. Кто будет мейнтейнером

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

    3. Для тех модулей что есть уже, и которие юзабельни написать мануали :)

    Вообщем орг. моменти епт :)

  • Кто не будет но хочет просьба отписать почему и когда будет удобней.

    Я не буду (((. Ну нету у меня ни аськи, ни джаббера. Есть только скайп и почта (.

    Кто будет мейнтейнером

    Как кто? @biakaveron. Он единственный (да ведь?!) из нас состоит в мемберах коханы на гитхабе (https://github.com/kohana?tab=members)

  • @aktuba а поставить так сложно.... на много сложней чем изучить рнр, кохану.... у меня тоже не било еще утром)))

  • @yan_kos, издеваешься? Я год как снес. И ставить совсем не хочется ((( Найду что-нибудь браузерное - появлюсь, нет - так нет.

  • Если ничего не поменяется, то буду. Я там Ramka.

  • На всякий случай напоминаю - до совещания в конференции осталось полчаса. Занимайте места заранее ))

  • Можно результат сюда кинуть, а то интересно, а поприсутствовать нет возможности

  • Так скажет кто-то, тема заглохла? )

  • Привет, нет не заглохла.

    https://github.com/organizations/kohana-pack

    Модулей пока 4 решили их допилить до актуальных версий (3.2 и 3.3)

    Распределение людей по модулям я увы не помню, думаю что кто-нибудь попозже отпишет по этому поводу. Обсуждение технических деталей относительно модулей будет уже на github происходить.

    Как-то так сейчас дела обстоят =)

  • у меня Notify + Assets

  • Модули и их управляющие:

    • Assets (управление статическими файлами - стили, скрипты, картинки) - @yan_kos
    • Notify (межзапросная передача данных, обычно через сессии) - видимо @yan_kos
    • Pagination - @kion
    • Events - @aktuba и @biakaveron
    • Debug-Toolbar (я его и так сопровождаю, поэтому пока просто форк).

    Управляющий имеет право на push, понятное дело pull request доступен всем. Любой может поучаствовать в развитии понравившегося модуля через обсуждения или предлагая свои наработки путем open issue + pull request.

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

  • Класс, буду заниматься обкаткой модулей в своей системе :)

  • А как найти ветку, а то по ссылке иду, а меня на главную кидает.

  • У меня есть сильное желание запилить модуль миграций и поддерживать его.

    Думаю что с нуля писать смысла нет, лучше выбрать нормальную реализацию и её поддерживать. Пока я остановился на https://github.com/Fedott/timestamped-migrations, я её чуть изменил, добавил поиск миграций по всем модулям, а не только в директории application. В целом реализация рабочая.

    Есть у кого мысли какую реализацию лучше посмотреть и взять на поддержку?

  • У меня есть модуль генерации форм, с поддержкой драйверов, пока только html, в перспективе буду писать драйвер под sencha. Пробовал сделать все компонентно, портировать из VCL. Правда там альфа, но вполне рабочая. Кому-то будет такое интересно,выложу?

    $form = new TForm();
            $form->action = $this->url();
            $form->label = 'Калькулятор';
            $select = new TSelect($form);
            $select->label = 'Откуда';
            $select->name('from');
            $select = new TSelect($form);
            $select->label = 'Куда';
            $select->name('to');
            $component = new TTextbox($form);
            $component->label = 'Вес (кг)';
            $component->name('weight');
            $component = new TTextbox($form);
            $component->label = 'Ширина (см)';
            $component->name('width');
            $component = new TTextbox($form);
            $component->label = 'Высота (см)';
            $component->name('height');
            $component = new TTextbox($form);
            $component->label = 'Длинна (см)';
            $component->name('length');
            $component = new TSubmitButton($form);
            $component->label = 'Подсчитать';
            return $form;
    

    Вот так выглядит форма, Скрин

  • А в чем преимущества-то?

    PS. Не понял, почему форма передается в компоненты, а не наоборот. Должно же быть что-то вроде $form->attach($component);

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

    new TComponent(TComponent $owner=null)

    , хотя это обертка, вот конструктор

    public function __construct(TComponent $owner = null)
        {
            if ($owner != null)
            {
                $owner->insert_component($this);
            }
        }
    

    Таким образом можно писать

    $form->insert_component($component)
  • Думаю что с нуля писать смысла нет, лучше выбрать нормальную реализацию и её поддерживать. Пока я остановился на https://github.com/Fedott/timestamped-migrations, я её чуть изменил, добавил поиск миграций по всем модулям, а не только в директории application. В целом реализация рабочая.

    Решил попробовать на kohana 3.3, делаю php minion db:migrate --help , получаю ERROR: Task 'Task_Db_Migrate' is not a valid minion task У оригинального скрипта то же самое.

  • Оно пока не поддерживает 3.3. Только 3.2

  • Хорошую тему подняли. Давно пора

  • Ой молодцы!!! Очень пригодился бы CRUD =) Может есть у кого опыт использования готового решения? Удобно?

  • Это, а когда будет че тестировать?

  • @ButscH, скоро ))). Что-то в процессе...

  • @biakaveron, форкни в организацию https://github.com/OpenBuildings/timestamped-migrations , это действительно наиболее перспективные миграции из тех, что есть, автор более-менее активен, я сделал конвертацию на 3.3, будем с Fedot его допиливать.

  • Сделано, вы с @Fedot управляющие ))

  • Отлично. Я влил все наши с @slider23 изменения. Будем теперь там дорабатывать.

    Желательно только веточку по умолчанию поменять, а то у меня на это прав не хватает.

  • Пока что сделал 3.3./develop, когда будет 3.3/master, переключу на нее.

Howdy, Stranger!

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

In this Discussion