«В прошлых сериях» члены сообщества высказывались о том, что API в МОДх недоработанное и стоило бы разработчикам уделить по-более внимания в это направление.
Соответственно давайте попытаемся обстоятельно обсудить и найти решения или сформировать пакет предложений для тех самых разработчиков с конкретно необходимыми функциями.
Небольшая вводная подборка:
Официальная информация по API (на англ. языке)
→
DocumentParser ($modx) (все API для работы с документом)
→
DBAPI (все API для работы с БД)
НЕофициальная информация
→
Русскоязычное описание АПИ функций с этого сайта
Это для того, чтобы все имели перед собой список и описание АПИ функций имеющихся на данный момент в «стандартной поставке».
Для начала, наверно, предлагаю начать излагать свои мысли
«каких АПИ функций вам не хватает при работе с МОДх ?». И соответственно все вместе обсуждать так уж эта функция нужна (учитывая, что она должна быть до определённой меры обобщённой).
Безусловно с чего стоит начать — это отсутствие нормальных АПИ функций для CRUD операций над документами (Create, Read, Update, Delete) за исключением Read — походу стандартные АПИ только это и реализуют (и то не хватает функции массового считывания доков с их ТВ параметрами).
По поводу CRUD сообщество уже немного подсуетилось. После небольших поисков нашлось два класса
Существующие расширения API
→
CakeMODx
→
Docmanager
Работа с Docmanager описана немного на этом сайте по связке его с Eform, но кажется данный класс уже давно не имеет активного развтия и поддержки.
А вот CakeMODx написал тот самый AHHP, автор JoCo и прочих расширений для MODx в не столь далёком прошлом и похоже продолжает активно развивать. По крайне мере список функций весьма хорош и, думаю, я начну этим пользоваться при необходимости.
Далее перейдём к «хотелкам». Моя первая хотелка, как я когда-то упоминал — это функция, которую я бы назвал getDocumentChildrenWithTVs.
Список API-«хотелок»
→
getDocumentChildrenWithTVs — функция полный аналог по возможностям к существующей фунции getDocumentChildren, но соответственно с выводом всех указанных ТВ. С такой функцией бы отпала необходимость в Дитто во множестве случаев.
Итак, Дамы и Господа, ваши мысли, предложения, мечты…? :)
Функции «хотелки» обоснованные в обсуждении буду прикреплять в список здесь.
По результатам обсуждения можно попробовать узнать мнение разработчиков на счёт включения/разработки некоторого набора доп. АПИ в стандартную поставку. А может быть кто-то даже реализует что-нибудь из этого списка прямо сейчас :)
Комментарии (17)
RSS свернуть / развернутьсистема работы с документами: создание, удаление, обновление
система работы с кешем, не просто удаление, но удаление кеша для одного документа, обновление кэша для одного или группы документов и т.п. вот это я считаю важным, потому как не гоже при изменении информации на сайте регенерировать весь сайт заново, неправильно это.
grinant
Про АПИ для авторизации и работе с юзерами — по идее это немного реализовано в CakeMODx. (Но наверно стоит составить список предполагаемых функций, которые бы хотелось впринципи).
iJack
теперь про кэш. Меня как пользователя системы, по идее ну никак не должно волновать внутреннее устройство, для этого API и реализуется, чтобы отгородить меня от рутиных задач, и вывести программирование на новый уровень абстракции. Согласитесь, когда я, как пользователь системы, знаю что и где и как хранится, и без этих знания мне никуда — это не есть гуд. А то что система кэширования она такая, а никакая друга — ну тут уж вопросы не ко мне. Я мыслю вслух относительно текущей MODx, а не гипотетической MODxCE.
grinant
Я говорил о том, что уже несколько раз обсуждалось, что частичное «ручное» обновление кэша (создание указанных АПИ функций ) — это не выход.
iJack
Но гипотетически именно об этом и стоит мечтать, чтобы мы меняли один документ и обновлялся только нужный кеш. В том числе если мы динамически создаем документ.
Но вообще тут скорее надо мечтать о том, чтобы вопросом кеша полностью занимался сам MODx всегда, то есть думал за нас когда его нужно чистить и где.
Carw
это нереально… только программист знает где ему кеш нужен а где нет. система может лишь обновить кэш в одном месте или удалить его в другом… потом только программист знает насколько актуальные данные хранятся в кэше, и соотвественно MODx может очищать кэш при утрате актуальности, но система не способна определить как и когда данные должны быть актуальны — это есть и будет всегда дело рук программиста.
grinant
Соответственно вопрос возникает простой — в каком случае нам нужно самими управлять кешем документов?
Carw
grinant
Хотя такое периодическое кеширование действительно имеет огромный смысл при огромной нагрузке, но когда кешируется полная страница и выдается сразу без вызова php. Так как это совсем иная история, то мы ее не касаемся.
В нашем же случае ситуация выглядит достаточно просто — кеш должен меняться тогда, когда обновились данные. Желательно при этом добавить еще и задачу, что кеш меняется только тот, который нужно менять.
Мне очень сложно придумать пример где страницу надо делать не кешируемой. Есть такой на примете?
Carw
я думаю что стоит заострять внимание не на кэшировании страницы как таковой, т.к. на это есть отдельные решения, а на кеширование блоков данных, а именно вызовов сниппетов, т.к. большинство процессорного времени используется там. С другой стороны, такие фишки MODx как плагины, которые цепляются непосредственно на вывод документа (например Phx), и работающие регулярными выражениями по тексту HTML-страницы значительно замедляют работу системы. Думаю в этом плане хорош опыт Smarty, когда шаблон компилируется в исходник PHP и тот уже работает со скоростью интерпретатора, а не когда мы каждый раз парсим один и тот же документ на предмет наличия сущностей PHx-плагина.
grinant
1 тип, скажем так, системное кеширование. Оно занимается кешированием документов, кешируемых книппетов, результатов работы плагинов, чанков и т.д.
Я именно про эту часть вел речь. Здесь правила четкие и можно добиться их умной работы. Программисту здесь копаться не нужно.
2 тип, скажем так, кеширование для разработчика (чего сейчас нет). Оно может использоваться для хранения промежуточных результатов работы сниппета / модуля / плагина, что тоже может значительно ускорить работу.
Так вот я не говорил выше о 2 типе. Но я упомянул в своем комменте о кешировании промежуточных данных и считаю его тоже очень важным. Разумеется его должны контролировать программисты.
Что касается Смарти, но это вопрос очень отдельный. Для начала нужно вообще доказать, что его подход дает существенное преимущество, а не будет экономией на спичках. И на сколько возможен такой подход в MODx.
Carw
сниппету не надо это знать, но судя по наблюдениям. кэшь сбрасывается на страницах везде где есть измененный сниппет (т.е. система сама следит за этим, каким образом хз — не разбирался)
grinant
Очень просто — кеш сбрасывается весь полностью. Пусть даже есть миллион документов на сайте, кеш сбросится для всего миллиона :-)
Carw
Работа с документами
— создание / редактирование (в том числе разных параметров) / перенос / удаление
Работа с группами пользователей
— создание / редактирование / удаление
— добавление / удаление пользователей в группу
— добавление / удаление документов в группу
Работа с пользователями
— создание / редактирование / удаление
— авторизация
— разлогинивание
Работа с пользовательскими данными
— хранение / изменение / удаление пользовательской временной информации (например корзина товара)
Работа с чанками
— создание / изменение / удаление (хотя это не часто требуется)
Кеширование промежуточных данных (хранение обычных пар ключ — значение)
— установить / удалить значение
PS: Разумеется все это хочется в родном АПИ, а не в сторонних библиотеках.
Carw
По крайне мере про CakeMODx Jason Coward сказал Надо будет на днях поковыряться по серьзнее в Рево, посмотреть как оно там.
iJack
Indra
Кроме того, я надеюсь, что ветка Evo будет жить еще достаточно долго :-)
Carw
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.