muhasa, значения можно хранить в отдельной таблице. Вообще, это известный шаблон проектирования EAV Я в своем текущем проекте храню значения атрибутов в JSON поле. Имея таблицы: продукты, группы продуктов (например, салат с ветчиной или с курицей имеют разную цену), атрибутов, связь атрибутов и групп продуктов, заранее заданные значения без повторений. Связь же таблицы значений и продуктов привязана к продуктам: {attribute_id: value(s)}, где значение может быть идентификатором из таблицы значений, списком идентификаторов или пользовательскими данными — зависимо от типа атрибута.
Никита Полевой, да, стоит попробовать такой вариант. Но в первую очередь важнее структура данных, а то, как построить форму, на мой взгляд, дело десятое и может быть решено разными способами.
Никита Полевой, самое простое, "в лоб", это выборка по условиям в статике *ngIf / *ngElseIf, если элементов-компонентов форм десятки, то есть смысл подумать о динамической подгрузке (это же может оказаться решением для иерархии, вложенных групп элементов). Думаю, да, ComponentFactoryResolver, вполне решение, и возможно не единственное.
Никита Полевой, обычно таким образом динамические формы и строят, например, для модели EAV в интернет-магазинах, где у разных товаров различный набор свойств. Если в Вашем случае формы хранятся как шаблоны, возможно это не лучший подход. Их ведь сложнее редактировать, чем структуру данных, описывающую форму. Для изменения шаблона его придется парсить в структуру данных в любом случае. Тогда как структура удобно ложится на многие движки. PS Если ответ выше устраивает, отметьте, пожалуйста, "ответом" на вопрос.
Dynamic Component Loading — речь идет только о собранных в JavaScript компонентах, и они должны быть загружены (и объявлены в модуле), а подгружать с сервера Angular может только модули, и они так же должны быть собраны в JavaScript. Возможно Вам удастся каким-то образом такие компоненты собирать налету в модули, на стороне сервера, но сильно сомневаюсь, что это верное решение.
Задача выглядит, мягко говоря, туманно. Что за формы? Нужен пример когда, часть пары форм на HTML и что Вы с ними хотите делать в обработчике на PHP. Могу лишь предположить, что Вы противопоставляете перебор значений в цикле — цепочке if / else if. Но, в любом случае, для 10 форм разницы в производительности не будет. Вы можете "прокрутить" тысячи элементов массива без особых проблем, если в итерациях не будет нагруженных операций, вроде обработки изображений или запросов к базе данных. В абстрактном общем случае, цикл лучше, если количество форм может меняться, если их число заранее определено, и формы разные, лучше будет использовать условия. Можно так же предположить, что задача изначально решается неверно (может 10 форм и не нужны?).
$klein->respond('GET', '/img/twitter', function () {
$response->file('/path/to/img/icons/Twitter_Logo_Blue.svg');
}
Но как и предполагалось, проблема конфигурации http-сервера (где Вы указали Apache не учитывать существующие файлы при пробросе запроса в Ваш обработчик index.php).
Вы выдаете изображение средствами фреймворка? Если нет, то задача касается настройки http-сервера, Apache / nginx или, возможно, настройки окружения (права доступа, например). Если средствами фреймворка, то приведите код, пожалуйста, каким образом выполняете отправку: $response->file(...) ? Также, приведите примеры ссылок и настройку маршрутов.
Смотрите возможности библиотеки, которой пользуетесь (или воспользуйтесь еще одной, для обработки HTML/XML), вырежьте блоки, в которых [только] IMG или IFRAME. Ну и наверное проще захватить сразу '.product__description'.
Антон Спирин, ощутимых плюсов нет, кроме тех, что вообще даёт SPA: скорость клиента, работа с API и некоторое снижение нагрузки на сервер, в ряде случаев, удобство построения UI. Проблема SEO - важный сдерживающий фактор и данное решение, пожалуй как и SSR, временный "оверхед"