Фреймворк SNDL

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

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

Я всё больше и больше убеждаюсь, что человек строит React.js или подобный фреймворк, но на другой основе. И теоретически он может это сделать (не будем здесь брать во внимание количество человеко-десятилетий, которые на это нужно затратить), но основная проблема, что не имея опыта, он не понимает, что его продукт рассчитан на разработчиков. Потому, что обычный человек не поймет логику передачи данных от блока к блоку + формирования XML для этого.

Моя рекомендация - пусть напишет небольшую инструкцию, найдёт человека, которому нужен сайт и сядет рядом с ним и пусть тот составит XML для нужного ему сайта без подсказки, просто используя ту инструкцию. Без бэкенда, чтобы не тратить время на разработку, просто XML. Это будет опыт работы с реальным пользователем, он покажет насколько работоспособен такой вариант и как люди его понимают.

А там он есть?

// заголовок для браузера

^ request(HTTPv)+" 200 OK"+>>;

^ "Content-Type: text/html"+>>;

^ "Charset: utf-8"+>>;

^ >>+>>;

рабочее. Что не факт, потому, что тут сказали 200, а пхп ничего не нашел и надо 404

И не для asp ли оно. Заметьте, не так

content-type: text/html; charset=UTF-8

а так

content-type: text/html

сharset: utf-8

судя по

Ну потенциально что-то ж должно анализировать эти XML-шаблоны и переводить в какой-то другой язык, который будет работать на веб-сервере.

Методы парсинга XML известны, в результате, это в терминах пхп ассоциативный массив или string после XSLT обработки.

Если ТС метнулся к var_export, то скорее, массив.

А куда дальше придем, видимо позже посмотрим.

Но, не отнять, что ТС идеями фонтанирует. И эти идеи... Иногда, вполне себе норм.

Это потому, что он про ООП не знает. Ладно, сюрприз будет (С).

Когда я был очень-очень маленький, то на спектруме написал нечто, что позволяло без знаний создавать журналы на дискетах типа спектрофон или зикс-форум. Про html тогда я ничего не знал, вообще не уверен, что он тогда очень был. Поэтому точил свое)))) На ассемблере, конечно, спектрум же, там альтернатив не особо) Наточил - никто не купил 😂 Зато потренировался и купил ума бесплатно 😂

я не о том как спарсить XML. У нас, например, вот эта библиотека используется https://github.com/prewk/xml-string-streamer, так как, насколько помню, стандартные отваливались уже на каких-то мелких XML-ях в 1000-2000 нод из-за нехватки памяти, а увеличивать под php-процесс бесконечно не хотелось.

Я о том как выполнить то, что описано в этих шаблонах:

От того, что он переведёт в массив - не поможет ему сайт запустить. То есть, нужно что-то что будет выполнять логику заложенную в XML. Формально нужен будет интерпретатор или компилятор, не знаю как это назвать, потока мысли потенциального директора в виде XML в то, что будет исполняться на сервере.

Если я правильно понял идею.

Это не для директора, откуда он будет знать, что где то есть класс меню:D

А в целом задача поставлена верно, на мой взгляд. Гибкая сборка хтмл, на основе различных данных. Но, вот решение:( Есть хтмл шаблон, в котором есть метка "контент", которая заменяется на нечто, собранное по правилам из хмл-файла. Не буду разубеждать - зачем хранить в хмл, если есть варианты получше. Скажу лишь, а зачем лишняя сущность - хмл. Самого шаблона достаточно, если документацию по шаблонизаторам почитать

#Twig:

{{ 2000 | price() | raw }}

#Php:

class TwigExtension extends \Twig_Extension

{ 

  public function getFilters()

  { 

    return array(

        new \Twig_Filter('price', array($this, 'formatPrice'))

        new \Twig_Filter('getComponent', array($this, 'cool_SNDL_method'))

        #...............

Ну или в задаче автора, что то типа

<body>

    Это содержание

    {{ "\\SNDL\\Menu" | getComponent() | raw }}

</body>

Определив в TwigExtension getComponent

Я не утверждал, что моя идея лучшая. Я стараюсь не оскорбить никого, а тех кто не понимает меня и называют дураком и тд. отвечаю соответственно. Есть фреймворки для веб-разработчиков. которые с костылями что-то с этими фреймворками собирают. Я делаю инструмент для простых людей, для создания ими своего сайта, такого какой они сами захотят, не на готовом cms и тд. Надеюсь мой фреймворк станет востребованным и накопится хорошая библиотека разных компонентов, тогда пользователь сможет и админку под свои задачи структурировать.

Оо да :) с него и у маня вкус к написанию своих программ появилась, интереснее было сделать что-то самому, нежели просто играть в разные игры.

Иногда ностальгия появляется и хочется сделать свой простенький комп с своим ПО, поглядывал на микроконтроллеры, на FPGA. В настоящее время это затратно и не актуально, но ностальгия бывает нахлабучивает и хочется что-то такое сделать.

Dreammaker, timo-71, Вот приятно иметь дело с людьми которые хотят разобраться и понять. Действительно в движке есть элемент интерпретатора, но упрощён, так как нет никаких команд, есть структура xml и обработка атрибутов элемента и всё. Относительно массива php я в них буду хранить настройки компонентов, чтобы при загрузке компонента инклюдился php, а не читался файл или база и потом унсерилизовывалось, так будет быстрее и удобнее ИМХО.

timo-71, что касается примера кода который я показывал, он к моему фреймворку не относится, просто я когда-то делал свой минисервер с своим языком и тд. Один из форумчан попросил показать синтаксис моего языка, короче забудьте, это к фреймворку не относится.

Но ум явно не приобрелся.