Multy Tags-Archive размышления, приведшие к текущей реализации

Это не то чтобы сложно, всего-то:

• добавить возможность приема второго массива в "ОБРАБОТЧИК ДЛЯ РЕЖИМА СОХРАНЕНИЯ СТРАНИЦЫ"
• добавить параметр в phMultyTargetsOutput
• изменить название массива в EditForm

Но целесообразность неочевидна, поэтому отложено.

Тут есть два варианта:

1. либо при нажатии кнопки связанные страницы отменять "липучесть", при повторном - возвращать, то есть просто тогглить класс ph-stickerer у ID=ph-stickerer по нажатию этой кнопки
2. либо внедрить вот этот плагин: https://silviomoreto.github.io/bootstrap-select/examples/
   • Плагин выглядит вроде симпатично, но у него есть существенный минус. В текущей реализации, если станиц в группе мало, они сразу все перед глазами, не надо тыкать выпадающие списки.

Итого: решено через bootstrap-multiselect.js

Цель: багфикс phFieldProcessing-multytags.php

• JS-код, который расставляет теги, ошибочен: он ищет наличие текста в строке. Однако таким образом он пометит страницу Xyz.Abc И Xyz.Abcd , а это неправильно. Поправить надо здесь и на Мемофильме.
  • взять версию с Астромифа + этот JS-код должен генериться только в режиме редактирования!
• остальной код надо взять из phph-field-processing.php (localhost:8888)
• баг нашел: пустые списки не сохраняются

Цель: стать универсальным, разместить поля с выбором тегов в правой колонке

• добавить новую вкладку в editMode.tmpl
• эта вкладка должна содержать отдельную страницу FieldProcessing-multytags-pagelists (?), где будут размещены дефолтные pagelist's и их шаблоны. Надо подумать над размещением. В отличие от SitemapsPack тут шаблоны, которые наверняка будут правиться в других Wiki. И их вызовы тоже будут правиться поэтому, это все должно быть на отдельной странице, а не вшито в editMode.tmpl.
  • появляется понимание, что шаблоны вызовов таких pagelist'ов должны быть в ThisSite.Config

Цель: давать возможность настроить имя поля, в котором хранить теги
Надо создать новую переменную в ThisSite.Config, например FieldProcessingMultytags.

Если FieldProcessingMultytags = tagrets, то EditForm создает input с name = phTags2Targets и мультитегами
Если FieldProcessingMultytags = multytags, то EditForm создает input с name = phTags2Multytags и мультитегами , а также создает скрытый input с name = phTags2Targets и значением "none".

phFieldProcessing-multytags.php:
Если получено phTags2Targets и оно не "none", то действуем как сейчас. Если none, то ничего не делаем.
Если получено phTags2Multytags, то делаем новый обработчик, который пишет не в поле targets, а в поле Multytags

В функцию phphTargetsFormat() добавляем параметр "целевое поле для обработки". В Config надо будет написать, что если поле меняется от дефолтного, то надо переопределить массивы PV.

Цель: давать возможность выводить значение поля с сортировкой по алфавиту ИЛИ незнамо как
В функцию phphTargetsFormat() добавляем параметр "имя callback-функции для сортировки".

Если передан, то сортируем массив linksMassive через http://php.net/manual/ru/function.usort.php
Если нет, то сортируем по алфавиту.
Если передано none, то никак не сортируем.

Следующие возможности уже реализованы:

• в Wiki-формате или в html
• исключать ссылки на определенную группу
  • я бы переделал это в массив
• выцеплять ссылки ТОЛЬКО на определенную группу
  • я бы переделал это в массив

Общий итог:
В Мастере определяются $FmtPV по-умолчанию: все подряд, с сортировкой по алфавиту, генерятся просто обычные ссылки.

На локальной Wiki их можно переопределить или расширить:

• изменить метод сортировки собственной функцией
• изменить имя обрабатываемого поля
• сформировать html-код ИЛИ wiki-код
• сформировать html-код по собственному шаблону для каждого элемента, к примеру добавив окружающий li вокруг ссылок
• выцепить ИЛИ исключить из обработки любой массив групп

• настройки режима редактирования: переделать таб в "Связанные Страницы"
• макет дизайна: если существуют "Связанные Страницы", то выполнять wiki-код, взятый из соседнего поля настроек
• wiki-код Связанных Страниц: делать "pagelist связанных страниц"
• pagelist-шаблон: смотрим значение "Связанные Страницы" из Настроек Режима Редактирования, генерить select'ы указав это значение в качестве имени селекта. Возможные значения
  • FieldProcessingMultytags = tagrets ИЛИ multytags

• форма редактирования: добавить вывод поля PV $targets И, если настройки "Связанные Страницы" = multytags, multytags
• форма редактирования: если существует настройка "Связанные Страницы", то надо выполнить JS-код, который:
  • расставит уже существующие теги из multytags (если существует) или targets по селектам внутри Таба "Связанные Страницы"
  • перед отправкой формы надо сериализовать значения из Таба "Связанные Страницы" и всунуть их в общий массив отправляемых данных
• phph-field-processing.php : научается различать приход targets и multytags и, соответственно, писать в то или иное поле

• phph-field-processing.php -> phphTargetsFormat должна уметь:
  • удалять лишние значения из поля targets
  • оставлять выбранные значения
  • сортировать результат по алфавиту, callback-функцию или никак
  • форматировать результат в виде html, wiki или текста

Короче, проще ее переписать, судя по всему.

Теперь вызываем: phFieldProcessing-multytags.php один раз в родительской вики.
В дочерних вики лишь определяются необходимые $FmtPV.

Принятые решения:
Отказались, потому что слишком муторно (надо перенести в todo в конце):

• от переноса селектов в правую часть
• от разработки ветви, которая пишет теги в отдельное поле

Осталось:

• все-таки добавить возможность кастомизировать pagelist по настройкам режима редактирования (по аналогии с sitemap). По той причине, что у всех разные группы
• отрефакторить функционал записи. На каждой странице должно быть три варианта действий:
  • использовать текущие Связанные Страницы (по-умолчанию)
    • если ни одна не выбрана, то случается последующий пункт
  • проставить Связанные Страницы автоматом движком pmwiki (перепрыгивает на предыдущий вариант при повторном редактировании)
  • занулить поле (сохраняется и восстанавливается при повторном редактировании )
• надо придумать механизм, по которому вся эта история будет применяться только к выбранным Группам. Ну, или наоборот, выбранные Группы будут исключаться.
• переписать функцию phphTargetsFormat:
  • удалять лишние значения из поля targets
  • оставлять выбранные значения
  • сортировать результат по алфавиту, callback-функцию или никак
  • форматировать результат в виде html, wiki или текста
• решить проблему с отображением связанных страниц при большом количестве групп
• задокументировать вынос $FmtPV из рецепта и написать примеры его реализации

Под вопросом:

• перенести css-код из http://master.pmwiki.ru/ThisSite/EditForm в phMultytags.php
  • с одной стороны вроде там ему самое место, с другой стороны снижается масштабируемость.

Сделано:

• настройки Условий и Выборки вынесены в настройки Режима Редактирования
  • теперь можно выключить функционал для любой Группы, Страницы
• отказались от идеи "занулятеля". Либо теги выбраны руками (причем хотя бы один), либо работает движок PmWiki. Все, нет вариантов, что поле вообще пустое, так как это сильно усложняет реализацию и, главное, может привести к сложнопредсказуемым последствиям по мере развития сайта.
  • если почему-либо на данной конкретной странице/группе нужно показывать теги не так, как везде, это надо решать другими методами, например через разметку макета дизайна или специальной PTV переменной
• переписать функцию phphTargetsFormat:
  • удалять лишние значения из поля targets
  • оставлять выбранные значения
  • сортировать результат по алфавиту, callback-функцию или никак
  • форматировать результат в виде html, wiki или текста

Осталось:

• решить проблему с отображением связанных страниц при большом количестве групп
• задокументировать вынос $FmtPV из рецепта и написать примеры его реализации
• написать документацию