Каким образом Сниппет должен понимать &limit?
Здравствуйте!
Пытаюсь сделать многостраничность со своей базой.
На выходе должна быть таблица с данными.
Создал компонент со своей базой, из которой нужно будет получать строки по запросу:
habrahabr.ru/post/126635/
Для начала, хочется понять принцип работы:
1. Как я понимаю, при помощи modx, нужно сделать sql запрос к базе, получить весь результат (?) и затем pdopage сам разделит эту кучу данных на несколько массивов, в количестве = количеству страниц. — сомнительно т.к. если база будет большая, процесс ведь затянется?
2. Или же запрос имеет параметр LIMIT OFFSET? (судя по статьям, так же не отличается скоростью выполнения)
Теперь, самое интересное. Подскажите пожалуйста, какие-нибудь статьи о том, как заставить Сниппет с запросом понимать этот злополучный параметр &limit?
Спрашиваю потому, что я видел разные примеры, ковырял разные исходники, того же самого вывода пользователей в up2, но так и не нашел в скриптах упоминания о limit и page. Может я что-то упустил?
Открыл userprofile2, попытался что-то сделать по аналогии, ничего не получилось. Далеко мне еще до понимания чужого кода. :(
Пытаюсь сделать многостраничность со своей базой.
На выходе должна быть таблица с данными.
Создал компонент со своей базой, из которой нужно будет получать строки по запросу:
habrahabr.ru/post/126635/
Для начала, хочется понять принцип работы:
1. Как я понимаю, при помощи modx, нужно сделать sql запрос к базе, получить весь результат (?) и затем pdopage сам разделит эту кучу данных на несколько массивов, в количестве = количеству страниц. — сомнительно т.к. если база будет большая, процесс ведь затянется?
2. Или же запрос имеет параметр LIMIT OFFSET? (судя по статьям, так же не отличается скоростью выполнения)
Теперь, самое интересное. Подскажите пожалуйста, какие-нибудь статьи о том, как заставить Сниппет с запросом понимать этот злополучный параметр &limit?
Спрашиваю потому, что я видел разные примеры, ковырял разные исходники, того же самого вывода пользователей в up2, но так и не нашел в скриптах упоминания о limit и page. Может я что-то упустил?
Открыл userprofile2, попытался что-то сделать по аналогии, ничего не получилось. Далеко мне еще до понимания чужого кода. :(
Комментарии: 24
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
— и, соответственно, если в вызове будут присутвовать свойства &a=`5` &b=`10` — они будут перекрывать их.
Что же конкретно до сниппетов pdoTools — у них есть как параметр &limit, так и параметр &offset.
Подводя итоги: если вы хотите при помощи своего сниппета реализовать выборку и вывести все через pdoTools, то вам нужно получить список ресурсов своим сниппетом и внутри него запустить pdoTools с параметром &resources. Как-то вот так:
И еще… Для запроса по таблице с ресурсами (класс modResource) можно напрямую вызвать сниппет pdoPage с параметрами limit и offset, потому как он автоматом вызывает сниппет pdoResources. Если нужны записи из какой-то другой таблицы, то в своем сниппете делаем запрос по нужной таблице, а сам сниппет передаем в pdoPage параметром element. И не надо изобретать никаких велосипедов.
limit для pdoPage = кол-во результатов на страницу.
limit для сниппета = ограничение кол-во результатов, которые нужно разбить на страницы. (Пример: ТОП-100 популярных ресурсов, выводимых по 10 на страницу.)
Что же до element — через api, думаю, выйдет быстрее, да и не придется городить массу переменных непосредственно в вызове pdoPage.
Согласен. Мне показалось, что там один и тот же лимит.
Какая масса переменных? pdoResources вызывается по умолчанию. Т.е. все только упрощается. Если запрос по своей табличке, то передаешь только сниппет через element.
Что же до велосипеда… Ну, в целом — да, ваша правда.
Но в рамках pdoResources (при всех его преимуществах с позиции скорости и удобовводимости данных): на мой взгляд, говорить, что кто-то уже придумал запросы к базе данных и, поэтому, любые собственные запросы к бд — велосипед, это — перебор..)
Моя ошибка в том, что я считал что передавать нужно обычный массив со значениями. Что затем, pdoPage подставит значения в нужный чанк, где это нужно. Ведь это быстрее? Чем загружать уйму лишнего HTML кода? Это мне казалось логичным, т.к. нечто подобное видел в прочих сниппетах, аля регистрация и т.д.
В действительности же, нужно передавать массив, состоящий из чанков заполненными данными. Какой же у меня был фейспалм… Я снова заблуждаюсь?
Вопрос. Из-за Ajax передачи значений переменных сниппету, думаю, что желательно запускать pdoPage прямо внутри сниппета. Такое возможно?
По поводу ajaxa — делаю нечто похожее тут, можно запускать где-то внизу страницы сниппет с условием:
— и отправлять аякс-запрос на ту же страницу, где вы и находитесь. После чего скриптами вставлять результат в нужное место.
Подробнее — тут (основы).
Когда писал этот топик совсем отчаялся сделать красиво с pdo. И поэтому решил забить на него, и практически разобрался со своим же кодом. Пагинация работает. Осталось продумать алгоритм для вывода страниц like pdoPage.
Простите, за потраченное время. То, что «почти получилось», на деле отказалось работать, видимо я снова что-то упустил. Уже нет сил плавать в чем-то непонятном. И схватиться не за что. Читал про pdoTools на docs.modx.pro/, но так ине понял как это работает. Видимо читатель должен знать какие-то основы, которые я даже не знаю как гуглить. Надо взять в привычку изучать ВСЮ документацию, вероятно тогда и проблем не будет. ;)
Но если интересно, то вот мой быдлокод, приятного чтива xD):
Ссылка на страницу
Ресурс «Все объявления»:
Сниппет «result_tables_new_all», который используется на разных страницах, с немного разными данными:
Чанк «result_table_items» данные таблицы:
Чанк «result_table_items_wrap» заголовок таблицы + фильтры:
Что реализовано:
1. Пользователь выбирает из mysql таблицы предмет любого типа, и выставляет его на покупку либо продажу.
2. Данные с id пользователя, id-предмета, его характеристиками (они могут быть разные, скажем уровень раскачки предмета) и ценой идут в таблицу buy либо sell.
3. Допустим 100 пользователей закинуло в эти базы свои заявки, по 20-30 заявок каждый. Итого 2000-3000 заявок.
Что обернуть в pdoTools:
4. Показ сразу всех заявок на странице «Все заявки». На данный момент, я ограничил запрос к выборке buy и sell до 30, иначе, загружается слишком много данных на одну страницу. Настолько, что страница махом отжирает 200мб оперативки, и пользоваться сайтом становится проблематично.
Поэтому нужна многостраничность, т.е. нужен постраничный вывод строк таблицы.
PS:
Почти закончил решение без pdoTools, аля костыль, но понимаю что это не дело. Опробовав однажды запрос по модели, почувствовал такооое облегчение.
как-то так:
И в самом конце сниппета, перед return добавить строчку:
Перед тем, как задействовать pdoPage меняю:
на
и вывожу не
а
Иначе ведь, pdoPage не поймет как нужно разделить цельный html код на страницы?
Линк: warframe.trade/testpages.html
Наверное откажусь от аякса, это не рентабельно + геморно. По крайней мере сделать Get на этой же странице, кажется гораздо проще.
Значит при выводе данных, странички будут с линком на ресурс который был вызван.
т.е. при переходе на другую страницу, я автоматом получу страницу с данными но без шаблона. :D