Василий Назаров: ну его преимущество, конечно, не в монструозности, а в фактической обязательности TypeScript и в целом строгости к подходам в разработке. С ангуляром будет проще сохранять единообразие кода, контролировать зависимости, отлаживать и т.п. Да и с монструозностью они, насколько я знаю, проблему активно решают. Как минимум многие основные модули были вынесены в отдельные пакеты.
Короче, ангуляр просто минимизирует человеческий фактор (не без компромиссов, разумеется), что становится реально важной задачей с большим количеством разработчиков.
Не согласен. Я считаю, что их просто некорректно сравнивать, так как они созданы для разных сегментов. И ангуляр скорее всего менее популярен как раз из-за того, что он не "народный" фреймворк, а решение для ентерпайза, что, очевидно, значительно сужает его аудиторию относительно Vue.
fiter: тем не менее это наименее геморройный вариант)
Можно ещё как-то закодировать в base64, но я бы не назвал такой подход более удобным)
А так - просто привязываете через ref файловый инпут и пихаете его содержмое в FormData. Готовый объект передаёте FormData вторым параметром в axios.post. В принципе ничего особо геморройного, хоть и, конечно, не самый удобный вариант.
Поэтому я и говорю, что нужно эту логику вынести или вообще за пределы компонентов (то есть в meta поле роута), или оставить внутри app-header (то есть как computed property).
Это плохо тем, что другие компоненты должны содержать код, который влияет на app-header. Одна из основных идей подхода с компонентами - это их низкая связность, то есть любое влияние одного компонента на другой без веской на то причины - это скорее всего плохо. Конечно, могут быть и исключения, но мне кажется, что ваш случай слишком простой, для того, чтобы таким быть. Хотя на 100% утверждать этого я не могу, так как всего кода не вижу.
Антон: Не знаю, может конкретно Avocode действительно удобная штука - я сам с ней дела не имел - но мне кажется, что это все равно несерьезно. Подойдет разве что для прототипов. Но это только мое мнение, не основанное на реальном опыте.
oleg_drozdov: в таком случае нужно создать свойство со ссылкой на раздел, потом в result_modifier.php (может можно и проще, точно не знаю) через CIBlockSection::GetList доставать все разделы, указанные в слайдах в этом свойстве, потом в шаблоне выводить в href LIST_PAGE_URL нужного раздела. Короче, тебе скорее всего придется найти кого-то, кто бы это мог сделать) Сам долго разбираться будешь.
oleg_drozdov: посмотри внимательнее - мы сначала открываем цикл, а только потом ссылку (внутри, соответственно, цикла). И непосредственно до закрытия цикла мы закрываем ссылку. Соответственно, все содержимое, выводимое в цикле, будет обернуто в ссылку.
Adamos: куча готовых модулей есть и под любой фреймворк. Вот только полноценной интеграции с 1С я нигде не видел, в т.ч. и в битриксе, где эта интеграция заставляет дорабатывать под себя всю структуру данных магазина (хотя должно быть наоборот). А общий интерфейс админки в большинстве случаев перегружен теми функциями, которые чаще всего возлагаются на разработчика. По сути все, что должно быть туда вынесено - это непосредственно управление контентом на сайте, остальное там обычно (не всегда, конечно) не нужно.
Adamos: ну если фреймворк не является цмс, то это не значит, что готовых решений не существует. Наверняка у каждого более-менее зрелого фреймворка есть плагины/модули/пакеты для управления контентом. Конечно, из админки вряд ли так же получится натыкать мышкой, например, структуру данных, но давайте взглянем правде в глаза - этим и в битриксе тоже занимается программист. К тому же способы хранения данных в цмсках далеко не оптимальные. Это оправдано, ведь цмска должна быть универсальной, но тем не менее. Фреймворки же диктуют только структуру организации кода и берут на себя ряд рутинных операций, в остальном ограничений нет никаких.
webquestions: я бы сказал, что не меняет. Просто попробуй, например, Laravel, сразу все ясно станет)
Я сам с CMS переходил (в частности с Drupal, который тоже заявляется как CMF) на фреймворки - это просто земля и небо.
kiff86: да я понимаю, ты прав, тем более вопрос действительно интересный. Но просто объем информации, который нужно передать, чтобы это понять, слишком большой, чтобы уместить его в комментариях. К тому же немаловажен непосредственно опыт программирования, без него понимание тоже вряд ли придет. Хотя один совет я дать могу - попробуй поизучать ООП на каком-то строго типизированном языке типа Java или C#. PHP, как язык слабо типизированный, не даст полного понимания. Опять-таки, очень долго объяснять, зачем это делать, но просто поверь и попробуй - сам убедишься.
