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