У замовника є продукт, з яким він наразі працює.

Проте, у зв’язку зі зміною дизайну та потребою власноруч оперативно робити у ньому зміни, а також для зручнішої роботи з даними, стало питання переробки двигуна проекту, заодно з’явилося питання розміщення проекту на хостингу, а не на VPS (як зараз), без погіршення якісних та швидкісних характеристик проекту, а з покращенням їх замовник знайшов вашу CMS, в частині функціоналу вона його влаштовувала як основа, також влаштовувала ціна за ліцензію та написання нового модуля.

Звертаю вашу увагу на те, що якщо буде зроблено під нас окремо модуль імпорту, то значна частина роботи через інші інтерфейси адмінки перекривається, бо файлами імпорту можна задавати (змінювати) майже все (тобто швидкодія адмінки буде не критичною).

Ще один модуль - це формування статичних (напівстатичних, тобто частина даних буде формуватися динамічно при звертанні до сторінки) сторінок, файлів та даних для наповнення напівстатичних сторінок на основі шаблонів.

Система (мова про версію 140323) у тому вигляді, як вона є, ніяк не може влаштувати ні мене, ні замовника.

Тобто два модулі потрібно буде написати, проте, думаю, у виграші залишитеся і ви, і ваші клієнти, тому що ваша адмінка стане кращою, ніж в конкурентів, і не потрібно буде показувати в процесі завантаження сторінки ніяких цяцьок, бо вона буде віддаватися одразу. Думаю, що час формування напівстатичних і статичних сторінок зі смарті можна значно скоротити, якщо знайти правильний підхід до використання SSI та кешування певних наборів тих самих даних, які використовуються для формування сторінок. Зі знаходженням оптимального підходу потрібно буде експериментувати, але воно того варте.

Щодо таблиць, не знаю як зараз, а раніше наявність нульових значень в таблицях сповільнювала роботу баз даних.

У вас навіщось в таблиці про товари знаходяться і яндекс і вконтакті і багато чого іншого, хоч, як на мене, варто це робити окремими таблицями - є обов’язкові дані по товарах, а є ті, які можуть не використовуватися.

Тобто систему я бачу як кістяк + модулі, є потреба працювати з яндексом - включили модуль - створили відповідні таблиці, закінчилася така потреба - виключили модуль - видалили відповідні таблиці.

Приемні речі

Сподобалися змістовні пояснення до написання свого коду для вашого продукту.

Стосовно нової RC-версiї

Прошу додати до тестового показу рубрику(и) з кількох сотень товарів, щоб можна було оцінити швидкодію нової платформи.

Я радий, що ви розвиваєтесь :)

А чи можна зробити у демці вивід на одну сторінку категорії кількох сотень товарів чи геть усіх, бо 10 на сторінку занадто мало для оцінки під наші потреби.

Питання

А якщо інформація про товар буде виводитися на сторінці категорії у наступному вигляді (тобто туди будуть додаватися дані про властивості):

<div class="PCI-hidden PCI-fitered"
        data-productID="00010"
        data-productAddUrl="/p00010-add-uk_pageAddURLSuffics.html"
        data-productUrl="/p00010-uk_pageURLSuffics.html"
        data-productAvailability="1"
        data-productPrice="1000010"
        data-brandUrl="/b001-uk_pageURLSuffics.html"
        data-brandName="Kratki"
        data-productProducerName="Amelia"
        data-p-sklo="пряме"
        data-p-d="100 мм"
        data-p-color="брунатний"
        data-productName="Чавунна топка Amelia"
        data-properties='{"Властивість 1:":"дані 10438","Властивість 2:":"дані 2","Властивість 3:":"дані 3","Властивість 5:":"<a href=#>дані 5</a>","Властивість 1:":"дані 1","Властивість 2:":"дані 2","Властивість 3:":"дані 3","Властивість 5:":"<a href=#>дані 5</a>","Властивість 1:":"дані 1","Властивість 2:":"дані 2","Властивість 3:":"дані 3","Властивість 5:":"<a href=#>дані 5</a>","Властивість 1:":"дані 1","Властивість 2:":"дані 2","Властивість 3:":"дані 3","Властивість 5:":"<a href=#>дані 5</a>"}'>
</div>

на скільки повільніше буде формуватися сторінка каталогу?

Швидкість сторінок

demo.imperacms.com/products?show_all=1 - надто довго обробляється запит, як для простого відсікання, у випадку, якщо такий запит не передбачений.

demo.imperacms.com/products/page_28 - не змінюється нумерація-навігація у випадку бази на >4000 товарів - в шаблоні Мінімаліст чомусь передбачено лише декілька перших кнопок навігатора, таким чином на сторінці наприклад 29 (індекс 28) продовжують показуватися ті ж самі перші кнопки навігатора.

Це можливе рішення щодо зменшення кількості запитів до серверу для пришвидшення завантаження (можливо зараз воно є десь новіше) - hunlock.com/blogs/Supercharged_Javascript

Трошки новіше рішення - code.google.com/p/minify

Щось подібне використовується на існуючому у нас проекті для файлів css, js. Це може бути також однією з переваг вашого проекту.

А у випадку шаблону Мінімаліст ви можете пришвидшити настання події DomContentLoaded, якщо скрипти та стилі вставите безпосередньо у тіло сторінки зручним вам способом (не окремими файлами), цим самим зменшите кількість запитів на 2 та пришвидшите початок відображення сторінки.

А ще не зрозумів чи кешуються на стороні серверу сторінки каталогу, якщо зважати на те, що ціна змінюється раз на день, нема потреби формувати їх щоразу.

Побажання до властивостей

В дизайні інколи важливий порядок виведення властивостей, яких для кожної категорії товарів може бути довільна кількість. У моєму випадку це порядок виведення основних властивостей згори сторінки товару та дозволених для показу на вкладці характеристик на сторінці товару та дозволених у якості фільтру на сторінці категорії у блоці фільтру.

Я це бачу реалізованим у адмінці на сторінці категорії товару на окремій вкладці (не на сторінці усіх властивостей).

Тобто порядок виведення властивостей категорії для будь-якої потреби, яка може виникнути. У моєму випадку таких потреб 3, а у когось їх може бути більше. Але у моєму випадку фактично це стосується категорії товару та товарів, належних їй.

Це може бути щось на кшталт трьох блоків, куди я додаю (мишкою перетягую) потрібні мені властивості зі списку усіх можливих для цієї категорії та мишкою перетягую у блоці властивості, щоб встановити порядок їх виводу у конкретному випадку.

Тобто можна дозволяти людині на цій вкладці чи окремо передбачити можливість створювати однотипно для усіх категорій блоки (довільну кількість) для вставляння відповідного коду в шаблони.

Ще одне: Думаю, що варто для властивості задавати тип, англійську назву для використання в шаблонах, внутрішню та зовнішню назви. Наприклад, мені буде зручно для однієї з категорій додати властивість «Габаритний розмір» типу «Розмір3» з одиницею виміру мм, яке в адмінці на сторінці товару матиме вигляд, наприклад,

Ш:______ В:________ Г:__________ мм

для економії місця, зручності та адаптивного дизайну адмінки. По суті у даному випадку це три властивості, об’єднані зручним виводом в адмінці. Типи ходових полів можна попередньо визначити.

З мого досвіду: прив’язування однієї властивості одразу до багатьох категорій призводить до певного роду проблем. Тому я вважаю за доцільне мати для кожної категорії свій унікальний набір. Тобто властивість «ширина» в одній категорії ніяк не пов’язана з властивістю «ширина» іншої, тобто вони мають різні внутрішні ID.

Принцип: одна властивість - одна категорія.

А ще достатньо важливим є порядок виведення властивостей товару для заповнення їх в адмінці на сторінці товару.

Статті

Пробую створити нову статтю на демці. Відразу не сподобалося автоматичне заповнення полів (meta title, meta keywords, meta description) - для мене це дуже дурний тон вирішувати за мене куди та що заповнювати, і мене це дратує.

Якщо робити механізм прив’язування статті чи усього іншого, то як на мене потрібно виходити з логіки Де саме має що показуватися. Якщо на сторінці бренду чи категорії товару мають показуватися заголовки статей, то для бренду чи категорії потрібно вибирати набір статей, які там мають показуватися, а одна стаття могла б показуватися для кількох категорій чи брендів, а у вас в інтерфейсі я не побачив такої можливості вибору.

Що я хочу бачити в інтерфейсі замість існуючої реалізації:

Для каталогу, бренду, товару і таке інше: таб для кожної одиниці додаткової інформації (блоку) на відповідній сторінці, де можна було б вибирати що саме показувати для кожного блоку.

На сторінці статті (одиниці додаткової інформації): таб з інформацією про те, де саме ця інформація показується: відповідна сторінка категорії, бренду, товару - але не можливість редагувати показ статті на певних сторінках.

А от якщо я хочу показувати на сторінці статі блок товарів, то саме на сторінці цієї статті я маю вибрати що саме показувати (товари певної категорії, бренду, набір кодів товарів, у майбутньому товари певної властивості).

А на відповідних сторінках адмінки для категорії, бренду, товару : таб з інформацією про пов’язування з певною статтею, новиною чи таке інше.

Причому таблиця прив’язки - незалежна. Тобто таблиця статей, категорій, брендів, товарів не несе інформації про прив’язку.

А якщо казати про виведення інформації в табах адмінки, то ресурсозатратну інформацію туди можна було б завантажувати ajax-ом після того, як людина клацнула на той таб. Я вам цим хочу нагадати про ролі-інтерфейси адмінки під різні задачі - у кожному випадку потрібно показувати лише певний набір інформації, а не геть все зазвичай.

А якщо казати про наш проект, то є сенс лише показувати певні товари на певних статтях, а не навпаки - бо ми займаємося продажем, а не навчанням :) Тобто мета, щоб люди переходили на сторіку товару, а не втікали звідти.

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

Меню

Мені не подобається у вашій адмінці те, що наліплено в купу те, що не повинно ліпитися жодним чином. На мою думку МЕНЮ, не важно які (верхні, нижні, бокові, та які завгодно), це окремі елементи ДИЗАЙНУ, а не ознака категорії, бренду, новини, товару чи статті. Ні в я кому випадку не треба на сторінці товару, категорії чи бренду давати інтерфейс для прив’язування їх до меню.

Каталог - це товарна структура. А виведення каталогу на сторінках та зручність роботи з ним - це зовсім інше.

Якщо когось дуже цікавить куди який елемент прив’язаний, для цього можна зробити відповідний таб для показу - не редагування.

А для створення довільної кількості меню повинен існувати окремий інтерфейс, як це зроблено у тому ж вордпресі, де людина може вибрати де, що і в якому порядку має виводитися. Один елемент можна ліпити до якої завгодно кількості меню під різними назвами, залежно від потреб. Ця проблема загальна для теперішньої логіки роботи вашого продукту.

Я пропоную вам кардинально змінити те, що є наразі в частині прив’язувань, та відділяти «котлети від мух»: є інформація про товар, а є сторінка товару.

Тобто є єлементи. Елементи можна зв’язувати одне з одним. Для роботи з прив’язкою певних елементів до інших можуть існувати окремі інтерфейси. Наприклад, якщо я хочу прив’язати до статті товари (об’єкт тип Зв’язані товари), то на окремому табі повинен бути інтерфейс для прив’язування певних товарів до цієї статті. Таких об’єктів того ж типу для одного елементу я можу створити кілька.

Прив’язування ОДНОСТОРОННЄ. Мені може закортіти показувати на сторінці елементу кілька блоків товарів з різними властивостями чи в різних дизайнах. Це можуть бути товари, які належать до певних категорій, брендів, мають певну властивість чи перелік ID товарів - це по суті набір властивостей товару у моєму розумінні властивостей, до яких відноситься і ID, тобто можна записати що показувати логічним виразом, а вже в шаблоні буде прописано скільки з того масиву елементів показувати і які з блоків прив’язки, які існують для цього елементу.

Якщо ж я хочу прив’язати до товару певні статті, аналогічно повинен бути інтерфейс прив’язування статей до товару за певною ознакою: рубрикою, ключовим словом і так далі.

Тобто якщо я хочу щось до чогось прив’язати, то на сторінці елементу з відповідним ID повинен сам свідомо створити таку прив’язку відповідного типу, щоб її інтерфейс показався на сторінці конкретного елементу в адмінці.

Тобто початково усі елементи не прив’язані і мають прості інтерфейси сторінок без інтерфейсів прив’язок елементів. При формуванні сторінки в адмінці конкретного елементу перевіряється, чи до нього щось прив’язане і виводиться інтерфейс сторінки відповідно до прив’язок.

Те саме варто зробити з ролями-інтерфейсу, щоб не засмічувати інтерфейс не потрібними в даний час для робити елементами інтерфейсу та полегшити сторінки.

Щодо властивостей

Одним з варіантів організації роботи з властивостями товарів може бути наступний, зважаючи на те, що у категорії товару можуть бути неоднотипні товари з різних на те причин.

Створюємо набори властивостей, які не відносяться ні до категорій, ні до брендів, а існують самі по собі і розраховані на певний тип товару.

Набір властивостей - це елемент (об’єкт), до якого можна підключити варіанти його виводу на сторінці товару чи для організації роботи фільтру на сторінці категорії.

Товар може мати лише один набір властивостей.

Не повинно бути якогось загального списку усіх властивостей, може бути лише список наборів властивостей. Тобто властивість можна створити лише у наборі властивостей.

У цьому випадку, якщо товар переноситься в іншу категорію, його властивості нікуди не діваються, оскільки не прив’язані до категорії.

Ваша CMS може бути як завгодно універсальна, але повинна налаштовуватися під потреби кожного клієнта: інтерфейс back-end (адмінка), таблиці та поля бази даних. Спробую нижче дещо описати.

Усе, що бачить відвідувач на веб-майданчику (front-end) показується на сторінках, але сторінки можуть бути геть різний вигляд для кожного її типу, який призначений для виведення певного типу інформації. Сторінки виводяться на основі шаблону, у який потрібно підставляти відповідні дані. Ці дані можна брати з відповідного об’єкту Page. Наша задача додати в об’єкт потрібні для виведення дані.

Загальне для сторінок те, що вони мають певний мінімальний набір даних, які потрібно виводити.

Назвемо цю сторінку Проста сторінка (Simple page) і створимо відповідний їй клас SimplePage. Тобто зазвичай об’єкт Page типу SimplePage матиме клас SimplePage.

Simple Page

Page Keywords

Page Publication Date

Присвоювання класів об’єкту Page відповідного типу повинно робитися через адмінку, щоб адміністратор міг налаштовувати інтерфейс під потребу конкретної задачі.

Крім того можна передбачити можливість налаштування порядку виведення доступних для об’єкту Page відповідного типу елементів форми на сторінці адмінки перетягуванням.

Тобто у шаблоні адмінки для сторінок об’єкту Page не задані жорстко поля, натомість вказується функція, яка залежно від присвоєних об’єкту Page класів буде виводити відповідні елементи в зазначеному порядку.

Уявімо, що нам потрібно виводити на сторінці користувацької частини на додаток до основної інформації ще певну інформацію, пов’язану саме (тільки) з цією сторінкою.

Для прикладу на сторінці статті це можуть бути інші статті, які мають певний набір ключових слів чи зазначені нами статті чи статті за певну дату. Тобто мова наразі йде про об’єкти Page типу Article. Тобто об’єкти того ж типу.

Articles Page Connect

На сторінці адмінки цього об’єкту з’являться елементи форми для пов’язування інших статей з цією. Це може бути поле для логічного виразу, а для тих, хто не розуміється на логічних виразах, окремо поля для ID статей, ключових слів.

Так само ми можемо дозволити прив’язування об’єктів Page інших типів, присвоюючи відповідні класи у разі потреби.

Якщо вас зацікавило моє бачення, я можу продовжити його викладення.

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

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

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

Короче, что я хотел сказать - если бы каждый начал описывать базу для своих целей, тьфу. А топик стартер не понимает что есть шаблон. От шаблона зависит будет вордпрес, виртумарт, магента, импера, битрикс, джумла, престашоп и пр. удобным.

Потом удобство у каждого ведь разное. Одному тайтлы авто заполняются в радость, другому все аяксом только, третему шоб уздеся отакая менюха вычвыкавалась по удару кувыкалки. И всем не угодить. Для того существуют шаблоны.

А вопрос про data- в дивах вобще жесть.

<div {foreach $prop as $name => $value} data-{$name}="{$value}" {/foreach}></div>

Та же самая скорость смарти что

<div>
    {foreach $prop as $name => $value}
        {$name}: {$value}
    {/foreach}
</div>

А смарти вы незнали что, кеширующий шаблонизатор. О каком бреде вы говорите - ssi. Короче, учите матчасть, после о видениях говорите.

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