#511 losdriver:
И так хотелось бы узнать в ответ на ваши коментарии в отзывах, чем же плагин такой особенный и какие сотни задач решает? Я то понимаю, что - что-то он там делает с эекстраполями, а что и как - не представляю к сожалению
Доброго!
Сижу и туплю, гадаю, - почему мне в оповещение на почту не пришло уведомление о вашем сообщении на форуме, - забыл подписаться в личном кабинете на обновления.
Ладно, к делу! Скажу прямо, если вы не разработчкик, - мой ответ врядли вам чем-то поможет, но тем не менее, постараюсь кратко ответить.
Идея даже не плагина, а вообще имено необходимость дробления таблиц БД на "блохеры и подписчики" (реляционная модель) лежит на стыке ряда нестандартных задач, с которыми, крайне сомнительно, вообще какой-то движок сайта или супер-пупер дорогая 1000 раз взломанная CMS могла бы справиться настолько просто и безболезненно, а именно:
1. Сайт на Котонти, используются все штатные основные модули (статьи, форум, опросы, личные сообщения) + модуль витрины товаров - нужно вывести кастомизированные заголовки и описание в браузер, что бы скормить их поисковикам. Для этого пришлось выполнить:
а). отдельный header.tpl если мы на странице товаров или в списках (внутри категории) (дифференциация пользовательских шаблонов);
б). снова мета-описание и заголовок, но уже переведеный на язык товара - модифицировали плагин "i18n", но конкретно под товары,
в). переведенные "штатно" заголовки и мета-описания по размеру и содержанию, не подходят для вывода на странице товара пользователю и браузеру в исходный код. Если товар называется "Автомагнитола бабинная «Электроника-308» с батарейками" то согласитесь, выводить на странице, пользователю "Купить автомагнитолу в Сингапуре за восемь баксов, цена со скидкой" - немного тупо, поэтому для плагина мультиязычности реализовали экстраполя, куда размещаем эти кастомизированные, уже переведенные строки с призывом к действию и выводим уже затем в свой отдельный header.tpl.
г). Дифференциация: названия товара, заголовка в браузере и заголовка на странице товара — что решает «специализация».
- Название товара - основной его текстовый "идентификатор" - он краткий в списках товаров (не выступает в огород к соседу и сам не ложится на три строки в своем);
например:
Автомагнитола бабинная «Электроника-308» с батарейками - Мета-заголовок товара - первая строка в списке искомого обьекта в поисковиках. Он же в названии вкладки браузера. и по правилам должен быть кратким (примерно 50-55 символов), но осмысленным, можно добавлять призыв к действию "Купить", "Получите скидку на .." и т.д.
например:
Купить «Электроника-308» Автомагнитола со скидкой 20% - Заголовок товара на собственно своей странице товара - тут уже можете его разогнать и обойти ограничения, которые ложатся на SEO-заголовок или название товара в списке, - (Расширенное название)
например:
Автомагнитола «Электроника-308» на бабинах 12 дюймов, в подарок пачка батареек и три колонки с бензозаправки.
д). все дифференцированные заголовки мы нашли как положить в локализированные версии (переводы) - в экстраполя модифицированного под товары плагина "i18n", и под расширенный заголовок создали экстраполе в модуле товаров, но в дополнение к расширенному заголовку, нам понадобилась куча дополнительных полей, которые также требуют своих переводов на другой язык (для туристов и приезжих работать):
- цена в долларах;
- наличие;
- Бренд/производитель;
- Период акции;
- Размер скидки;
- стикеры;
- и еще штук 15 минимум...
Забегая наперед, скажу, что даже встречал, когда в таблицу товаров пихали эмейлы в одну колонку и телефоны в другую, всех, кто купил товар.
Ну как? лупить это всё в одну таблицу товаров - это норм??? - физически то можно, но управлять такой организацией структуры таблицы БД - будет крайне не приятно, - "ломаются" не только глаза, но и вы порой уже забудете, что конкретно искали. И товары это всегда тысячи строк в БД.
Вот здесь и было решение - создаем отношения - "матери и дочки" - они между собой "коннектятся" - сообщаются, иногда ржу с подколом, и называю "блохеры и филоуверы".
Показываю на пальцах:
1. Создали товар - объект с уникальным идентификатором. (мать)
2. Объект имеет наследуемые характеристики и свойства (условно, - 4 дочки, по 7, 9, 11 и 12 лет с разным характером и размером одежды, да еще и в разных школах)
3. Мать же не таскает их везде с собой, - на работу, к подругам, в ванную, туалет или еще с десяток мест? - Правильно, все собираются по какому-то условию или событию - семейный ужин, генеральная уборка или поездка на отдых. Нет смысла, вот везде всем быть в одном месте - катастрофа неизбежна.
Точно также с нашим "Объектом" - он может иметь свои 20-ть "детей" - поля с информацией о цене поставщика, наличие, период скидки и еще 15 штук свойств и характеристик, которые нет смысла всюду, всегда и везде таскать с собой, а собирать вместе по конкретному условию и событию, и заметьте, - всегда сохраняется отношение, то есть принадлежность - соседские дети на отдых с нашей мамой не поедут.
4. Когда у нас уже есть 20-ть "детей", которые ссылаются на одну “маму” - мы строим новую структуру - для каждой дочки шьем костюм - переводы этих значений на другие языки, для реальных туристов или трудовых мигрантов, которые на своем родном языке, но в нашей стране ищут товар через поисковые системы.
Вот так и родилась идея плагина “Custom Extrafields” - у каждого объекта свои наследуемые поля, и вам не нужно под каждый тип данных (цена, время и дата, текст, выпадающий список, радио-кнопка и т.д.) писать снова новый плагин, и снова новый код - всё уже написано и довольно прекрасно реализовано в Cotonti средствами "API Extrafields". Для меня лично - да, создание плагина еще как оправданно, и скажите спасибо что он бесплатный.
И очень надеюсь, что ответил на ваш вопрос
"чем же плагин такой особенный и какие сотни задач решает?".
