Всем привет. Хочу сделать пошаговую регистрацию на сайте. Как бы это сделать правильнее?Нет рецепта для общего случая. Всегда есть нюансы, если вы делаете что-то чуть в сторону от классики.
1. После каждого шага сохранять в БД? Много запросов бессмысленныхОго, много это сколько? И почему бессмысленных? Вы же осмысленные данные туда пишете?
У кого, какое мнение? Где какие подводные камни/нюансы?Мнение: С таким описанием нихрена не посоветуешь. По конкретным шагам можно что-то обсуждать.
Это, например, два абсолютно разных проекта которые соединяются связью ? или это один проект, условный контейнер, и в нем создаются множество модулей ? что из этого реально является микросервисом и используется в реальности ?
view/layouts/main.php), второй для страниц с Vue (view/layouts/vue.php)view/layouts/vue.php нужно подключать JS скрипты, которые генерит npm start. Для этого открой исходный код страницы, которую раздаёт webpack и скопируй оттуда все подключенные <script>. Либо вручную, либо парсер напиши. Вроде бы у этих скриптов статичные имена, поэтому тут проще. Можно один раз скопировать и забыть.view/layouts/vue.php подключать финальные сжатые JS скрипты, которые генерит npm run build - тут сложность в том, что эти скрипты с уникальными именами всегда.
use yii\queue\redis\Command;
class RedisCommand extends Command
{
public function actionRun($channel = null)
{
if ($channel !== null) {
$this->queue->channel = $channel;
}
return $this->queue->run(false);
}
}'queue' => [
'class' => \yii\queue\redis\Queue::class,
'commandClass' => \app\commands\RedisCommand::class,
'redis' => 'redis',
'channel' => 'default', // Queue channel key
'as log' => \yii\queue\LogBehavior::class,
]yii queue/run channel_group_1yii queue/run 3 channel_group_1
Хранить html код в столбце поста кажется нецелесообразным по ряду причин:Угу, ага...
Лишняя трата памяти на хранение html теговОго, а лишние это сколько? Экономия на байтах чаще всего приводит к тратам на вычислительные мощности. Некоторые расчеты чуть ниже.
Уменьшение производительности (?)Производительности чего?
Стили/компоненты могут изменяться, а код останется прежнимСтили как раз и нужны для того, чтобы легко конфигурировать визуал, не привязываясь к коду. Код может быть каким угодно, но стилизация через теги пока что лучший вариант, который придумали разработчики.
Использовать собственные минифицированные теги, благодаря которым определенный парсер будет воссоздавать нужные блоки с помощью компонентов (возможно динамичесих)Ага, переизобретаем BBCode, найс... Для понимания проблемы - такие коды придуманы для форумов, с целью ограничить использование хтмл в пользовательском вводе. При этом подходе он худо-бедно оправдан, хотя и требует постобработки при каждом выводе, а это использование регулярок, что как бы совсем не бесплатно. В вашем же случае, источник текста более-менее доверенный, и ограничение в тегах больше мешает чем помогает.
Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id), используя отношения к родительскому посту, соответственно сохранится структура и рендериться пост будет через соответствующие компоненты в нужном порядке (однако как будет именно рендериться в шаблоне поста пока неизвестно)Базовые элементы и так должны храниться отдельно, другой вопрос почему они у вас рендерятся в одном порядке, а в другом месте в другом порядке? Заголовок, короткое описание, текст, главное изображение - отдельные поля, оглавление по сути часть текста, зачем его выносить отдельно - загадка, это же такой же текст, котрый автор волен располагать . Вариант с внешней таблицей по сути приводит нас к выносу части данных в EAV(отличный пример универсализации в ущерб производительности), что как раз будет серьезно напрягать выборки бд, если понадобится делать какие-либо поисково-выборочные манипуляции по этим данным.
Использовать собственные минифицированные теги, благодаря которым определенный парсер будет воссоздавать нужные блоки с помощью компонентов (возможно динамичесих)
Хранить html код в столбце поста кажется нецелесообразным.
Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id),Тут - непонятно. Но есть такое эвристическое правило дизайна
public function afterSave($insert, $changedAttributes)
{
var_dump($changedAttributes['desabilitado']);
var_dump($this['desabilitado']);
die;
[...]
}
<?php
$go = ['test1','test2','test3'];
print_r(array_reverse($go, true));Array ( [2] => test3 [1] => test2 [0] => test1 )<?php
$go = ['test1','test2','test3'];
for ($i=count($go)-1; $i>=0; $i--) {
echo $i.' => '.$go[$i].'<br>';
}2 => test3
1 => test2
0 => test1
var $rows = $("#main").find("tr");
function goToRow (num) {
var $target = $rows.eq(num);
var y = $target.offset().top;
$(window).scrollTop(y);
}
Но не знаю, какое техническое решение взять? Писать на нативном РНР? Взять готовый фрэймворк?