А в чем смысл where в данном случае? У вас таблицы джойнятся по этому же условию.
ЗЫ: Вот препарированый запрос, но вроде все нормально
Как раз запрос-то и неправильный. В данном случае, в инстукции WHERE справа должна быть скалярная величина. А если вы хотите связать поля 2-х таблиц (т.е. тот же джойн), то уберите JOIN, а в FROM добавьте эту вторую таблицу.
Вообще, думаю, там следует учинять ровно такую же проверку, как и в коде сниппета.
Какой смысл дублировать код? Все манипуляции с правами вынесены в сниппет. Там, в зависимости от требуемых условий, выставляется флаг readOnly. А в классе просто должен проверяться этот флаг. В новой версии это дело поправлено.
1. При установке опции &allowGuestEdit=`0` вроде все гуд — гости смотрят, админы редактируют и добавляют. Но только админ не может удалить событие. Всплывает окно с предупреждением, а далее сообщение, что редактирование запрещено.
Есть такое дело. Логику с правами вынес в сниппет, а в классе забыл подправить это дело. Исправление будет доступно в новой версии. А пока можно самому поправить в файле core/components/mycalendar/model/mycalendar/mycalendar.class.php (строка 406)
if ($this->config['readOnly'])
2. Помогите подружить его с гугл-календарем!
По инструкции должно быть 3 шага:
1. Получить API Google календаря.
2. Создать доступный всем (public) google календарь.
3. Получить его ID. Он должен выглядеть как-то так abcd1234@group.calendar.google.com.
API Google календаря прописать в системных настройках, а ID календаря в параметре &googleCalendars сниппета. Если все сделано правильно, то должно работать.
Календарь ru.russian#holiday@group.v.calendar.google.com является общим календарем с праздниками, у Вас он тоже должен работать.
Не совсем понимаю о чем речь. Через ajax можно запускать и свой сниппет и pdoPage и сниппет в сниппете. Ограничений нет. Просто я не до конца понимаю контекст вопроса.
1. Как я понимаю, при помощи modx, нужно сделать sql запрос к базе, получить весь результат (?) и затем pdopage сам разделит эту кучу данных на несколько массивов, в количестве = количеству страниц. — сомнительно т.к. если база будет большая, процесс ведь затянется?
Ничего не затянется. Тут тысячи записей и все работает быстро.
… вы правда считаете чистый запрос на api — велосипедом?)
Интересная интерпретация. Т.е. если придумывать то, что уже придумано, на чистом api, то это уже не велосипед. Прикольно.
limit для pdoPage = кол-во результатов на страницу.
limit для сниппета = ограничение кол-во результатов, которые нужно разбить на страницы. (Пример: ТОП-100 популярных ресурсов, выводимых по 10 на страницу.)
Согласен. Мне показалось, что там один и тот же лимит.
Что же до element — через api, думаю, выйдет быстрее, да и не придется городить массу переменных непосредственно в вызове pdoPage.
Какая масса переменных? pdoResources вызывается по умолчанию. Т.е. все только упрощается. Если запрос по своей табличке, то передаешь только сниппет через element.
В данном примере пагинации не будет. Чтобы она была, в первой части не нужно запрос ограничивать лимитом. Лимит нужен для pdoPage.
И еще… Для запроса по таблице с ресурсами (класс modResource) можно напрямую вызвать сниппет pdoPage с параметрами limit и offset, потому как он автоматом вызывает сниппет pdoResources. Если нужны записи из какой-то другой таблицы, то в своем сниппете делаем запрос по нужной таблице, а сам сниппет передаем в pdoPage параметром element. И не надо изобретать никаких велосипедов.
Мне тоже больше нравится вариант с minishop. Работы меньше, а возможностей больше. Просто интересно мнение с той стороны, т.е. пользователей. Поэтому к вам и обратился.
Уже достаю minishop из коробки. Но боюсь, за выходные вряд ли сумею найти место, куда вставляются батарейки.
Михаил, вопрос по онлайн-оплате. Вы вроде как в теме.
Я правильно понимаю, что при использовании miniShop там будет всего один товар — бронь? В связи с чем вопрос — целесообразно ли заставлять пользователя (например, отели) устанавливать такой мощный магазин ради одного товара?
Как раз запрос-то и неправильный. В данном случае, в инстукции WHERE справа должна быть скалярная величина. А если вы хотите связать поля 2-х таблиц (т.е. тот же джойн), то уберите JOIN, а в FROM добавьте эту вторую таблицу.
По инструкции должно быть 3 шага:
1. Получить API Google календаря.
2. Создать доступный всем (public) google календарь.
3. Получить его ID. Он должен выглядеть как-то так abcd1234@group.calendar.google.com.
API Google календаря прописать в системных настройках, а ID календаря в параметре &googleCalendars сниппета. Если все сделано правильно, то должно работать.
Календарь ru.russian#holiday@group.v.calendar.google.com является общим календарем с праздниками, у Вас он тоже должен работать.
Версия 1.0.0-pl, а не бета.
П.С. А когда Леонид вернется?
Согласен. Мне показалось, что там один и тот же лимит.
Какая масса переменных? pdoResources вызывается по умолчанию. Т.е. все только упрощается. Если запрос по своей табличке, то передаешь только сниппет через element.
И еще… Для запроса по таблице с ресурсами (класс modResource) можно напрямую вызвать сниппет pdoPage с параметрами limit и offset, потому как он автоматом вызывает сниппет pdoResources. Если нужны записи из какой-то другой таблицы, то в своем сниппете делаем запрос по нужной таблице, а сам сниппет передаем в pdoPage параметром element. И не надо изобретать никаких велосипедов.
Уже достаю minishop из коробки. Но боюсь, за выходные вряд ли сумею найти место, куда вставляются батарейки.
Выбор будет между oneBooking с одним, двумя методами оплаты или oneBooking + miniShop2 с большим набором дополнений к нему.
Я правильно понимаю, что при использовании miniShop там будет всего один товар — бронь? В связи с чем вопрос — целесообразно ли заставлять пользователя (например, отели) устанавливать такой мощный магазин ради одного товара?