Это не соответствует теме в которой мы находимся. Секта в монастыре которой идет дискуссия - "БД не нужна, хватит и велика на файлах, а еще лучше статика генеренная бекофисом на другом хосте".
Покажите мне феррари)
Всё что я видел - УГ. Но не потому что много лишнего. Это пустое. А потому что не SOLIDно и "Мокро". Хороший двиг это тот в котором лишнее не мешает (отключается, не ставится - не важно), а нужное - легко дописывается.
Такое в паблике отсутствует.
Вашу секту мы знаем - больше ЖС хорошего и разного).
Имеет право на жизнь, но нет под это всё внятной экосистемы.
Всякие ангуляры это больше про фронтовые задачи, а не под логику за которой стоит голая статика.
Без обид. Но две секты в одной теме это каша.
Подход ТС имеет право на жизнь в своей (достаточно большой) нише. Ваш подход уноса максимальной части логики вьюва на клиент - имеет право на жизнь, в не меньшем объеме задач.
Но это сектантство. Сейчас еще я начну свой специфический взгляд на то как правильно готовить модели здесь толкать, и мы никуда не уедем)---------- Добавлено 26.12.2016 в 18:45 ----------
Решается на уровне покупки исходя из данных хранящихся в БД, но....
У ТС тонкий фронт. Очень тонкий. Одна статика да скрипт отправки заказа.
При покупке нам надо валидировать все возможные промокоды. Как? Отдать все варианты промокодов клиенту - дыра. Делать информацию в самих кодах зашифрованной? Часто хочется иметь читаемый код. Собственно всегда.... Отдавать клиенту массив валидных хешей от промокодов? Допустим в этом случае мы кое-как накреативили. Перегрузили локалсторейдж. Ну даже пусть не его, а файлик отдельный сделали, в общем накреативили. Но... наша "небаза" всё сложнее и сложнее. Завтра будет еще задача, и еще...
Медленнее чем можно было ждать.
Новый год + банкротство. Наверное были еще какие-то транши до национализации.
Да и "одолжил" это не докапитализация. Так что хрен его знает, но спасибо за новость. Я если честно ожидал что им нальют на счета НБУ (частично безналиком, частично грузовиками) ярдов 30 до НГ.
тсс... не пугайте человека, он же "почти дописал".
А что понадобится через пять лет - не считается.
Ну вот уже пяток вещей которые еще можно решить в полуголой статике, но уже костылями.
100.000 товаров две сотни атрибутов, 6 разных вариантов перелинковок (различные запчасти, также смотрят и т.п.), 5 видов цен, три-четыре способа доставки, пять методов оплаты, валидация адреса и стоимость доставки у нас считается сразу на сайте с учетом географии пользователя, размеров и массы товара, ну и метода доставки и метода оплаты (наложный платеж влияет на обоих, а также доставка в почтомат, отделение службы доставки, ускоренная доставка, курьер и т.п. переплетены между собой).
Нормальный, вполне себе типичный вариант магазина.
Не микро, но и не супер-космос.
Да, всего этого обычно нет в стоковых движках, но претензия именно к движкам а не к их размеру.
Ну вот простой магазин у клиента.
Манагеры, операторы, продаватели и закупатели, весь саппорт и т.п. - обитают в офисе в Москве.
Сеошник в Киеве, контент.манагер - Харьков.
Программисты - Одесса.
Админ - Винница.
Всем им с той или иной периодичностью приходится иметь доступ в бекофис.
Директолог еще из Киева (на момент старта проекта был из Донецка).
Может кого-то и не знаю.
Маркетологи конечно лохотронщики. Зачем этому магазину доступ онлайн? Ума не приложу. Пусть всё через тимвьювер делают :)
Здесь две проблемы в кучу.
1 - стоковая порнография. Это реальная проблема. Сток ужасен, особенно бесплатный, но и платный тоже.
2 - отделение витрины от ERP действительно неплохая идея с точки зрения безопасности и т.п. Минусом здесь только поддержка двух различных архитектур. Если у вас уже есть полноценный фреймворк, готовый набор моделек и т.п., то проще дополнить одну платформу кодом для витрины, и отдельно кодом для бекофиса, а не делать ВЕЗДЕ разные вещи. Ну есть у меня уже ORM. Зачем мне еще свой велосипед городить для фронт-витрины. Ну понадобится. Все равно понадобится. Попадется вам большой магазин в заказе и понадобится....
У вас получается большая собственная система ERP. которую нужно писать. Таких "из коробки" нет. У других ее нет. И многим оно не нужно.
Просто нет другого сервера (или локального компьютера с локальной 1С и отдельным софтом), отдельных тикет-систем, систем анализа статистики, обработки этих логов статистики, затягивание этого в вашу систему, генерации из этой статистики рекомендаций и т.п.
Тут два момента - либо у вас весь функционал магазина (то что обычно) сделан в отдельной ERP, либо половину от него вы вообще не используете. Зависит от задачи.
Но держать большой зоопарк разного софта удобно не всем. вернее никому не удобно.
В вашем случае уменьшение зоопарка получилось написанием своей системы ERP/CRM.
Другим проще иметь многофункциональный магазин.
Привязка к категориям и производителям вполне себе делается на стороне ERP если ERP своя. Вы просматривали - явно в локалстор или куках, рекомендуемые, акции и т.п. можно тоже в ERP. Их можно составлять банально из логов апача.
Параметры доставки/оплаты вполне могут быть настолько простыми что могут быть и захардкожены или уточняться уже менеджером в телефонном режиме.
Сделать можно всё, но это уж очень пахнет Fat Stupid Ugly Controllers.
Оно конечно не совсем оно, или даже совсем не оно, но сам подход очень сильно похож.
У вас есть база данных товаров, категорий, свойств и т.п.
То что вы ее храните в файлах не отменяет того что это база данных.
Итого реально у вас два разделения:
1а) Ваша база храниться на хостинге, и ваш движок генерирует из нее страницы.
1б) Ваша база находится в другом месте, движок магазина находится там-же, а на хостинге хранятся только статические страницы являющиеся грубо говоря "кешем" вашего магазина.
Здесь не важно где эта база заполняется и в каком формате она хранится. Важно что она есть.
Второе разделение:
2а) Использовать в качестве базы данных реляционные СУБД (в первом приближении сюда можно отнести и noSQL)
2б) Сделать свой велосипед на файлах.
Для простой витрины за которую всё делает "отдельная система с полноценной СУБД) вполне может хватить и своего файлового велосипеда.
Да, это усложнение, но возможно для какой-то задачи оно у вас и оправдано.
Минусы:
Собственный велосипед для файлов который нужно поддерживать,
Ограничение роста сложности витрины и необходимость уносить почти всю логику в отдельный сервис.
Плюсы вы можете написать сами.
У меня был кейс где такой путь казался уместным. Был основной сайт с полноценной системой учета всего, и был связанный с ним файлообменник.
Функционал ФО был минимальный, да добавить файл мог любой, но основное заливалось через отдельное АПИ, в виде уже готовых файликов и файликов-описаний. Через пару лет таки вернулись к единообразию с базой и т.п.
Сложность поддержки разных кодовых баз дорого.
Гы.
Вот за что "люблю" Приват, и видно любить его буду до конца, так это за их подход к работе)))
Поимел сегодня глюк с подписыванием платежки.
Менял сертификат ключика, то да сё... в общем где-то у них что-то глюкнуло.
Пару раз подписывал - писало что ок, подписано, всё гуд, но продолжает ждать мою визу.
Я аж перезагрузился. Не помогло. Полез в чат.
В чате в частых FAQ (да, FAQ, роботом, не человеком) мне посоветовали "добавьте или уберите пробел в описании платежа, и сохраните, а потом пробуйте подписать заново"). Так и сделал. помогло. Нет, не подумайте чего. У меня на диске лежит документ на 25 страниц. С описаниями багов и глюков Привата. В основном Приват24. В основном бизнес.
Меня тут улыбнул именно момент наличия такого совета в ЧАВО)))
ПС: формально моя ставка с поеданием карточки закончилась сегодня. Есть не буду (что давно очевидно, но я говорил о себе). Сегодня таки сделал платеж с юрика.
