ну это да :) боты ведь - это всего-навсего межсерверное взаимодействие, и на чём оно будет - хоть на javascript, пофиг (про js как таковой я загнул, но вот на node точно всё будет круто)

Есть ещё один хардкорный вариант - - юзать tg-cli)

Но там надо будет юзать какой-то аккаунт

Так первых ботов делали

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

но что-то меня в этом всём смущает

что-то здесь точно не так :)

Ну, давайте тогда подождём на ответ уважаемого

глубину просмотра сообщения объясните простому человеку - что это? как это? для чего это?

Я думаю, что человек имеет в виду, как далеко пользователь отмотал ленту вверх

коряво видимо выразился, количество просмотров у каждого поста(цифра которая около глаза у каждого сообшения)

возможно я ошибаюсь, но в документации нигде не написано как это сделать значит, наверняка, это невозможно (или, как выше Дмитрий писал, пробовать через cli)

Да в доках такого не было. Cli это имеется ввиду авторизироваться пользователем конкретным и уже от пользователя делать запросы ?

Да

Но там намного сложнее, чем с обычными ботами

тоже смотрел доки но подобного метода не нашел, это все таки возможно через cli?

Ну, если вы где-то такой каунтер засекли, то где-то он есть

А через tg-cli все очень низкоуровнево

Там может быть

@eugenesmit а где вы такой каунтер соскринили?

я об этом

в каналах

В канале

любой пост, который отправляется в канал, получает такой каунтер

(эта песня - из канала, скинул ради демки каунтера)

та же песня, но уже не из канала - уже без каунтера

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

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

*боты

А есть готовый cli на yii2?

может я ошибаюсь, но cli - это command line interface клиент то есть, не визуально оформленный, а через консоль

может я ошибаюсь, но cli - это command line interface клиент то есть, не визуально оформленный, а через консоль

Вы правы, это еще одна реализация клиента для tg, но через консоль

А есть готовый cli на yii2?

у вас мания искать все что связано с yii2?

проще на php в общем искать

вот, святой Хабр

https://habrahabr.ru/post/264301/

https://github.com/zyberspace/php-telegram-cli-client

Проект на yii2, не хотелось бы отступать но на решение на php тоже не беда, спасибо.

объясните, пожалуйста, как вы совместите бота и веб-сайт?

через composer сделайте require того, что выше, и будет вам php-telegram-cli-client в yii2

объясните, пожалуйста, как вы совместите бота и веб-сайт?

возможно, человек берёт из yii2 как и я - только мелкие фрагменты

не проще делать два проекта?

есть бот -- как сервис

и к нему по rpc или через какой-то таск брокет связь с сайтом

german, celery, rabbitmq и тд

По поводу второго проекта хорошая идея, тоже думал сделать как отдельное api

а чем вам не подходит?

Где лучше создать папку виджета ?

серьезно? :)

Ну я имею ввиду не важно в какой папке?

web

А как с бд работать? можно для этого использовать класс модели, где есть подключение к бд?

я же вам отправил ссылку на докуменатацию вам не хватило усилий дойти к статье о виджетах?

я же вам отправил ссылку на докуменатацию вам не хватило усилий дойти к статье о виджетах?

Я читал) я просто сверяю правильность понимания

Без практики нечего сверять )

Делайте

Пробуйте

Пробуйте

Смотри у меня есть модель категории и модель статьи, соответствено в них прописаны релейшены, если я хочу показать все статьи одной категории, мне в какой модели вызывать findAll()?

Релейшены(отношения)

Опять я с вопросами (со вчерашним, если кто помнит, не пересекается почти). До последнего абзаца можно не читать, тут размышления с ответами себе же. Была на сайте форма оплаты. Ну то есть во-первых две формы (одна у себя обрабатывается, другая на яндекс-кассу ведёт, в зависимости от способа оплаты). Во-вторых экшн, который рисует модальное окно с этими формами и результат одной из них обрабатывает (ещё один контроллер с ответами яндекс-кассы работает). А теперь форму оплаты включили в интерфейс одной из многоступенчатых форм заказа. Ну то есть есть четыре шага, первые три заполнили, результат отправили, сгенерили какой-то итог + форму оплаты, показали в качестве четвёртого шага. При этом старое окошко оплаты тоже осталось (для других пользовательских сценариев). В итоге имеем: * В составе двух вьюшек копипасту общего куска кода; * Некоторую копипасту в составе двух экшнов двух разных контроллеров; * Ещё какое-то барахло; С копипастой во вьюшках всё просто - выношу в виджет, вставляю его где надо. Но остаётся копипаста в контроллерах. Будь это разные экшны одного контроллера, я бы вынес это в приватный метод и успокоился. С другой стороны что это за код? Ну во-первых это обработка платежей (не тех вчерашних, а других) и решить её можно точно так-же: запилить компонент. А во-вторых это получение данных из запроса и всякие проверки, которые сложно уложить в валидацию моделей (например есть несколько типов платежей, часть обрабатывается в одном контроллере, часть в другом и "перепутать" их недопустимо). Т.е. сугубо контроллерная тема. В итоге, что мне остаётся не понятно: как кошерно избавляться от деблирования сугубо контроллерного кода в двух разных контроллерах? Код включает в себя: * Получение данных из запроса; * Проверки с выбрасыванием исключений; * Одно-два условия, влияющего на обращения к сервисному слою; * Передачу данных во вьюшку; Это вообще как-то адекватно решается или обычно на это забивают и фигачат контроллеры копипастой с последующим допиливанием?

О, и с разу ещё вопрос: У меня получается два очень похожих компонента с очень похожим смыслом и реализацией. Это оплата подписки и оплата услуг. Стоит ли их делать двумя разными компонентами (с _почти_ одинаковым интерфейсом) или одним компонентом с префиксами у этих почти одинаковых методов?

делайте один интерфейс, может еще что-то добавится к проекту

ERROR: S client not available

но два компонента

что-то общее можете перенести в один класс

"Но остаётся копипаста в контроллерах." можете делать класс на основе Action

если это вам подходит

делайте один интерфейс, может еще что-то добавится к проекту

Тут некоторая проблема в том, что интерфейс всётаки разный. Но я подумаю, может быть можно придумать такой, чтобы был общий и в то же время без странностей в виде методов принимающих ассоциативные массивы в роли сишных структур.

"Но остаётся копипаста в контроллерах." можете делать класс на основе Action

В смысле компонент будет сам контроллером и будет иметь собственные экшны?

компонент -- не контроллер

контроллер -- отдельно, экшын -- отдельно, ну и компонент -- отдельно

логику ни к чему деражать в контроллере

То есть запилить для платежей отдельный контроллер, отдельный компонент. (Что есть экшн в данном контексте не понял, я думал что это собственно метод контроллера)

Можно выносить код экшынов в отдельные классы

http://www.yiiframework.com/doc-2.0/yii-web-erroraction.html

Вот пример

Смотри у меня есть модель категории и модель статьи, соответствено в них прописаны релейшены, если я хочу показать все статьи одной категории, мне в какой модели вызывать findAll()?

релейшены в AR Yii2 подразумевают, что у тебя объект AR уже заполнен данными из БД и может получить эти релейшены. Бесполезно вызывать релейшены у нового объекта (new Category())->articles ни к чему не приведет

SiZE не рекомендую тратить на это время Человек в упор не желает читать доки

=)))

=)))

это не смешно, это грустно

скорее надо так =(((((

Я это пишу не просто так, поверьте

да я помню что он вчера писал )

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

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

Чёрт, у меня тут Чёрная Дыра Рефакторинга ? В смысле чем больше привожу ооп в порядок, тем больше всплывает того, что нужно ещё привести. Тем временем для начальства это всё выглядит так, что вот тот крутой фрилансер всё очень оперативно сделал, а мне осталось чуть-чуть, но я копаюсь тут целую вечность ?

беги от туда где заказчик говорит - тут пару часов или тут немного сделать, как правило это обман с целью сбить стоимость

вот как слышишь от заказчика эти слова сразу знай - ушлый

потому что простой заказчик не может знать чо тут сделать и на сколько это долго

а если все так просто и на пару часов - пусть сам и делает раз такой умный

сорян, блинчики надо делать) потом прочитаю

Да я тут уже 3 года работаю. Уже понял, что тут центральная обязанность сотрудника перед самим собой объяснять начальству свои заслуги, иначе их никто не поймёт, а вот причиной всех косяков окажешься. Но я оооочень не люблю говорить "вот Вася тут вот так и так накосячил", поэтому просто беру и пилю чтобы было хорошо. Как итог - я тут самый тормозной программист, который только и занимается исправлением каких-то косяков (видимо исключительно собственных).

Вдвойне неловко указывать что исправляю говнокод специалиста, чья ставка часовая х2 от моей)

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