Ну потенциально что-то ж должно анализировать эти XML-шаблоны и переводить в какой-то другой язык, который будет работать на веб-сервере.
Я не говорил, что нужно делать запрос в базу. Речь, скорее шла о том, что усовершенствование функции конвертации этого массива - это "оптимизация на спичках" и она на этом этапе вообще не важна. Ибо с большой вероятностью у него компилятор или как это назвать будет виснуть на циклической обработке шаблонов, когда нужно будет заходить внутрь.
А ещё вдруг понадобится передать состояние от родительских шаблонов вовнутрь, а такая задача может всплыть даже для минимальных сайтов, то его стройная система рекурсивных вызовов шаблонов рухнет и нужно будет костыль на костыле прикручивать. А ещё условия и т.д.
Я всё больше и больше убеждаюсь, что человек строит React.js или подобный фреймворк, но на другой основе. И теоретически он может это сделать (не будем здесь брать во внимание количество человеко-десятилетий, которые на это нужно затратить), но основная проблема, что не имея опыта, он не понимает, что его продукт рассчитан на разработчиков. Потому, что обычный человек не поймет логику передачи данных от блока к блоку + формирования XML для этого.
Моя рекомендация - пусть напишет небольшую инструкцию, найдёт человека, которому нужен сайт и сядет рядом с ним и пусть тот составит XML для нужного ему сайта без подсказки, просто используя ту инструкцию. Без бэкенда, чтобы не тратить время на разработку, просто XML. Это будет опыт работы с реальным пользователем, он покажет насколько работоспособен такой вариант и как люди его понимают.
это "оптимизация на спичках".
Вы можете представить себе простого пользователя (например, директора предприятия), который разберётся в вашем XML и настроит, например, разный вывод финансовых данных на каком-нибудь дашборде разный для директора, для отдела продаж и для конкретного продавца?
Premature optimazation is the root of all evil (c) Tony Hoare + Donald Knuth
Опыт показывает, что неоптимальные места обычно не там, где думает программист. Да и часто устранить "боль" пользователя - это решить проблему, а не ускорить цикл на четверть десятых секунды.
Какую проблему создавал найденный код, что она мешала завершить проект и пришлось улучшать код?
Есть такой термин "оптимизация на спичках", случайно это не тот случай?---------- Добавлено 08.11.2019 в 21:13 ----------
Если это фреймворк, то наилучший способ это выложить код на Github и получать пулреквесты. А уже на основе фрейворка строить бизнес - CMS или же разрабатывать проекты. Я бы лично не заказывал что-то на малоизвестном фреймворке, разработчиков под который днём с огнём не сыщешь. Даже, если в нём очень оптимизированный метод сохранения массива в файл.
У вашего проекта - две проблемы - малая известность и более-менее новая концепция. То есть, мне как потенциальному заказчику нужно будет оплачивать роботу программиста, который будет вникать как в код, так и в концепцию. А если у него сгорит винт, бабушка заболеет или кот переест корма и нужно будет сводить к ветеренару, то нужно будет оплачивать время другого программиста на время ознакомления.
Конечно, есть вы, но одновременно делать 100 проектов на одном фреймворке вы не сможете.---------- Добавлено 08.11.2019 в 21:17 ----------
Глянул на проекте - 33 бранча :) Нужно хотя бы поудалять исторически заброшенные, хотя иногда всплывает надобность, вот недавно пришлось смотреть в ветки несколько летней давности.
А пробовали статьи с другой тематикой подавать, может со здоровьем перестраховываются?
Lord Maverik, в cms_subscribe есть id подписок, которые не существуют в cms_subscribe_temp?
Если я правильно понял запрос
вы, кроме всего прочего, ищете записи в cms_subscribe_temp соответствия которым нет в таблице cms_subscribe. По крайней мере, LEFT JOIN используется в таких случаях.
Для чего он использован в рамках вашей задачи я не могу понять. Но я с SQL работал последние годы мало, больше с NoSQL (Mongo). С SQL только с PostgresQL (полнотекстовый поиск как замена сфинксу использовали).
Может я неправильно понял задачу, но, как мне кажется, вам нужен простой WHERE, без LEFT JOIN.
Я немного туплю, но можете объяснить для чего там LEFT JOIN? У вас в cms_subscribe_temp есть записи, которых нет в cms_subscribe и вы хотите сделать рассылку по тем, кто не подписался?
silicoid, ArbNet,
хм, выглядит как будто кто перепутал учетки и продолжил отвечать с другой :)
Maks01, а как форма обратной связи может быть на "на обычном html и css"?
Stek, ну, это да. Я первым делом решил был форум немного доделать, который нашёл в инете. В итоге чуть ли не с нуля его переписал. Правда, от этого он лучше в плане кода не стал. :)
Но общее понятие дало, как оно в вебе вообще всё работает.
Хотя сейчас бы, если начинать с нуля, то можно два варианта:
1) я взял бы какой-то фреймворк уже готовый и пробежался бы по мануалу по созданию чего-то простого, но готового на нём. Вхождение будет быстрее и, по-крайней мере, плавать в формулировках не будет.
2) онлайн-курсы на Udemy, Coursera или чем-то подобном.
У меня для одного проекта программер по как раз по реакту прошёл подобный курс, и я просил его пересказывать мне своими словами, после каждого значимого куска, чтобы потом хотя бы на общем языке смогли говорить :). Ибо js за последние годы ушёл вообще за горизонт. В итоге реально толчок дают такие курсы, даже если это вроде сходу и не заметно, но от преподавателя зависит, конечно.
