[EVO] CResource - редактирование всего и вся

Я не знаю как вам, но лично мне в MODX до сих пор не хватает такой штуки, которая бы позволяла редактировать параметры нескольких документов на одной странице. Так сказать не отходя от кассы.

Нет, решения конечно есть. Но они делятся на 3 типа
— В разработке и разработка хз когда завершится
— Кривые или порой проблемно воспользоваться
— Не умеют того, что мне хочется

За частую существующие решения комбинируют в себе сразу несколько типов — как темпераменты.

MetaQuickEdit
— Разваливается верстка
— Не поддерживает ТВ параметры

fast_content_csv
— Выгружаем в excel и там правим как нужно
— Не вызывает события onDocFormSave, на который иногда навешиваются вспомогательные плагины типа TagSaver или даже банальный расчет значения 3 ТВ параметра по первым 2.

Возможно есть что-то еще, но стоит ли продолжать перечислять? Ведь если бы инструмент был достойный — о нем бы знали все. Ну или хотя бы многие…

Теперь я позволю себе немного отвлечься и рассказать предысторию. Когда ребята (не будем показывать пальцем) объявили о скорейшем выходе BID, это стало сенсацией. Примерно в это же время я начинаю работу над проектом в котором несколько миллионов товаров — естественно хранить их в таблице site_content не разумно. BID-а нет, и как уже теперь понятно — хорошо что я его не стал ждать.

Для фронта взял DocLister. Для создания записей написал небольшой класс по принципу modResource из MODxAPI. Осталось дело за малым — редактирование записей.

Писать интерфейсы для редактирования было некогда, а изобретать очередной велосипед для формирования списка записей я не захотел. Поэтому взял easyUI datagrid о котором упоминали в BID. Передал ему список документов в JSON из DocLister'a и возрадовался что все так просто.

Потом захотелось добавить немного гибкости… В общем что из этого вышло смотрите в ролике

Как видно, сделано на половину. А причина тому проста — после очередной беседы с заказчиком решили отказаться от редактирования данных через сайт. Делаться все будет в 1С от куда собственно и будет происходить переодическое обновление информации. Товаров много — поэтому думаю не стоит объяснять, что правки и на сайте и в 1С еще больше запутают владельца сайта и меня как разработчика.

Поэтому и имеем что имеем. Но данный топик не для того, чтобы похвастаться какой я молодец, а для того чтобы поинтересоваться у сообщества — интересна ли им эта разработка? Нужно ли ее доводить до ума?

Уверен — на предыдущие вопросы многие (если не все) ответят — ДА. Но теперь самый главный вопрос — одно дело, когда я делаю подобное для проекта. А совсем другое — в свободное время.

За сим и вопрос — может ли кто-то из сообщества предложить мне интересный проект на котором я смогу довести эту разработку хотя бы до BETA версии? Быть может сообщество готово к краудфандингу?

78 комментариев

avatar
Хорошее решение собственно логика работы таже самая что и в так же не сделанном и находящимся на той же стадии bid-cart.
avatar
Весь прикол в том, что CResource на выходе даст не только модуль но и улучшения сниппета DocLister + добавит гибкости в MODxAPI. Т.е. в комплекте с этим плагином автоматически развивается еще 2 проекта, которыми уже некоторые пользуются
Комментарий отредактирован 2013-11-13 18:48:36 пользователем Agel_Nash
avatar
Так получается, что имеющимся уже функционалом можно полноценно пользоваться для управления стандартными документами? Или чего-то еще не хватает?
Есть вообще перечень запланированных задач?
avatar
Не хватает неного легкости решения что б можно было не только пользоваться но и легко изменять под свои задачи
так же думаю нужно сразу реализовывать как работу документами MODX так и работу с внешними таблицами

Вообщем продукт есть но сырой а что довести до ума нужно приложить усилия
avatar
Не хватает неного легкости решения что б можно было не только пользоваться но и легко изменять под свои задачи
DocLister позволяет без гемороя кастомизировать массовый вывод данных — контроллеры в помощь.

MODxAPI может так же без гемороя помоч настроить работу с виртуальными полями. Как пример — modJoomla для работы с веб-пользователями MODX (обрати внимание на виртуальное поле salt).
Сейчас у меня есть заговка абстрактного класса autoTable для MODxAPI. Вот класс пример класса modReview сделаного на основе такой заготовки
include_once(dirname(__FILE__)."/autoTable.abstract.php");
class modReview extends autoTable{
    protected $table = "reviews";
}

Т.е. тупо меняем имя таблицы и получаем profit.
$DOC = modReview($modx);
$DOC->create($_POST)->save();

Не ORM конечно, но принцип очень похож. Кстати, класс modReview как раз таки и используется на сайте который разбирался в видео.

так же думаю нужно сразу реализовывать как работу документами MODX так и работу с внешними таблицами
Работа с документами как видно уже есть. С внешними таблицами почти тоже, но в отличии от документов пока невозможно создавать новые записи в кастомных таблицах (только редактирование и удаление).

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

Для кастомной таблицы хотелось бы сделать заготовку модуля с набором виджетов для ввода информации (календарь, загрузка картинки, текстовая область, email, строка, число и т.д. и т.п.)

Все остальные хотелки уже почти оттестированы временем — DocLister и MODxAPI. Ну а самое главное — документация. Плагин довольно сложный, поэтому на документирование потребуется тоже время.
avatar
Подготовил исходник проекта и выложил на GitHub.
В README указал ссылку на дамп сайта который засветился в видео. Поэтому если желаете помочь в развитии — разворачивайте дамп, тестируйте и шлите багрепорты. Приветствуются PullRequest-ы.

Чуть позже как появится свободно время я сам накидаю примерный план что хотелось бы реализовать в плагине. В общем присоединяйтесь… Хотя судя по реакции сообщества — разработка мало кому интересна(
avatar
Не получается скачать agel-nash.ru/data/cresource.zip
avatar
Перезалил архив. Специально для вас создал раздел с категориями и статьями. Статьи привязал к категориям и настроил плагины чтобы можно было обозревать какие статьи привязаны к этой категории. Итого — там повсеместно используется DocLister. В админке:
— Для формирования списка категорий под статей в ТВ параметре
— Для построения грида плагином CResoruce
На фронте:
— Хлебные крошки
— Список категорий со ссылками под статьей
— Вывод списка статей как с фильтрацией по категориям, так и без фильтрации.
— Меню

В общем если детально разберете этот демо-сайт, то думаю многому научитесь. Заодно и поймете почему я DocLister везде использую.
avatar
Спасибо! Скачал. Буду разбираться.
DocLister я использую теперь вместо ditto. Нравится. Единственный недостаток — здесь blog.agel-nash.ru/addon/doclister.html не описаны плейсхолдеры доступные в чанках. В частности это не нашел:
Доступен только внутри чанка tpl
[+iteration+] — порядковый номер элемента в списке
[+url+] — ссылка на документ (если документ типа ссылка, то будет показана та ссылка, на кого ссылется этот документ, а не по принципу [~[+id+]~])
[+date+] — дата публикации документа сформированая по правилам указаным в параметре dateFormat (по умолчанию %d.%b.%y %H:%M). Помимо этого учитывается server_offset_time в настройках движка.
[+active+] — 1 если id документа совпадает с id элемента в списке.

Доступны везде если включена пагинация
[+параметр_id.totalPages+] — общее число страниц
[+параметр_id.isstop+] — (1 если текущая страница — последная)
[+параметр_idisstart+] — (1 если текущая страница — первая)
Возможно плохо искал.
Также не нашел подобную страницу modx.com.ua/thanks.html. Есть желание поблагодарить материально за нужную работу.
avatar
в файлике README.md на GitHub (главная страница проекта)
avatar
Увидел. Спасибо.
avatar
avatar
И я немного присоединился к благодарностям :)
avatar
avatar
Обновил документацию по плейсхолдерам. Возможно теперь станет еще понятнее от куда что появляется.
avatar
Очень хорошее дело! Хотелось бы еще возможность добавления ресурса в несколько категорий и чпу.
А так просто супер. Большое дело делаете.
  • Shin
  • 0
avatar
/news/1.html — чем не ЧПУ? Просто в моем случае в качестве алиаса я использовал id записей. Если в вашей таблице есть специальное поле для алиаса — то проблем нет, в плагине CustomRoute параметру fieldname нужно присвоить имя этого поля (по умолчанию там указано id). Если же редактировать обычные документы из site_content. То вообще проблем не вижу — плагин CResource работает точно так же, как штатные средства MODX для редактирования документов. Т.е. создавая документ на основании pagetitle (или какие там у вас будут настройки) — формируется алиас.
avatar
Я видел 1.html. Имел ввиду автогенерацию алиаса. Но важнее по-моему, документ в разных категориях. Этого в модх нет.
avatar
Скачайте тестовый сайт. Откройте еще раз CustomRoute и посмотрите внимательно на вызовы сниппетов генерирующий ссылку
[[route? &id=`18` &alias=`[+id+]`]]

Как думаете, что будет, если я подставлю вместо id поле alias? Верно. Будет долгожданное ЧПУ. А теперь второй вопрос — как вы думаете, что будет если из modResource в свой класс типа modReview скопировать функцию getAlias? Правильно — будет вам автогенирация. Т.е. можно считать, что эта хотелка из коробки уже есть. Вам нужно лишь научиться ей пользоваться.

Теперь ко второму вопросу. Да, в MODX нет категорий. Но разве вас кто-то заставляет создавать в категориях под-документы? Вот, пожалуйста. И что там есть категория? А если на сайте потыкать:
* Физические упражнения
* Научный подход

Как это сделано? Банально — при помощи плагина TagSaver и TV-параметров. А на фронте выводится при промощи того же DocLister. Теперь главный вопрос: Если DocLister умеет на фронте выводить статьи с учетом категорий, то сможет ли он в бэкенде их вывести, если использовать одни и те же параметры? Смекаете к чему я? Правильно — MODX уже поддерживает категории. Просто вам опять таки нужно научиться их готовить.
avatar
С несколькими категориями зачастую другой компот это генерация хлебных крошек а так же несколько разных Урлов для одного товара
а реализовать их не проблема
самый простой способ это разнести:
Категории и Товары по разным родителям и выбирать раздел через ТВ
короче тут просто главное желание а сделать можно :)
avatar
Категории и Товары по разным родителям и выбирать раздел через ТВ
Вот и я о том же. А «генерация хлебных крошек» и «несколько разных Урлов для одного товара» это уже точно не к CResource
avatar
Я думал сделать множественные категории, как во всех других движках, через таблицу связей. Вы правы. Нужно скачать и разобраться.
В любом случае, работа очень нужная.
Комментарий отредактирован 2013-11-14 20:13:13 пользователем Shin
avatar
Если хорошо подумать там суть таже:
товары отдельно от категорий
avatar
Через обычный фильтр дитто, надо полагать? а ТВ какой в данном случае должен быть?
avatar
По программной части ничего не могу сказать, но поддержать и похвалить хочется.
Это великолепно! :)
Комментарий отредактирован 2013-11-14 16:10:14 пользователем style-nes
avatar
Тестовый сайт не скачивается.
avatar
Перезалил
avatar
Мне кажется, что было бы просто замечательно, если бы эти отдельные таблицы (поля в них) привязывались и парсились стандартными функциями modx, в том числе для обработки TV.

Т.е. в конфиге плагина мы привязываемся к определенным шаблонам и если выбран такой шаблон, то заносим все данные в одну таблицу стандартными формами вместе с tv (все в одну строку).

Это требует несколько пунктов:
1. по аналогии с quid создается таблица, только не просто для tv, а полностью — копия структуры modx_site_content плюс при добавлении/удалении к шаблону ТВ — еще доп.колонки в этой же таблице для ТВ — это в принципе достаточно просто
2. Для создания документа тоже вроде все просто:
2.1. в конфиге для кнопки «добавить» просто надо передать pid родителя в GET и a=4
"docURL":{
        "new":"index.php?a=4&pid=32"
    }

это откроет стандартную форму добавления ресурса со всеми ТВ в нужном виде
2.2 На событие onDocFormSave после того как ресурс сохранится в обычную таблицу можно его оттуда достать вместе с ТВ и перенести это все в нашу таблицу в одну строку. При этом в таблицах content и значений ТВ все удалить.

В итоге мы уже имеем нормальную запись в таблице нашей для обработки в onetable

3. Редактирование ресурса — вот тут самое сложное. Видимо надо делать под это дело кастомный mutate_content.dynamic.php и подсовывать его вроде так:

case 'OnManagerPageInit':{	
		if($action==27&&isset($_GET['table'])){
				global $_lang,$_style;
				$manager_theme=$modx->config['manager_theme'];
				include_once "header.inc.php";
				include_once MODX_BASE_PATH."/assets/plugins/onetable/mutate_content.dynamic.php";
				include_once "footer.inc.php";
				die();
		}
		break;
	}


предварительно опять же передав в конфиге плагина crecource адрес для редактирования вроде

"docURL":{
		"edit":"index.php?a=27&table=8&id="
 
    }


где — table — это наш id шаблона, который мы заносим в отдельную таблицу.

При этом можно будет опять же распарсить входящие ТВ стандартно через modx-функции, если их немного подправить для корректной выборки ТВ из одной строки таблицы.

Ну а на событие OnDocFormPrerender также повесить добавление этого параметра table в input type=«hidden», ловить данные и сохранять их в нужную таблицу при редактировании.
avatar
Поздравляю, вы изобрели шопкипер.

Я бы не советовал идти по этому пути. Andchir тоже считал, что чем больше «стандартных примочек» из админки modx он заюзает, тем проще будет разобраться в админке. В итоге он сделал все, чтобы админкой было вообще невозможно пользоваться. Одна точка входа — хорошая концепция для кодинга, но не для интерфейса админки (я имею в виду тот факт, что для попадания в каталог из админки надо умудриться нажать на совершенно неочевидную ссылку, потом на дерево, потом опять на ссылку).

Идея о том, что пользователь идиот и не в состоянии запомнить как заполняются данные в модуле или внешней админке, конечно же имеет право на жизнь. Но это не значит, что из-за идиотизма пользователя надо делать ему и себе неудобно.

А вот насчет того, что надо «какбе TV» хранить в рядочек в одной таблице — идея хорошая и правильная. Хотя если речь идет о каталогах, то есть ведь еще и зависимые от категории товаров свойства, которые не могут храниться в одной таблице. Впрочем, это уже тема для отдельного большого разговора.
avatar
шопкипер хранит ТВ в отдельных таблицах аналогично модховским ТВ — он не потянет в стандартной сборке и 100 000 товаров кто бы что не говорил именно из-за особенностей выборки из такой таблицы ТВ.

Да и этих «совершенно неочевидных кнопочек» каталог я уже тоже наелся, поэтому и пишу в теме cresource (где есть нормальная кнопка редактировать и нормальная кнопка добавить), но нет функционала редактирования/добавления в настоящий момент. Т.е. кнопка есть, идея что это должно быть в одной таблице есть, а куда идти дальше — похоже нет. Вот я и предлагаю куда идти :)

Если же хранить в одной таблице — то потянет и 600 000 — больше не пробовал.

И второй момент — я ориентируюсь на docLister с его onetable-контроллер от того же автора, а он хочет данные из одной таблицы :)
avatar
я ориентируюсь на docLister с его onetable-контроллер от того же автора, а он хочет данные из одной таблицы

Боюсь, а может наоборот, надеюсь, что для полноценных каталогов не получится обойтись без допиливания DL под несколько таблиц. Мы же не можем иметь в БД столько таблиц, сколько категорий в магазине, а значит различия между товарами в разных категориях одинаково надо будет хранить в отдельной таблице с привязкой по категории, а не по шаблону, как в случае TV.
avatar
Для всех товаров одинаковых шаблонов — одна таблица, в какой бы категории они не находились. Поле parent для выборки никто не отменял. Так что таблиц будет ровно столько, сколько шаблонов понадобилось для разных товаров.

Если у вас одежда и у нее в параметрах только цвет/раздел/материал, то неважно — женская она, мужская или детская (по категориям) — все эти товары с их тремя параметрами хранятся в одной таблице в рядок и выбираются по полю parent :)
avatar
Ню-ню=)

А если по каждому сочетанию цвета и размера нужно хранить остатки?

А если при одинаковых шаблонах нужно просто вывести блок под товаром с перечнем характеристик? И товары будут вообще разные во всем (шило и мыло).
avatar
А если по каждому сочетанию цвета и размера нужно хранить остатки?
А причем тут это? Это разве умеет стандартный модх или шопкипер?

Я говорю про то, что одинаковые вещи должны быть оформлены одинаково, а не плодить 100 велосипедов на случай «а если надо вот это». Это не относится к стандартной ситуации и не реализовано в модх на данный момент, так к чему эти риторические вопросы ни о чем? :))

Опять же — заводите себе плагин multiTV, который работает с обычными ТВ и храните там все что душе угодно. Вряд ли он станет работать с вашей кастомно-придуманной таблицей со своими полями без ТВ.
Комментарий отредактирован 2014-01-06 20:33:22 пользователем webber
avatar
А задача стоит повторить то, что итак умеет modx и шк? Или все же сделать что-то помощнее?

Ладно, меня вы убедили. В том смысле, что спор ни о чем.
avatar
шк так не умеет, т.к. я уже написал вначале — даже с собственной таблицей он не потянет больше 100 000 товаров именно из-за затыка выборки ТВ из таблицы хранения своих ТВ такой структуры, как в и модх. Не говоря уж про фильтрацию.

и модх так не умеет, т.к. умрет уже на 10 000 товаров, если будет использовать дерево :)

Я предлагаю использовать лишь то, что модх умеет нормально — обрабатывать ТВ перед записью в базу, обрабатывать ТВ перед выдачей их из базы, заботится о безопасности этих данных и достигать нормальной гибкости за счет связки ТВ+набор ТВ и т.п.
Комментарий отредактирован 2014-01-06 20:46:32 пользователем webber
avatar
Привязка к шаблону и создание под каждый шаблон своей отдельной таблицы — это и есть решение проблемы разных ТВ у разных видов ресурсов (как это сделано в quid, только не просто выносом одних ТВ в таблицу, а вместе с полями вроде pagetitle). Ну а чтоб с этими полями не мудрить ни при создании ни при редактировании и предлагаю этот кусок таблицы любой оставлять такой же по структуре как и таблица modx_site_content. И добавлять только колонки нужных ТВ в зависимости от шаблона, к которому привязана та или иная таблица.
avatar
Кто такой quid?

Я думаю, что в каталогах тянуть за собой структуру site_content будет накладно. Выигрыша никакого, а помнить что из полей попало в таблицу, а что нет — это нудно. Было такое, долго не понимал, пошто шопкипер ломается на попытке записать что-то в longtitle (кажется), которого как оказалось, не было в таблице catalog.

В целом же я не вижу вообще необходимости в TV как таковых для таблиц, которые мы сами создаем под конкретный проект и сами пишем в конфигах структуры. Может быть я просто не о том же думаю, о чем вы говорите, но мне не нравится также присобачивание TV с их шаблонами к EasyUI. Это во всех отношениях неприятное занятие.
avatar
quid — это плагин такой для modx evo, который хранит тв шаблона «в рядок в отдельной таблице» помимо основной таблицы ТВ — ооочень полезная вещь, если надо фильтровать что-то в большом количестве.

Да и не разговор о том, чтоб это все в easuUI пихать. В таблице выведенной через easyUi штук 5-6 колонок основных идет (текстовые или чекбоксы какие вроде название, цена, показывать/не показывать) и т.п. чтобы быстро подредактировать. Для добавления же нового или редактирования существующего ресурса со всеми его ТВ и прочими полями — открывается отдельно во фрейме форма. Так вот если это просто ресурс (вроде новости в выложенном сайте) — то тут проблем нет, все идет через стандартные формы.

А если это ресурс из сторонней таблицы, то там не доделано еще. Вот и предлагаю в какую сторону доделывать это можно было бы.
avatar
Значит, я верно вас понял.

Собственно, все зависит от конкретного проекта, и ваш подход вполне себе неплох, если речь идет о сколько-нибудь простых каталогах. Соблазн велик, но я бы не стал идти этим путем, если речь идет об универсальном решении.
avatar
А TV для собственных таблиц нужны с одной простой и единственной целью — чтобы их нормально и безопасно распарсить и обработать что в админке, что на фронтэнде стандартными средствами modx, а не придумывать и реализовывать очередной 101-й способ обработки списка или чекбоксов каждый раз что в админку, что на сайт.
avatar
Почему бы очередному благородному дону не реализовать 101-й способ?

Собственно, спор скатывается в сторону ниочема. Есть 2 мнения, все равно потом придет лесник и всех нас разгонит.
avatar
Это скорее разговор из серии «не читал но осуждаю». Сложилось стойкое ощущение, что вы просто рассуждаете не удосужившись для начала скачать дамп сайта с cresource да посмотреть что и как там реализовано, а что еще не доделано, какими инструментами это все сделано и как с помощью тех же инструментов можно сделать что-то еще :)

Может для начала ознакомиться все-таки с предметом рассуждений?

А насчет «сложных каталогов» — не встречал еще таких. что нельзя было бы реализовать с помощью шаблонов+тв. Единственное — это все упирается в конечном счете в производительность системы modx, рамки которой можно значительно раздвинуть предложенным мной способом практически не потеряв гибкости. Уж куда гибче связка шаблон+набор ТВ, чем своя таблица и своя самописная обработка всей этой таблицы под каждый вид товара как снаружи так и внутри сайта. не говоря уж про безопасность и тысячи подводных камней/косяков, которые может подсунуть нам modx evo :)
avatar
Все, я с вами согласен. Все, что было выше — это не я писал, у меня акк угнали, теперь я его вернул и буду вас всецело поддерживать.
avatar
Все что тут наобсуждали по факту это bid-cat :)
— использование одной таблицы для доп параметров
— удобное управление интегрированное в MODX
— использование jEasyUI

Жаль что так пока и не доходят руки довести все до ума

Кстати у SHK только 1 недостаток это неудобство редактирования при том это решается довольно просто
и будет вполне комфортное решение до 100к товаров :)

вообщем я бы подвел итог что путей решения есть несколько просто нужно взять это все и сделать.
avatar
Кстати у SHK только 1 недостаток это неудобство редактирования
Еще чпу для товара и множественные категории. Возможно, уже решено.
Дальше мультиязычность и мультивалютность.
avatar
Много букав. Я пока не смог детально вникнуть в чем причина холивара. Но пока разработка заморожена по 3 причинам:
1) Нехватка времени
2) Для комфортной работы CResource необходим DocLister + MODxAPI. Это аж целых 2 зависимости установку и обновление которых я планирую автоматизировать в ближайшем будущем (кому интересно — можете посмотреть демку).
3) Планирую выпустить DocLister2 и переработать код MODxAPI, чтобы это было больше похоже на нормальную ORM.

Теперь что касается хранения всех данных в одной таблице — я категорически против этого. Да, есть контроллер onetable с помощью которого можно реализовать большую часть простых каталогов. Но я не планирую делать 1 модуль на все случаи жизни и заниматься копипастом данных из 1 места в другой. Представьте, у вас таблица с ТВшками на 100 тысяч записей. Она клонируется под другим видом плагином QUID. А еще и тут мы куда-то клонировать что-то будем. WTF? А ничего, что данные могут иметь разный формат: строки/числа? Дык нахрена собственно изобретать велосипед — это же самое можно реализовать 101 способом при помощи других модулей.
Тут идей в том, чтобы дать базовую заготовку с минимальным набором функционала для решения простых вещей. Те, кому нужны будут каталоги посложнее — будут вынуждены писать код. Да, именно писать код. Делать так, чтобы каталоги на 1 млн записей любой сложности мог создавать каждый верстала я даже и не планирую.

Что касается формы редактирования данных — то да, планируется использовать что-то похожее на ТВ параметры. Но явно использоваться это будет не в том виде, в котором оно сейчас предлагается MODX-ом. Опять таки, скорее всего придется руками сопоставлять поля с заранее подготовленными виджетами. Но пока даже и не знаю как это будет в конечном счете выглядеть — поэтому в дебатах не могу принять участие.
avatar
Я пока не смог детально вникнуть в чем причина холивара.

Это потому, что

вы просто рассуждаете не удосужившись для начала скачать дамп сайта с cresource да посмотреть что и как там реализовано, а что еще не доделано, какими инструментами это все сделано и как с помощью тех же инструментов можно сделать что-то еще :)

Про композер интересно. Только непонятно с автозагрузкой классов получилось, выходит, что нам волей-неволей придется жестко задавать структуру папок. Может быть как-то вынести этот вопрос на обсуждение, или хотя бы озвучить как-то? А то будем параллельно вести разработку одних и тех же вещей, потом как обычно начнем локти кусать из-за несовместимости.
avatar
Composer позволяет выполнять автозагрузку по стандарту PSR-0 или PSR-4. Можно так же указать папку из которой автоматически загружать файлы. А можно указать конкретный файл. Да, желательно конечно, чтобы при разработке придерживались стандартов PSR-0 или PSR-4. Но на первых парах можно обойтись и без этого. Вот допустим для MODxAPI который рассматривается в примере я просто указал папку (в контексте пакета имеется в виду assets/lib/MODxAPI/) из которой загружать файлы с классами (больше ничего не правил). Ну это тонкости изучать которые нужно уже после релиза composer'a для MODX, а не во время разработки. Тем более это стандарты и я считаю что лучше придерживаться их и поправить свои разработки если это необходимо, чем придумывать костыли как сделать так, чтобы без переделок работало все и сразу. Кто не согласен — пусть дальше по старинке работает с MODX Evolution в конец расслабляясь от отсутствия стандартов, невозможностью управлять зависимостями и автозагрузкой.
avatar
Про стандарты я уже говорил :) правда в личку

1 у MODX есть свой стандарт но им никто не пользуется
2 к сожалению авторы своих решений не спешат их обновлять (к примеру обновление MANAGER_PATH)
3 Composer рулит но только тогда если его сделать стандартом для MODX и включить в базовую поставку только тогда это подтолкнет всех делать по стандарту. Иначе я не вижу причин которые бы заставили вникать и переписывать готовые решения :(
avatar
у MODX есть свой стандарт но им никто не пользуется
Потому, что эти стандарты мягко говоря ГАВНО

Composer рулит но только тогда если его сделать стандартом для MODX и включить в базовую поставку только тогда это подтолкнет всех делать по стандарту. Иначе я не вижу причин которые бы заставили вникать и переписывать готовые решения
composer рулит и без modx. А разбираться в стандартах MODX (которые из категории Г) не хочется (кто добровольно согласится ковыряться в этом?). Более того, разбираться в стандартах которые уважают веб-разработчики всех систем это дело чести так сказать.

Это примерно тоже самое, что если ты хочешь писать правильно — то учишь правила. А не хочешь — придерживаешься принципа мол и так понимают. Со временем человек который учил правила резко выделяется из толпы тех, которые общаются на первобытном уровне «му-му ме-ме мы друг-друга понимэ».

Я понимаю, что ты призываешь придерживаться стандартов MODX. Но я призываю MODX придерживаться стандартов. Это совершенно разные вещи. Более того, я никого не заставляю использовать эти вещи. Я их делаю для себя. Те, кто захочет пользоваться моими разработками — им придется так или иначе разобраться как устанавливать модули через composer. Ну а те, кто не захочет — смогут по старинке делать сайты (благо и без моих наработок есть еще куча сниппетов/плагинов/модулей которые как раз-таки и остаются без поддержки). Т.е. тут я никого не ограничиваю в выборке и не заставляю насильно что-то использовать. Увидят выгоду — пожалуйста. Увидят пользу — здорово. Захотят научиться — подскажу. Ну а остальные лесом. Только я не понимаю зачем этим остальным вообще тогда веб-разработка?

Любой веб-разработчик (я сейчас про php кодеров говорю) даже начинающий двигается по следующей схеме:
— HTML+CSS
— Азы PHP
— ООП программирование
— Программирование с соблюдением стандартов
— Изучение новых технологий

Если же программист застывает на определенной стадии допустим (азы php) и не желает двигаться далее, то этот человек просто обречен делать говносайты пусть и с красивым дизайном.

Вот и думайте кто чего хочет. Делать сайты и развиваться как разрабочтик. Или же просто делать сайты пока делается.
avatar
Я согласен с тем что нужно развиваться в сторону стандартизации в этом плане Компосер рулит.

но политика выборочного принятия правил это глупо
Ты предлагаешь принять новые правила но сам не принимаешь старые, да пускай они ГОВНО но они есть. Притом они есть уже года 3 но никто не обращает на них внимание.

Да я понимаю что ты хочешь сделать лучше но ты как по мне делаешь это через несколько шагов сразу
avatar
Как ты не поймешь, что это я делаю ДЛЯ СЕБЯ! Не нравится — не юзай.
avatar
Нужно воспитать культуру кода и его правильности. Тогда будет все хорошо.
avatar
Много букав. Я пока не смог детально вникнуть в чем причина холивара.

и правда пришел лесник и всех разогнал )))))

Речи о дублировании и не идет. Идет речь о том, чтобы
1. ресурсы определенного шаблона сразу писались в отдельную таблицу вместе с ТВ в одну строчку и соответственно обрабатываться могли через контроллер onetable без записи их в modx_site_content и modx_site_tmplvar_contentvalues
2. Шаблон этот задаем в настройках плагина.
3. ТВ берутся из тех, что прикреплены к шаблону, типы для колонок в таблицу — из типов ТВ.
4. Для добавления/изменения ресурса из отдельной таблицы используется стандартная форма добавления/изменения ресурса modx со стандартными полями и прикрепленными к шаблону ТВ

п.с. холиварить и не собирался, у каждого свое мнение, может кому-то это и сто лет не нужно.
avatar
Теперь в целом понятна суть. Идея конечно интересная, НО! Это как бы не входит в задачи поставленные CResource. Данную хотелку можно очень легко реализовать примитивным плагином на событии onDocFormSave. После этого да, можно будет редактировать данные и в гриде easyUI и открывать во фрейме (конфиг CResource позволяет подменить ссылку для страницы фрейма/изменить контроллер DocLister для вывода данных в грид).

Так что те, кто говорил об утопическом варианте такого подхода — не пользуйтесь им. А кому это нужно — легко смогут активировать. Так что действительно — холливар как говорится не в кассу.
avatar
Это как бы не входит в задачи поставленные CResource. Данную хотелку можно очень легко реализовать примитивным плагином на событии onDocFormSave.

Ну не таким уж примитивным, учитывая что форма формируется прямыми запросами к базе, где этих данных не будет :) Тут уж скорее подходит событие onBeforeDocFormSave для перехвата «на подлете» к базе что при создании нового что при редактировании существующего. Однако пару нюансов в этом процессе выявлены:
1. по modResource — нет работы со стандартными датами (кроме publishedon), т.е. поля publishedby,editedon,editedby, а тем более pub_date и unpub_date и завязанные на них значения published — нигде не обрабатываются.
2. по onetable — аналогично по датам глухо (например по сортировке pub_date/createdon)
3. по плагину CResource — отказывается также работать с полями вроде дата из календаря для сторонних таблиц.
4. По тому же плагину — возможно ли часть параметров кроме конфига передавать динамически (например какой-нибудь request из $_GET или еще чего) или к конфигу не подступиться снаружи? Не помешало бы (если нет такой возможности).

Ну а насчет «не входит в задачи» — так потом опять будут разговоры что «урезали/закопипастили вместо того чтобы расширить» — поэтому пока планирую добить эту тему в привязке к тому, что уже сделано по Cresource — работа кипит :)
avatar
1) Занес в TODO, хотя как уже говорил планирую сделать версию 2 более похожую на ORM
2) onetable это из DocLister. Тут нужно так же понимать, что onetable это заготовка для примитивных таблиц. Для более сложных таблиц проще унаследовать и внедрить нужную логику, нежели вносить 1000 лишних параметров, чтобы возможно когда-то кто-то воспользовался хотя бы 1 из них. В базовой комплектации сделано и так уже очень много параметров позволяющих без программирования начать выводить данные из любого источника. Просто опять таки, если внедрять поддержку дат, то нужно учитывать, что они могут храниться в различных форматах это еще как минимум 1 обязательный параметр.
3) Возможно. Особо не тестировал этот момент
4) Возможно, но опять таки. Думаю целесообразней дождаться выхода DocLister версии 2 и обновление MODxAPI, чтобы не тратить время в пустую тут и не выпускать потом версию CResource 2. К тому же уже планируется внедрение и DocLister 2, и MODxAPI 2 в ядро MODX Evolution. Так что вполне возможно, что часть задач и вопросов со временем отпадут сами собой.
avatar
По датам — было бы достаточно UNIX-time, как в основной таблице.
Просто получается что даты pub_date и unpub_date из календаря летят в необработанном формате, но для их преобразования есть стандартный метод $modx->toTimeStamp($value).
И еще нюанс — если pub_date больше текущей, то published по умолчанию в modx ставится в 0.

Ну а с датами из ТВ или других таблиц тут да — каждый борется как может. Для ТВ в принципе виз.компонент UNIXTIME и все нормально будет (ну кроме сортировки) — хотя это уже дебри, туда и лезть не стоит.

Но вот для замены modxApi в любом случае с датами из modx_site_content таблицы доработать не помешает.

вот тут я с со стандартными датами сражался и полями publishedby,editedby и т.п. :)
Комментарий отредактирован 2014-01-08 18:47:02 пользователем webber
avatar
И еще один момент неудобный — по крайней мере на мой взгляд. В классе autoTable поля по умолчанию default_field сразу при инициализации определяются и никакой легальной возможности их подменить (если мне нужна другая таблица) нет — т.е. при сохранении утыкаемся в то, что если таблица другая — то запрос не проходит. Тут бы было гибче либо перед вставкой в таблицу проверять еще раз эти поля и отсекать лишние, или давать возможность их поменять в зависимости от таблицы в какой нибудь хоть функции setTable, в которой сразу присваивается новая таблица и к ней пересчитываются новые поля.
Вариант второй с отдельным методом setTable вне конструктора (и желательно public чтоб его не переопределять в каждом классе-наследнике мне нравится конечно больше :)

Хотя, может конечно на текущую реализацию есть веская причина… я не в курсе )
Комментарий отредактирован 2014-01-08 17:56:09 пользователем webber
avatar
Если таблица определяется на лету, то для начала нужно определить этот класс. autoTable это не класс. Это абстрактный класс поэтому у вас всегда должен иметься оригинальный класс который унаследован от autoTable. Для скорости разработки все поля таблицы определяются автоматически. Но на продакшине уже желательно указывать самостоятельно default_field перечислить.
avatar
Класс то есть, и даже таблица своя в нем есть, которую и переопределить можно. Да вот беда — при инициализации этого класса берутся дефолтные поля из первой определенной таблицы в этом кастомном классе и потом если даже таблицу подменить, то поля то остаются старыми. Как результат — при попытке save() все нормально, пока он не пройдется по старым дефолтным полям из и добавит лишние — результат — ошибка sql — нет таких полей в таблице :)

Поэтому было бы просто замечательно вынести этот метод вроде setTable() с инициализацией полей из конструктора, а в конструкторе просто написать $this->setTable(). Тогда бы при необходимости можно было бы и в другом месте для другой таблицы «на лету» сделать такой же setTable() и получить новые дефолтные поля.

Или там что-то мешает так сделать (архитектура, безопасность и т.п.)?
avatar
Есть еще небольшие косяки по маршрутизации (сниппет и плагин route).
1. Похоже за счет использования rtrim при определенных обстоятельствах обрезает лишние символы, что бывает критично, т.к. потом не может найти такой ресурс в базе. Связано с тем, что rtrim обрезает справа не просто суффикс, а любые символы из суффикса, т.е. из страницы product.html получается produc (удаляется и буква t, т.к. она присутствует в наборе .html). Это особенно критично при использовании алиасов, т.к. их может быть сколько угодно и они бывают длинные (т.е. могут содержать практически все буквы адреса :)
2. Плагин не реагирует на проверку if($sendparent), т.к. к нему приходят, похоже текстовые переменные true и false, а не булевы. Т.е. что бы ни было выбрано, если оно выбрано, то if($sendparent) выдаст true и всегда перенаправит на родителя, что может вводить в заблуждение.
avatar
1. Знаю. Поленился сразу обновить Gist на GitHub, а теперь забыл где последная версия стоит. Руки не доходят повторно фиксить багу.
2. Да, очень похоже на правду.

Спасибо.
avatar
Вот кстати github.com/webber12/customTables сделал то, что тут расписывал с отдельными таблицами (в конфигурации плагина задается через запятую номера шаблонов, документы из которых пишутся в отдельные таблицы) плюс туда же дописалось контроллер customTables для DocLister и фильтр ct_filter для него же — для работы с этими таблицами как в админке, так и вне ее (в том числе поиск в админке). Немного подправил плагин и сниппет route, Cresource и дописал класс modCustomTable для MODxAPI — для работы опять же с этими таблицами.

Так что если кто осилит потестировать — милости просим :) За дельные советы — отдельно спасибо будет )))
avatar
не могу понять docURL.


"edit":"index.php?a=27&id=",
"new":"index.php?a=4&pid="


27 и 4 — что?
avatar
Для всех пессимистов и ответа на вопрос «нафиг это все нужно» (customTables) — запустил тестовый сайт.

Исходные данные:
579,903 объекта недвижимости (каждый с 26 доп.параметрами)
349,939 объекта доп.услуг (каждый с 18 доп.параметрами)
109,998 объекта новостей
Статистика времени и потребления памяти — в нижнем левом углу.

Решение возможно и не идеальное, возможно что местами и дырявое (как и большинство решений modx) — но главное демонстрация сути :)
avatar
а фильтры на чем сделаны?
avatar
Понятно, что не автофильтром — вряд ли он больше 2000 ресурсов потянет фильтровать. Фильтры DocLister, синтаксис идентичный, только вместо tv надо писать ct — для кастомной таблицы.
avatar
Сегодня пробовал через filters но так и не получилось завести что б работало
или А или Б и или С или Д
А, Б — 1ТВ
С, Д — второй ТВ

работает почемуто или всегда ИЛИ
или всегда И
avatar
не очень понял где и что именно «заводилось». Если на тестовом сайте — то там 2 пары и есть — 1: аренда или продажа/покупка, 2: спрос или предложение. Или мы о разных вещах? :)
avatar
Поставил плагин и пропало дерево ресурсов, modx 1.0.14-d6.9
скажите что сделать?
avatar
Похоже, при копировании кода плагина в поле админки попал открывающий тег
<php
если его убрать и удалить файл кеша assets\cache\siteCache.idx,
то все должно заработать по-идее
avatar
Пример из дампа работает отлично.
Но после установки с GitHub на MODx 1.1b-d7.0.16 выдает пустую таблицу
Похоже, не видит конфига.
Кто сталкивался — делитесь опытом
avatar
Я развернул дамп сайта, но он не совпадает с тем, что на видео.
Там нужны еще какие-нибудь настройки?
Недозапускается плагин, при нажатии кнопки просмотр, на новостях, отзывах. Заголовки колонок, кнопок есть, оформления и содержимого нет.
Комментарий отредактирован 2014-11-19 09:56:50 пользователем belkaU
avatar
В дампе устаревшая версия. Обновите DocLister и сам CResource.
avatar
Спасибо, что отвечаете в топике.
Я не очень хорошо разбираюсь в программировании, но Ваш модуль мне кажется полезным и перспективным, поэтому я хотел бы собрать по нему Вики, или хотя бы просто актуальную инструкцию, так как мне все ещё не удалось его запустить.
На локальном сервере дерево документов просто не реагирует на плагин.

В онлайн версии (не на вашем дампе, а просто сайте, с установленными плагинами и сниппетами) загружается уже новая, красивая шапка, как в видео, но не выводятся документы, написано, что их 0. Из конфигурационных файлов не понял, почему могут отсекаться дочернии документы папки, зависит ли это от шаблона или других настроек.
В чеи может быть причина?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.