Точно нужно будет заводить дополнительные параметры с возможностью выбора, причем у разных товаров наборы будут разные (цвета, размеры и т.п.). Здесь не помешали бы примочки как на shopkeeper (типа shk-select и т.п.) Ты вот это глянь. Кликаешь картинки — параметры меняются. Параметры меняешь — картинки соответствующие меняются. Но это все — фронт и индивидуальные примочки, так что подобные вещи на совести конечного разработчика. А вот база, дающая возможность делать это, при чем с использованием 100% технологий самого MODX-а — это уже задача сборки. Вот там используются стандартные TV-параметры и т.п., так что подобные вещи делать — запросто. Еще нужна будет возможность один и тот же товар размещать в нескольких категориях. Я уже делал это на shopkeeper (баловался), но не помешало бы такую функциональность запихнуть в ядро. Да, это надо, и это будет. Собственно, наработки для этого есть давно. Просто будем смотреть как красивей это сделать (чтобы было удобней в управлении). Соответственно под это еще и роутер надо зафигачить. Тоже будет сделано. Еще неплохо было бы реализовать какие-нибудь JS примочки типа полета товара в корзину или helper как в modx. Это тоже будет сделано. При чем в этой версии большое внимание будет уделено боле-менее качественному шаблону и Ajax-у. Я думаю, какие-то идеи придут, и я обязательно вынесу их на рассмотрение. Да, идеи озвученные однозначно нужны будут. Не все будет сделано и не все сразу, но тем не менее, во многом будем опираться именно на них. Вообще, я предлагаю создать пару тем, в которых накапливать вопросы и предложения на темы shopmodx и связки templatesphp и modxsmarty — smarty-плагины, процессоры, расширения, заструганные именно под эти продукты. Например, я сделал простенький процессор для вывода картинок из gallery, сейчас делаю breadcrumbs. Вот это всячески поддерживаю. Причем планирую создавать документацию по процессорам и т.п., так как в отличие от сниппетов, они более стабильные и универсальные. Я думаю, чем шире будет такой «репозиторий», тем выше будет интерес к этим продуктам и они сильнее будут развиваться. А то сейчас все как-то раскидано по разным местам, сразу не найдешь. Будем думать над этим.

Точно потребуется система скидок в зависимости от акции (причем акций может быть одновременно несколькои на разные, заданные группы товаров: новинка, праздник, распродажа), суммы покупки, накопительных за период и индивидуальных для покупателей. Можно сделать возможность выставлять какие-либо флаги (типа скидок, новинок) сразу на все товары в категории. Можно предусмотреть систему учета спроса — пригодится для вывода лучших товаров и отчетов. Не помешает заложенная система резервирования на складе — как при оплате, так и просто на время. Еще можно было бы сделать возможность выставлять на продажу наборы, которые комплектуются из отдельных товаров, но имеют другую цену. Причем эти же товары можно приобрести отдельно. На складе фактически пусть учитываются именно товары, а наборы — типа виртуальных папок и формируются на лету, если есть все товары для набора.

если есть какое-то ТЗ, бриф или типа того Как такового ТЗ нету. Пока только некоторые хотелочки на словах. Трудно сказать сразу. Обычно идеи возникают во время работы. Точно нужно будет заводить дополнительные параметры с возможностью выбора, причем у разных товаров наборы будут разные (цвета, размеры и т.п.). Здесь не помешали бы примочки как на shopkeeper (типа shk-select и т.п.) Еще нужна будет возможность один и тот же товар размещать в нескольких категориях. Я уже делал это на shopkeeper (баловался), но не помешало бы такую функциональность запихнуть в ядро. Еще неплохо было бы реализовать какие-нибудь JS примочки типа полета товара в корзину или helper как в modx. Не помешала бы система фильтрации типа tagManager. А ты планируешь AJAX туда заложить? Тоже такая вложенная функциональность будет нелишней. Я понимаю, что это все можно сделать самому, но когда это включено — для многих такие вкусности станут решающим фактором. Мне пока трудно сказать, что можно добавить в сборку, я пока в ней мало ковырялся. Я подобные программы делал на Delphi (движение комплектующих склад -> формирование комплектации по требованиям на изделия -> склад готовой продукции, со всякими отчетами), но тут нужен немного другой подход. Я думаю, какие-то идеи придут, и я обязательно вынесу их на рассмотрение. Вообще, я предлагаю создать пару тем, в которых накапливать вопросы и предложения на темы shopmodx и связки templatesphp и modxsmarty — smarty-плагины, процессоры, расширения, заструганные именно под эти продукты. Например, я сделал простенький процессор для вывода картинок из gallery, сейчас делаю breadcrumbs. Я вообще сейчас стараюсь избегать по максимуму использования стандартных чанков и сниппетов. И было бы неплохо иметь единую кучу, куда все это можно было бы сваливать, обсуждать, дорабатывать. Я думаю, чем шире будет такой «репозиторий», тем выше будет интерес к этим продуктам и они сильнее будут развиваться. А то сейчас все как-то раскидано по разным местам, сразу не найдешь.

Ох, вообщем нужна помощь так как с ООП у меня проблемы. Вообщем нужно обратиться к методам одного класса известного модуля (по коду видно), но есть проблемы. Вообщем вот я получаю сервис. $articles = $modx->getService('articles','Article', $modx->getOption('core_path') . 'components/articles/model/articles/', $scriptProperties ); Затем мне нужно в ручную создать ресурсы (в данном случае новости) и применить некоторые методы из пакета Article. $document = $modx->newObject('Article'); ...... В итоге наблюдаю ошибку при создании: Fatal error: Class 'Article_mysql' not found in .................\core\xpdo\xpdo.class.php on line 763 Погуглив я вроде как стал понимать, что проблема кроется в одинаковых названиях классов. Но теперь непонятно, что можно сделать чтобы подключить те методы без конфликта через $modx->getService так как менять название в схеме таблицы это костыль, который не хочу делать. Думаю наверняка есть простой метод обхода проблемы, но плохие познания в ООП подводят.

Ольга Ивановна, здравствуйте! Извиняюсь за задержку, что-то закрутился тут, еще и выборы… Все сделал, все поправил и доработал. Сейчас форма работает корректно, и отправляются уведомления на почту.

А когда можно ждать релиз? Всей суммы мы еще не собрали, но как я и говорил изначально, работы начнутся через две недели после анонса топика. Получается с 11-го числа. Очень постараюсь за неделю все сделать (просто хочется сделать очень много всего нужного и хорошего, но буду расставлять приоритеты от необходимого к просто хорошему, чтобы в заявленный срок основной функционал обязательно был обеспечен). Кстати, если у тебя предполагается магазин, и если есть какое-то ТЗ, бриф или типа того, пришли мне. Я посмотрю, что можно будет учесть еще на этапе создания сборки.

По поводу шаблонов и общего списка: шаблоны созданы не для того, чтобы сделать исключительно индивидуальные списки, а чтобы разделить единый список. Ведь в конкретной политике на основе конкретного шаблона имеется ограниченное количество вариантов. Согласись, гораздо удобней видеть, что в этой политике назначено 7 из 15-ти, чем просто 7 из вообще всего набора прав. Это если ты пользователям всего одну роль создаешь, это может особо и не понятно, но когда у тебя на сайте штук 30 политик, тогда ты это все оценишь.

По поводу проверки прав и наиболее удобного способа: вот это очень и очень сложный момент. Можно даже почитать статью, которая была почти сразу написана после этой статьи, чтобы оценить это примерно. Так вот, в метод checkPolicy лучше не лезть вообще. Нет, в упрощенном варианте конечно можно по какому-либо условию сделать свою проверку, и либо сразу вернуть четкий результат, либо отдать дальше на выполнение родителю через return parent::checkPolicy(), но лучше все-таки этого не делать. Если у тебя все это дело будет использоваться во фронте, то лучше все это делать именно на процессорах, так как тебе довольно не сложно будет расширить базовые процессоры и просто в своих выполнить проверку на уровне нативных методов. Это получится дешево и сердито. Я хочу, чтобы юзеры с фронта могли просматривать/создавать/редактировать/удалять/getlist своих/чужих Вот это тоже очень интересный момент. Я не раз говорил (и Джейсону тоже), что у нас с политиками есть очень большой промах. У нас в принципе нет такого понятия сейчас как владелец. В моем понимании все создаваемые объекты должны иметь флаг владельца, чтобы можно было выставить исключительные права. Второй момент (тоже очень досадный), что все рассчитано на групповые политики. То есть, права выдаются на группы пользователей, но не выдаются на конкретного пользователя. В итоге получается, что чтобы дать индивидуальные права одному пользователю, надо создать для него группу и отнести его к этой группе. В итоге 1000 пользователей — 1000 групп. Вообще не кульно получается. В своем ModZilla я расширил этот механизм и добавил механизм индивидуальных прав для пользователей, но во-первых, там все равно все не идеально, во-вторых, это вряд ли будет включено в официальное ядро в обозримом будущем, а в третьих, это вообще становится все сложно :-)

Привет! Коммент реально зачетный! Сразу видно, что не 5 минут потратил на изучение этого вопроса. Но наверно правильней было сразу в отдельный топик оформить. Ну да ладно, пусть здесь будет. Итак, по сабжу: так много писать не буду, а выделю основное. Ты много раз говоришь про локальные и глобальные политики, но никак не можешь уловить разницу между ними. А между тем, суть как раз и кроется в том, что означают эти названия. Глобальные — они и в Африке глобальные. И локальные там же. Вот у тебя есть глобальное право сохранять документы. ОК, априори ты можешь взять, и сохранить документ. НО, документ может находиться в той группе документов, на которую у тебя нет прав на сохранение. То есть, в принципе ты можешь сохранять их, но конкретный документ, находящийся в конкретной группе, ты сохранить не можешь — нет прав на это. То же самое и с публикацией и т.п. Это все равно, как есть у тебя глобальное право Копать. В принципе ты можешь пойти и где-то начать копать. Но придешь в городской парк, и скорее всего тебя быстро скрутят, так как конкретно в этом парке ты копать не имеешь права. Надеюсь ответил на твой вопрос. По поводу расширения не тех процессоров, лишних проверок и т.п.: безусловно, где-то не все оптимально. Но по большей степени там все оправдано. И еще вот такой момент по поводу проверок прав до и после сохранения. Как я и писал выше, проверки прав на документы (ресурсы), основаны на участии документов в группах ресурсов. А так как документ, пока не сохранен, по сути не может и в группе находиться, то прав локальных как бы и не имеется. И получается, что после сохранения и возможного попадения документа в какую-либо группу ресурсов, могут измениться локальные политики конкретно на этот документ.

В коде ошибку допустил, когда редактировал. Надо вот так: if ($parentResource->checkPolicy('add_children')){ // ... }