iCMS 2.0 - предложения

флуд

lokanaft, вы говорите уже об узко специализированных решениях.

Каталог автомобилей: коробка передач есть? -есть, тогда сколько передач? -5, но это поле не нужно для автоматов и уж тем более электромобилей и не должно быть возможности даже попытаться ввести кол-во передач, если я уже выбрал в фильтре автомат.

Вы представляете себе как должен выглядеть интерфейс, в котором можно было бы настроить такую логику, причем универсально? Я вот слабо. В реальной жизни в большинстве случаев не требуется настолько доскональное соблюдение всех зависимостей. А там где требуются — создаются специализированные решения, в которых эти зависимости обрабатываются на уровне кода, а не настраиваются в админке.

Я считаю что управление контентом в 2.0 сделано намного гибче и мощнее, чем в большинстве других CMS. И будет улучшаться еще и еще. Но это не означает что мы получаем волшебную палочку для всего сразу.

Зависимые поля в том или ином виде появятся, но такой магии про которую вы пишите все равно не будет, это очевидно.

lokanaft, и буду признателен за ссылку на движок где реализовано все то, о чем вы говорите. Чтобы посмотреть как это может выглядеть.

Возможно ошибаюсь, но...

Сейчас реализована(во 2 бета версии) зависимость выводимых полей в окне регистрации, в зависимости от группы пользователей (которая выбирается в этом же окне и подгружается ajax)

На сайтах объявлений авито и подобных, при заполнении формы объявления, поля подгружаются в зависимости от выбранных ранее значений полей.
Возможно достаточно будет использовать уже имеющуюся логику из компонентов пользователи и регистрация в компоненте контент. Может расширив настройки категорий контента до настроек компонента пользователи?

А как будет дело с внешним видом новых типов контента, можно ли будет его настроить на свое усмотрение внеся некоторые правки в css с добавлением, например, префикса типа контента? Так как если внешний вид блогов будет аналогичен статьям, то визуально различать эти типы контента придется исключительно исходя из набора полей. И как будут реализованы настройки блогов их пользователями, кроме настройки просмотра "Для всех", "Друзьям", "Персональный", там настроить фон, шапку блога, персонализировать блог? И можно ли будет подписываться на новости блогера по rss или непосредственно на самом сайте? Будет ли в этой версии аналог "Добавить в закладки на сайте", как это вроде как планировалось сделать стандартным компонентом на версиях 1.10*? Ведь, по сути, блоги — это инструмент самовыражения пользователя, его возможность заявить о себе к тому же, как о человеке со вкусом. В ЖЖ хорошо уловили этот момент, мечталось бы увидеть и на инстанте подобные возможности :)
Ох, сколько вопросов набралось по блогам… )

lokanaft, и буду признателен за ссылку на движок где реализовано все то, о чем вы говорите. Чтобы посмотреть как это может выглядеть.

Простите, не мне вам давать советы, но может стоит предоставить lokanaft возможность реализовать эту "зависимость" волшебную? Вдруг сделает? Битрикс заплачет!

Простите, не мне вам давать советы, но может стоит предоставить lokanaft возможность реализовать эту "зависимость" волшебную? Вдруг сделает? Битрикс заплачет!

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

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

так я ж и говорю, пусть не говорит, а сделает (простите за тавтологию)

пусть не говорит, а сделает

Я то сделаю, но навряд ли это будет: "держите, благодарности не надо"

Это недоработка или пожелание, но зачем обязательно писать в шаблоне?
просто
не работает… А хотелось бы :)

пусть не говорит, а сделает

Я то сделаю, но навряд ли это будет: "держите, благодарности не надо"

1. за такую реализацию я лично заплатить готов, если где-нибудь понадобится
2. тогда нафига требовать у кого-то бесплатно?
3. очень надеюсь, что вместе с вами полку разработчиков, подчёркиваю разработчиков, а не вымогателей прибавится. Просто обсудите с r2 возможность и условия участия в разработке.
Пишу этот опус лишь по одной причине, нам всем очень нужен девайс в виде настраиваемых зависимых полей. Хотя, вы и сами это понимаете…

Просто обсудите с r2 возможность и условия участия в разработке.

Товарища r2 лучше сейчас не беспокоить по пустякам

тогда нафига требовать у кого-то бесплатно?

Я лишь указал проблему.

Ну, а денежки то собирать на проверку движка будем?
Пока наберем, пока протестируют...
Что бы уже все нормально было, а то потом начнут вопросы по безопасности подниматься.

добавлю свои пять копеек

1)думаю нужно разделить хранение полей контроллеров и полей форм(точнее на основе полей контроллеров создавать поля форм). Хранить информацию в БД, для скорости генерировать текстовые описания полей в кеше полей. Использовать оттуда, при изменении набора полей в графическом интерфейсе — перекомпилировать файлы полей в кеше.
Т.е. еще раз повторю, в графическом интерфейсе все один раз настраиваем, потом "компилируем" текстовые описания полей — дальше все быстро работает
еще, убрать динамическое создание каждого поля array( new stringField… пусть один класс генерит описание сразу всех полей формы, зачем столько вызовов new?

2)как вариант, сделать таблицы "Категории" (там будут все категории всех контроллеров) и таблицу "Описания структуры категорий" (см. мой первый пункт) Между категориями можно сделать связи (да эти самые связи) — сам пробовал делать, вроде получается
— здесь как вариант опишу
Контроллер Доска объявлений
подкатегория Квартиры — описание полей квартир — фильтр появляется с полями для этой подкатегории
подкатегория Авто — описание полей автомобилей — фильтр появляется с полями для этой подкатегории
зависимые поля тоже делаются на ура (даже при редактировании записи появляются в порядке выбора зависимых полей при создании записи)
То же самое с блогами, статьями и т.п. только полегче уже...

3)в качестве хранения данных сделать класс DB в котором при инициализации будет вызов factory — т.е. выбор движка хранения данных. Кстати есть хорошие нереляционные СУБД, в которых удобно хранить таблицы с переменным числом полей. В mysql для этого приходится немного "извращаться"
4)как следствие третьего пункта и ради защиты от "криворукого" стороннего разработчика, предлагаю запросы к БД делать с помощью параметрических функций, а ля sprintf(). Соответственно, записать данные другого формата в поле уже не получится (или они отфильтруются)
т.е. запрос query("insert into $t (id,name) values (2,"lalala") будет что-то вроде этого
query('insert into #t (id,name) values (#n,#s)','cms_content',$id,$name);


Соответственно, можно спрятать в реализацию этого класса чтение и запись в совершенно другую СУБД (но это мои чисто теоретические размышления 😊 )

Друзья, я прошу прощения — не нашел ни где, а дата в статье где выставляется? было бы прекрасно делать отложенную публикацию, Дата + Время.