ArbNet

ArbNet
Рейтинг
146
Регистрация
27.10.2019
Программист самоучка
Sly32 #:
чем отличается концепция, паттерн, шаблон?

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

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

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

Таким образом, концепция является общей идеей, паттерн - это типовое решение, а шаблон - конкретная реализация паттерна.

Упс. Если для тебя это всё одно и тоже, то тебе надо за парту "умник" 😁 что в лоб, что по лбу..

Антоний Казанский #:
здесь только можно отойти в сторону и не мешать

Вот это правильно 😎 не можешь помочь, тогда не мешай

br.almighty #:

А где сам фреймворк то? Я заценить хочу, но ни по каким ссылкам нигде никакого фреймворка нет.

Мне запретили его тут обсуждать, показывать и тд. И да, разработка ещё ведётся. В дискорд заходите, могу показать и рассказать.

Sly32 #:
код тут вообще не причем. клиент не понимает что такое MVC в принципе, а его подделка вообще никак не попадает под этот паттерн

Во-первых для тех кто что-то слышал, но мозг которого не в состоянии осмыслить услышанное.. MVC это не паттерн, а концепция разделения данных и логики на модель, представление и контроллер. Паттерн - это шаблон проектирования, некоторые называют MVC паттерном проектирования, но это не правильно. Паттерн решает некоторую проблему, а концепция MVC это не решение проблемы это архитектура целого проекта.

Во-вторых, я когда начинал разработку, говорил что MVC не плохая вещь, но есть идея сделать другую свою концепцию... И да, в данной теме я вообще не говорил, что использую MVC или ли что-то ещё. У меня своя разработка, но вы до сих пор этого не понимаете и как попугай повторяетесь..

Sly32 #:

шел 2024 год, а некоторые до сих пор не понимают, что такое MVC и для чего он. Да здравствуют вечные грабли! Безумно забавно  читать такие топики. Это как на полном серьезе обсуждать, как к истребителю приделать еще одну пару крыльев сверху.

Сказал тот, кто кроме как штаны протирать в офисе ничего не может. Сделай хоть один достойный полезный проект и тогда можешь поучать, хорошо 😉

А по теме скажу то, что в HTML разметке предусмотрены атрибуты для событий и др. функционал с CSS и тд. то MVC во фронте можно реализовать посредственно, всё равно всё будет связано и неразрывно.

Знания(технического и фундаментального анализа) +

webinfo #:
Опыт + интуиция + аналитика.

+ математика(расчёт рисков и доходности) + психология(надо уметь себя сдерживать от эмоций, только холодный расчёт)

ЗЫ. Учите матчасть по биржевой торговле.

Snake800 #:
Классика MVC же ж. Короче, никаких on*="" в <коде />. Html вообше не должен знать, что с ним будет происходить после того, как он придёт в браузер.

Во фронте MVC не катит, в бэке да такой подход удобен и то есть случаи когда приходится совмещать разметку и код.

А вот в фронте разметка и код не разделимы, можно конечно писать модули, компоненты и прочее, но в основном нужно что-то сделать быстро и чтобы потом можно так же быстро разобраться и поправить при необходимости и поэтому разделение тут только будет во вред. Да если владелец сайта сам программист и может разобраться, найти что где находится в каких файлах и прочее, то не вопрос, но когда человек мало что понимает, то ему будет удобнее в одном месте где-то что-то подправить по инструкции. Именно поэтому я и стараюсь делать по другому. Глядя на существующие фреймворки и инструменты как там напридумано всяких объектов в которых должны быть некие параметры и всё это нужно знать, то для обывателя это тёмный лес, да и с доработкой на таких инструментах позже будут проблемы..  ИМХО

nikki4 #:
Для этого есть множество фреймворков, например antd, mui из наиболее крупных 

Если они вас устраивают, пользуйтесь, вот только другим навязывать их не надо, меня они не устраивают, поэтому делаю по своему.

Snake800 #:

Не. Лучше через data-, кмк. Вернее так: событие должен ловить некий css-селектор (в т.ч. через data-*). А что делать с этим элементом, сотдержится в дата-атрибутах. Я так делаю. Правда я в js далеко не гуру и, возможно, вообще правильнее dom- элементы заворачивать в какую-то js-обёртку.

Я пару лет назад тоже так рассуждал и даже делал обработчики навешивая на элементы где data-do="указание какого-то действия" функций обработчиков тех или иных действий. Потом стал писать разные модули и придумывание разных функций каждый раз для каки-то действий это только хуже и навешивание событий это только дополнительная путаница и тд. В html предусмотрены атрибуты для обработки событий onclik и др. on* к тому же есть возможность создания своих событий через MutationObserver, создав модуль для обработки событий наблюдений за элементами просто прописываешь как обычно своё событие on*** с указанием функции обработки и всё. А для ускорения разработки в других модулях подготавливаешь функции для изменения, работы с элементами и др. указывая которые в обработчиках событий, так намного понятнее и проще.

webinfo #:

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

Как для программиста это да, пофиг, можно как угодно сделать, главное чтобы работало.

Я же хочу чтобы и не программисты могли без знаний JS легко создавать разные динамические формы обрабатываемые скриптом и тд. Короче решил через события делать, разработчику не трудно прописать атрибут события, а пользователю без знаний JS надо просто скопировать готовую разметку и всё, так будет удобно для всех ИМХО

webinfo #:

Так нагляднее, ИМХО. И это не обязательно огромная кнопка, можно маленькую иконку ставить.

Ну это не ответ на мой вопрос: навешивать события скриптом или делать прописыванием их в элементе через атрибуты on*

Это украшение так сказать, удобство интерфейса, при наведении мышкой на элемент который имеет возможность редактирования, например можно менять цвет фона, границы, показывать подсказку и тд.

Всего: 2287