vorst.ru - web-programming



КОММЕНТАРИИ

«These pieces really set a standard in the indyutrs» «And I thought I was the sensible one. Thanks for...» «All of my questions se-eltdtthanks!» «I do trust all of the ideas you have introduced...»

Вы пока еще не просмотрели ни одного поста.


Плагин для агентств недвижимости

как получить результат, ничего не меняя

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

Чтобы разобраться, как это возможно, я решил написать плагин для агенств недвижимости. Расширять структуру данных не хотелось - это уже будет не WordPress. Решил сохранять JSON-определения объектов недвижимости в поле post_content и преобразовывать эти определения "на лету" - Demo, GitHub


Как получить данные из amoCRM.ru

все о сделках в форме CSV-таблицы

Заказчик попросил вывести данные о сделках в таблицу в формате CSV. Данные должны быть максимально полными.

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

Ну и прочее - кто, когда, с кем, контакты клиента и, наконец, все комментарии к сделке.


Как определить событие

пример события

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

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


Чтение без перезагрузки страницы

динамическая загрузка контента

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


Если читатель хочет вспомнить

что просмотрено и прочитано

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


Как добавить новый атрибут загруженному файлу

можно добавить описание как и любой другой атрибут тоже

Иногда важно определить дополнительную информацию для загружаемого файла. Например это может быть описание. В расширении yii2-byone-uploader возможность добавить описание к файлу уже предусмотрена.

Кроме описания может быть добавлено и любое другое свойство. В предыдущем примере использовалось свойство when типа radio с двумя значениями - "до" и "после". Как добавить новое свойство?


Галерея До & После

фотографии, загруженные до и после момента времени

Представьте, что вы продаете курс похудания. Вам нужно наглядно представить результат вашего курса. Фото "До" и "После", что может быть лучшей иллюстрацией?

Как и в предыдущем примере примем, что участников ограниченное количество. Например 4. Забудем про похудающих - слишком скучно. Будем "работать" с кинозвездами. Для каждого можно загрузить только 4 фотографии. Таким образом всего 16 фото. Если загружены все 16 и кому-то захочется добавить "свои" фото, то придется что-то удалить. Демо.


Загрузка изображений

делаем демо

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

Например, можно устроить, что-то вроде надписи в столовой - "Уберите, пожалуйста, за собой посуду" (демо).


Проверка модальной формы

редактирование без перезагрузки

Бывает, что количество полей в таблице не слишком велико и редактировать в модальном окне проще и нагляднее. Что необходимо, чтобы организовать стандартный набор операций - CReate, Update, Delete?


Расширение для доступа к таблицам Google

Yii2 & Google REST API

В предыдущей статье уже была ссылка на работающий пример.

Следующим шагом стало выделение процесса аутентификации на сервисе Google в отдельный класс. А это, в свою очередь, позволило сделать расширение, немного упрощающее решение задачи.


Доступ к таблицам Google из приложения

что такое OAuth2

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

Доступ к таблицам разрешен только вам и тем, кому вы предоставите такое право. Причем доступ возможен не только из Google.

Можно просматривать список таблиц и редактировать выбранную таблицу оставаясь в рамках своего приложения. Примерно так - http://sample.vorst.ru/googl

Для этого разработано Google Sheets API, доступное в двух вариантах - клиентская библиотека и REST API.


Сайт на двух языках

переводим контент

Для перевода интерфейса в Yii применяется таблица из двух колонок. В первой колонке записываются слова или фразы на английском, во второй - перевод на русском. Строки отсортированы по первой колонке. В тексте программы вместо нужного слова или фразы вызывается функция t('Word or Phrase'). Если текущий язык сайта английский, функция возвращает параметр, иначе соответствующий перевод.

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


Виджет для рубрик

выбор всех статей по рубрике

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

Первая из них - необходимо добавить поле rubric в таблицу post. С этой операцией связано и изменения в модели common/models/Post, которые очевидно касаются методов rules() и attributeLabels().

Кроме этого нужно добавить обработку выбранной пользователем рубрики в actionIndex() контроллера frontend/controllers/PostController.


Контроллер для рубрикатора

элементарные, но достаточные действия над деревом Nested Set

Все необходимые методы, для управления деревом Nested Set уже определены в расширении.

Поэтому изменения в стандартном контроллере совсем небольшие. Нужно, например, вместо стандартного метода save() модели использовать метод prependTo() расширения, а вместо delete(), deleteWithChildren().

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

Но, по порядку.


Представление для ввода новой рубрики

редактирование, удаление узлов в дереве Nested Set

Мы, в общих чертах, разобрались с деревьями Nested Set и создали модель для хранения дерева. В модели определили пару простых методов.

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

Для добавления рубрики нужно определить, в какую родительскую рубрику будет входить новая рубрика. Этой цели служит поле $parent_node модели.

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


Подключение расширения Nested Set

модель для рубрикатора

Мы получили общее представление о древовидной структуре данных называемой Nested Set. Теперь пришло время подключить к блогу соответствующее расширение выполненное в виде поведения.

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

Наши задачи проще и сводятся к следующему:

  1. Управление рубрикатором - добавление и удаление рубрик, редактирование, отображение списка рубрик для визуального контроля.
  2. Закрепление статьи за рубрикой.
  3. Вывод списка рубрик для выбора нужной рубрики.

Для их решения, как обычно, нужна модель, контроллер, представления и еще виджет.


Вложенные множества для организации рубрикатора

как устроена структура данных Nested Set

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

Поэтому, давайте делать рубрикатор.

У нас есть рубрики записанные в правой колонке:

id lft rgt level name
1 1 12 1 Root
2 2 5 2 --- Data structures
3 3 4 3 ------ Nested Set
4 6 9 2 --- Searching
5 7 8 3 ------ Posts chains
6 10 11 2 --- About sites

И нужна структура данных, которая помогла бы нам:

  1. Выводить список в заданном порядке.
  2. Делать отступ при выводе названия рубрик.
  3. Находить все под-рубрики выбранной рубрики, чтобы выводить соответствующие статьи.

Предыдущие и следующие статьи

какую статью выбрать следующей или предыдущей?

В предыдущей статье речь шла о несколько необычном подходе к организации контента в блоге. Суть его в том, что не обязательно все мысли излагать в одной статье, можно это делать постепенно от статьи к статье. В промежутках рассуждая о других вещах и размещая статьи по другим темам.

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

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

Но есть одно "но".


Можно ли сделать блог удобнее?

цепочки статей, объединенных одной темой

Ну, во-первых, удобнее по отношению к чему?

К WordPress, например. Некоторое время назад я использовал эту программу для ведения блога.

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

Но, в одну рубрику могут входить статьи, посвященные разным темам. Да и с метками та-же неопределенность.

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

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

Можно ли улучшить положение?


Этапы развития сайта

следуют за развитием компании

Сначала о компании. Выделим, условно конечно же, три этапа.

В начале сотрудников не много, как и клиентов. Возникающие вопросы легко решаются. Они вас не раздражают, наоборот, вы их ждете с нетерпением.

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

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

А что же сайт?