Понимаю, что по большему счету можно просто написать JS скриптик, который в дереве на node будет классы вешать, которые выпадающий список вернут. Но как это правильно делается на ExtJS понятия не имею, а криво писать нет желания абсолютно никакого.
Кстати на счет перезаписи при обновлении. Столкнулся с проектом в котором пришлось в стандартном классе msProduct поменять поле $allowChildResource с false на true, чтобы в дереве ресурсов у него можно было создавать дочерние ресурсы. При обновлении этот момент может слететь. Василий не подскажете, как этого избежать?
Подскажите пожалуйста как вывести изображения ресурса
На всякий случай еще раз:
… Ресурса...
Через pdoResources такое сделать можно, конечно, но в чем смысл? Тем более сразу видно, что вы с pdoResources еще не имеете достаточного опыта работы. По сути же стоит вопрос, чтобы в ручную запрос к БД через него составить. А это значит, что нужно для начала указать, что пляшем мы не от таблицы ресурсов, а от таблицы в которой хранится инфа о файлах, а условие с id ресурса в WHERE указать.
Не понял, что имелось ввиду под словом «размер» :-) но в любом случае повторяю: календарь просто упрощает ввод и делает нагляднее вывод переменных с датами. Ожидать от него, что он вам поможет более, чем указывать дату начала и конца, не бессмысленно. В вашем случае нужно:
1) в папке минишопа перейти в model/minishop2 и там найти файл msProduct.class.php и в нем заменить $allowChildResources с false на true, чтобы иметь возможность создавать дочерние ресурсы у товаров.
2) нужно создать кастомный класс от modResource и у него нормально переписать метод checkPolicy(), который в своём результате выдаёт разркшение на просмотр («view») ресурса у пользователя.
3)Создать новую таблицу, где будут храниться даты с которых можно смотреть пользователя прошлый ресурс + ID пользователя и самого ресурса.
Каким образом интересно? Вам не кажется, что функционал ограничения доступа пользователей сайта к ресурсам и их возможностям не имеет никакого отношения к вышеописанному календарю, по большей степени являющимся не более чем графическим интерфейсом? То есть средство для более удобной работы с вещами завязанных на датах?
Написана чушь, если честно. Достаточно было в !msProducts указать parents='0' и тогда бы никаких условий не было бы с родителями. Как следствие достаточно было одного вызова Сниппета без pdoResources. Далее у вас написано, что limit=0. Зачем выводить за раз сотни превьюшек? Нужно было в pdoPage все это дело обернуть + включить AJAX подгрузку при скроллинге. Да и сортировать по menuindex плохая идея, т.к. результаты с разных уровней и разных родителей и поэтому может быть, что menuindex со значением 1 может оказаться сразу у 7 ресурсов. По-моему просто по алфавиту через заголовок нужно сортировать или более сложные варианты.
Написать то не проблема, проблема в другом:
1) Мой рейтинг менее 25 и, честно говоря, мне не хочется про подобные вещи писать в разделе вопросов или т.п. Тема, хоть объемная и сложная, но вытворять позволяет интересную штуки:-) да и альтернатив я не так уж и много видел.
2) Материал про ограничения прав на работу с конкретным ресурсом конкретному пользователю очень сложный. Я более чем уверен, что именно на данную тему проще действительно какое-то дополнение выпустить, т.к. подобные материалы единицы просто хотя бы до конца дочитают.
3) Я не являюсь мастером слога. Я думаю, что даже если и напишу подобный материал, то понятен он будет только мне самому. Формулировка мысли таким образом, чтобы она была доступна и понятно большинству — это не моё, поверь. Собственно, это и есть основная причина. Я не хочу, чтобы ценностью подобного материала было только его наличие. Более того, я мситпю, что вреда будет даже больше: много кого только напугаю мудрёностью темы и вообще отобью от желания заниматься подобным:-)
Касательно последних материалов Николая я не знаю. Точно знаю, что ранее он много написал про сложные моменты в работе со стандартными классами и тп. Собственно поэтому и привёл в пример. Все таки раз было столько до этого про узость в плане достаточного уровня навыков у аудитории, то и решил о ком-то написать, кто про подобного уровня темы писал. Почему-то мне никто больше в голову не пришёл. Тот же Василий писал, по-моему все таки для людей с прилично более низким уровнем, по поводу базовых методов и классов…
Так я и не спорю. Пускай такие вопросы и задаются в соответствующем разделе. Другой вопрос, что мне не очень нравится то, что на главной абсолютное большинство публикаций банальная реклама дополнений от их авторов. Я ничего не имею против, но взять того же Николая Ланца. Чего-чего, но у него было (правда на его ресурсе) достаточно много интересных статей именно про xPDO и прочую основу-основ. Лично бы я с удовольствием почитал про безопасность и варианты того, как можно ограничивать доступ к конкретному ресурсу на фронте у конкретных пользователей (не групп или т.п., а именно ресурса с определённым ID для определённого пользователя). Осоюенно интересно, про Реализацию этого через два класса: первый наследующий класс modAccessResource, а второй наследующий класс modResource с переписанным под первый checkPrivacy(). так можно хоть по абсолютно разным датам давать доступ вообще для всех бзеров:-) или индивидуальное расписание показа и тд
Ну или про те же контроллеры и ExtJS почитал бы…
Все просто достаточно, действительно. Глянь тут: docs.modx.pro/components/minishop2/development/plug-ins-products
Тут расписано про то, как расширить таблицу продуктов, но ничто не мешает точно также расширить таблицу заказов и\или адресов. Просто вместо msProductData пиши msOrderAddress.
Если через xPDO $order->toArray() — получим значения свойств объекта, а $order->toArray(false, false, true) — построит дерево из значений объекта и значений вообще всех загруженных и связанных с ним объектов. В последнем методе вместо true можно указать цифру, которая будет показывать глубину дерева.
Если чистым php, то get_class_vars($order) — все свойства класса (но будет очень жёсткий результат :-) ), get_class_methods($order) — все методы класса.
Если головой, то посмотреть schema minishop'а и исходники классов.
Ну, как минимум скорость загрузки страницы, т.к. JS добавит ссылки на изображения и начнёт их грузить уже после того, как будет загружена страница. На тяжелых галереях или слайдерах самое оно. Плюс в слайдерах можно реализовать не просто подгрузку обычной/ретина версии, но и разрешение картинки под экран. Следовательно для экранов 1366х768 не будут грузиться под 1920х1080 картинкт, что может прилично съэкономить скорость готовности страницы
Тег picture обработают, но как div, а srcset, проигнорируют, да. Кстати на счёт АЯКСа было сказано, что вариант на JS не отрабатывает… Это почему? Что мешает повесить на событие успеха выполнения запроса выполнение скрипта для замены картинок на ретине?
Лучше просто прогнать через специальные сервисы, вроде www.fontsquirrel.com/tools/webfont-generator
В итоге иконки будут в форматах, которые значительно легче, чем SVG, вроде WOFF2, т.к. в них не храненится значения для векторов в плоскости Z и т.д.
Давно я такого не видел :-) Но в таком случае есть маленькая проблема:
Вариант 1: Мы выставляем в src ссылки на картинки с вдвое большим разрешением. Это не айс, т.к. получается, что людям с обычным экраном нужно грузить прилично более тяжелые картинки
Вариант 2: Мы ставим обычные картинки, тогда людям с ретиной придется загружать обе версии картинок, т.к. браузеру по фиг на JS и он сначала загрузит обычные версии, а потом JS вместо них воткнет Retina версии.
Вариант 3: Использовать , но тут вопрос в поддержке браузерами.
На всякий случай еще раз:
Через pdoResources такое сделать можно, конечно, но в чем смысл? Тем более сразу видно, что вы с pdoResources еще не имеете достаточного опыта работы. По сути же стоит вопрос, чтобы в ручную запрос к БД через него составить. А это значит, что нужно для начала указать, что пляшем мы не от таблицы ресурсов, а от таблицы в которой хранится инфа о файлах, а условие с id ресурса в WHERE указать.
1) в папке минишопа перейти в model/minishop2 и там найти файл msProduct.class.php и в нем заменить $allowChildResources с false на true, чтобы иметь возможность создавать дочерние ресурсы у товаров.
2) нужно создать кастомный класс от modResource и у него нормально переписать метод checkPolicy(), который в своём результате выдаёт разркшение на просмотр («view») ресурса у пользователя.
3)Создать новую таблицу, где будут храниться даты с которых можно смотреть пользователя прошлый ресурс + ID пользователя и самого ресурса.
и т.д.
P.S. Интересно будет взглянуть, как реализовано подобное. Особенно в плане работы со словами-исключениями или пришедшими из других языков.
1) Мой рейтинг менее 25 и, честно говоря, мне не хочется про подобные вещи писать в разделе вопросов или т.п. Тема, хоть объемная и сложная, но вытворять позволяет интересную штуки:-) да и альтернатив я не так уж и много видел.
2) Материал про ограничения прав на работу с конкретным ресурсом конкретному пользователю очень сложный. Я более чем уверен, что именно на данную тему проще действительно какое-то дополнение выпустить, т.к. подобные материалы единицы просто хотя бы до конца дочитают.
3) Я не являюсь мастером слога. Я думаю, что даже если и напишу подобный материал, то понятен он будет только мне самому. Формулировка мысли таким образом, чтобы она была доступна и понятно большинству — это не моё, поверь. Собственно, это и есть основная причина. Я не хочу, чтобы ценностью подобного материала было только его наличие. Более того, я мситпю, что вреда будет даже больше: много кого только напугаю мудрёностью темы и вообще отобью от желания заниматься подобным:-)
Касательно последних материалов Николая я не знаю. Точно знаю, что ранее он много написал про сложные моменты в работе со стандартными классами и тп. Собственно поэтому и привёл в пример. Все таки раз было столько до этого про узость в плане достаточного уровня навыков у аудитории, то и решил о ком-то написать, кто про подобного уровня темы писал. Почему-то мне никто больше в голову не пришёл. Тот же Василий писал, по-моему все таки для людей с прилично более низким уровнем, по поводу базовых методов и классов…
Ну или про те же контроллеры и ExtJS почитал бы…
P.S. А что сейчас на главной?
docs.modx.pro/components/minishop2/development/plug-ins-products
Тут расписано про то, как расширить таблицу продуктов, но ничто не мешает точно также расширить таблицу заказов и\или адресов. Просто вместо msProductData пиши msOrderAddress.
Если чистым php, то get_class_vars($order) — все свойства класса (но будет очень жёсткий результат :-) ), get_class_methods($order) — все методы класса.
Если головой, то посмотреть schema minishop'а и исходники классов.
В итоге иконки будут в форматах, которые значительно легче, чем SVG, вроде WOFF2, т.к. в них не храненится значения для векторов в плоскости Z и т.д.
Вариант 1: Мы выставляем в src ссылки на картинки с вдвое большим разрешением. Это не айс, т.к. получается, что людям с обычным экраном нужно грузить прилично более тяжелые картинки
Вариант 2: Мы ставим обычные картинки, тогда людям с ретиной придется загружать обе версии картинок, т.к. браузеру по фиг на JS и он сначала загрузит обычные версии, а потом JS вместо них воткнет Retina версии.
Вариант 3: Использовать , но тут вопрос в поддержке браузерами.