alexx
Th0r
Хорошо что не в Австралию - там бы пришлось вверх ногами ходить
Pavel
Вчера был разговор про хранение элементов в файлах. Я хотел уточнить - а вот снипеты в админке же нужно создавать в любом случае? даже если хочешь, чтобы они лежали в файлах. Наумкин пишет, что снипет должен иметь запись в таблице.
Миша
Нет не нужно
Миша
Ничего в админке не надо кроме шаблона и в инклюдить
Миша
В нем
Pavel
Нет не нужно
получается Наумкин ошибался? Но он утверждает, что снипет - это потомок класса modSnippet со всеми возможностями и а файл не имеет такой функционал.
Pavel
Pavel
Миша
Эм, это плохо?
Миша
Вот про кэширование, файл то и кэшировать не надо
Pavel
Эм, это плохо?
вот я и хочу докапаться до истины. Он утверждает, что такие снипеты, которые не имеют записи в БЖ имеют ряд ограничений, например их нельзя использовать в качестве модификаторов
Миша
Возможно, я что то не проверил
Миша
Хотя нет
Миша
Работает
Миша
Могу даже живой пример показать
Миша
Работает 100%
Михаил
Василий все верно говорит
Михаил
Сниппет в полном его проявлении -обязательно объект в БД
Михаил
Если у тебя "сниппет" в файле без записи в БД - это не сниппет в нотации MODX. Если такое встречается, pdoTools на лету через newObject('modSnippet') создает сниппет, заполняет его содержимым из файла и выполняет.
Михаил
Но параметры по умолчанию, стандартные механизмы кэширования и многие другие плюшки таким "сниппетам" недоступны
Миша
Ну в кэше толку нет
Миша
А вот другие это печально
Миша
Особенно параметры
Pavel
Михаил
Да
Pavel
а чанки можно создавать в файлах без создания в конфигурации?
Михаил
Ведь в БД будет запись, на которую смогут ссылаться параметры, наборы параметров и т.д.
Михаил
В какой конфигурации?
Pavel
В какой конфигурации?
в админке. извиняюсь. термины 1с случайно вырвались. там админка называется конфигуратором )
Михаил
Для чанков тоже доступны параметры по умолчанию, кэширование и прочее
Михаил
Все механизмы для чанков, сниппетов, шаблонов и плагинов максимально похожи, тк они являются наследниками одного класса modElement
Миша
Хотя мне не пригодилось при написании, может и норм
Pavel
надо для себя глубоко погружаться в англоязычную документаци. Чтобы получить полное понимание ядра modx. Тем, кто начали заниматься modx раньше нас - в начале 2010-ых им больше повезло. Уроков и доков на русском еще небыло и они были вынуждены переводить доку и изучать ее. А те, кто сейчас начинают изучать modx - их избаловало наличие любительских уроков и статей блога, где не всегда раскрывается полностью правильно вся суть. Как результат - у старичков знания глубже ) Лично я теперь не успокоюсь пока всю доку не пропущу через себя.
Михаил
Паш, я официальную доку практически не читал по причине английского языка
Михаил
Не надо все переводить в плоскость "Кто раньше начал, тот больше знает".
Миша
В блогах практически нигде не ковыряют юдро
Михаил
Я глубоко работаю с MODX всего лишь около 3-х лет.
Миша
Кроме openmodx, ilyaut,bezumkin
who are you
доку читать не обязательно, достаточно файлы изнутри посмотреть чтобы понять что к чему 😊 я думаю старички так называемые так и делали
Михаил
Все зависит от задач и только от них.
Михаил
Если ты клепаешь шаблонные блоги и интернет-магазины, то достаточно открытых уроков и готовых компонентов. Естественно, в таком случае нет стимула лезть глубоко.
Миша
Вот вот
Михаил
Но если ты реализуешь сложную бизнес-логику, то практически никакая документация не поможет - призодится активно читать исходники
Миша
Но чуть функционал другой и ты в заднице
Михаил
И иногда даже залезать в ядро, занимаясь отладкой, чтобы понять глубинные механизмы
Михаил
То есть, в особых случаях даже чтение не помогает - требуется начать изменение исходников, чтобы понять всю суть происходящего
Михаил
Поэтому, если хочешь действительно изучить, возьми в работу вместо очередного сайтика систему управления предприятием с элементами взрослой ERP
Pavel
Михаил
Все зависит от твоего знания инструмента
Михаил
Ни одного подобного не завалялось
Dmitriy
Dmitriy
Михаил
Pavel
мне интересно не начнутся тормоза у модх если на ней написать многофункциональную систему. Ну типа Bitrxi24 там. или всякие складские учеты со списаниями, рассчетами себестоимости, зарплатой и отчетностью
Миша
Да нет
Миша
С чего бы им начаться
Миша
Использовать по факту orm pdo
Миша
Его к примеру и фреймы юзают
Pavel
а админка тормозить от перегруженности?
Миша
Да можно свою написать
Михаил
У меня больше года работает складской учет на базе MODX - за это время документов об инвентаризациях, списаниях и приходах заведено более 50 000
Pavel
от сам фреймворка от огромного количества namespaces
Dmitriy
Я согласен но тем не мене
Pavel
Михаил
Да
Миша
Поклон
Pavel
то, о чем 1с-ник может только мечтать - реализовать складской учет в вебе.
Михаил
Вся работа в системе идет, фактически, по 20 складам со своими остатками/продажами по каждому и тд
Pavel
вы ее не продаете? демок нет в интернете или статей о ней?
Pavel
мне интересно как реализовали интерфейсы админки. Свои на Extjs формочки рисовали?
Михаил
Поэтому у меня есть реально действующий ответ на все выпады из серии "MODX маленькая CMS, на которой нельзя ничего серьезного реализовать"
Миша
Да в основном времени нет на статьи у профессионалов
Михаил
Для всех пользователей реализованы интерфейсы на фронте
Михаил
Такие вещи в Ext мы даже не пытались делать. Было очевидно, что это нерационально.
Pavel
типа бутстраповского интерфейса? или по принципу SPA?
Михаил
Бутстрап