Профиль пользователя заблокирован сроком с 29 августа 2016 г. и навсегда по причине: Снова мат
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: Вы меня как-будто не слушаете. То что Вы написали с точки зрения полезной информации ровняется нулю, так как из этого отрывка можно понять только то, что Вы присоединились к армии mvc-php'шников, которые говоря о 79 годе пишут полную ересь.

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

    Если бы Вы мне задавали вопросы и я на них бы не мог ответить, вот тогда бы наш разговор был бы в Вашу пользу, но пока остановимся на том, что Ваша статья нанесет больше вреда чем .. пользы в ней точно не будет.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: ахахаха. Это не Вы написали статью где angular шаблоном проектирования назвали? Просто Вам мини пример, это не пример mvc, это пример порно какого-то.
    Такое ощущение что Вы пишете по парадигме angular :) Без зла говорю. Вы наверное будите причиной апокалипсиса после изобретения новой парадигмы.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: Вы ещё и flux туда приписали?) Я не буду читать даже, это трата времени. Вы как упертый не хотите понимать что такое mvc и что такое компонент. Flux это представление, реакт это библиотека для рендера. Если Вы хотите угодить всем подстроившись под всех и дав им то что они хотят услышать, то я больше не буду с Вами на на такие темы разговаривать.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: нет я не читал и читать не буду, так как ссылку на неё дали Вы, а значит она подтверждает Ваше мнение, а значит ставит диагноз по симптомам, а не по анализам.

    Я Вам привел конкретные доводы что и где есть, хочу услышать и от Вас тоже самое.
    Но Вы говорите - а вот он сказал, а вот там я слышал. У Вас собственное мнение есть?
    Как Вы можете данные-ассеты называть бизнес-логикой? Да хоть сто раз головой об что-то ударится и сто раз завернуть говно в газеты, все равно ничего не изменится.

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

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

    copal
    @copal
    Сергей Протько: вот я не хочу сворачивать с темы веба, но не получается на нем объяснять. В соседней ветке сегодня появился вопрос как создать морской бой. Хоть это и не сайт но он очень простой и на нем очень хорошо проиллюстрировать модель. Представьте что игровое поле состоит из квадратов каждый из которых 0 или число представляющего часть корабля. Типа массив, сейчас сделаю минималистический пример -
    let gameField = [
        0, 1, 0, 0,
        0, 0, 0, 0,
        0, 0, 1, 0
    ];

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

    Сложность вся в том, что никто не дал формулировку тому что такое настоящая модель и что ей быть не может по определению.

    Но теперь смотрите. Я беру и делаю мега морской бой где каждый корабль можно прокачивать, делать его сильнее и эффективнее. Вот в таком случаи у кораблей появятся свои модели. Но для модели игры их по прежнему не будет существовать.
    Но может быть такая ситуация, когда второстепенной модели может потребоваться обратится к модели приложения. Вот тогда бы я мог сказать что такой подход можно назвать mvvm, но только как подход, когда модель обращается к другой модели, что в рамках mvc является вполне обычным делом. Но назвать бы это парадигмой я бы не смог, так как это не что-то за грань выходящие. Просто бы Вы меня быстрее поняли что я второстепенная модель обращается к основной. Эту модель можно было бы и viewModel назвать как это многие делают. Но многие не из мира вэб. В чистом вэбе, где обычные приложения, я не могу придумать таких случаев. В каком-то сложном онлайн редакторе, очень интерактивном приложени, да, но не на сайте.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Чтобы было ещё понятней должно быть SomeInputComponent. Это обычный компонент, который олицетворяет информационную модель компонента. В нем нет ничего что его бы опорочило или сделало не компонентом, в отличии от того что Вы не сможете мне сказать тоже самое о своем mvc, так как не сможете показать мне в нем бизнес логику.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: забегу вперед и скажу что я тоже буду считать это mvc если Вы скажите где тут бизнес логика, которая и делает модель моделью? А вот про анимичные я вообще слушать не хочу так как это придумали те, кто использовал mvc не правильно и мало того что просто использовал, а у них даже разума на трактовку не хватило, но зато из ошибки вытянули понятие анимичной модели. Это не модель и точка.
    И ещё дальше забегу.. Здесь нет бизнес модели. Все вот это самое обычное представление, которое можно объединить к компонент. Вы же понимаете что компонент это некое законченное самодостаточное приложение? По другому можно сделать вот так, в ооп стиле
    class SomeInput {
        private _input;
        
        private _data: string;
        public get data(): string {
            return this._data;
        }
        
        constructor(){
            this._input = document.createElement('input');
            this._input.addEventListener('change', this.input_changeHandler);
            
            document.body.appendChild(this._input);
            
        }
        
        protected input_changeHandler = (event) => {
            this._data = event.data;
        }
    }

    Это законченный самодостаточный класс, который является компонентом по определению (естественно это минимальный пример) и так же является обычной часть представления.

    Вы сказали что mvc собирает куски приложения и это так, но части представлений могут собирать только представления. У моделей тоже самое.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: хорошо, я продолжу свои рассуждения, так как мне хочется не переубедить Вас, а разобраться кто из нас прав. Вот смотрите, Вы подходите к делу так?
    // и все это объедененно в компонент начиная от сюда
    let inputModel = {value: null};
    let inputView = document.querySelector('.some-inpur');
    function controller(){
        inputView.addEventListener('change', event => inputModel.value = event.data);
    }
    // и заканчивая здесь
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: а для меня Вы типичный проблематик, я даже начал с объяснения что такое настоящая модель, а Вы сейчас не обосновывая или обосновывая у себя в голове услышанными ранее словами, говорите что это масштаб. Как не крути но модель из mvc, это бизнес логика, а бизнес логика не может быть разной в зависимости от масштаба. Это как какашка мамонта и мыши, все равно говно. Простите за употребление некрасивых слов, но сравнивать вишню и арбуз не так эффективно.
    Вы начинаете опрерировать собранными отовсюду фразами. но не хотите думать сами, возможно Вы слишком доверились авторам книг. Данные не бизнес модель и ассеты не бизнес модель, хоть со скалы сиганите, но оно не будет моделью не на каком уровне.

    Для Вас '{a: "name", setName(){...}, hetName(){...}}' тоже маленькое mvc? И да, я хочу сказать что от части Вы правы, mvc может состоять из маленьких mvc, но для этого приложение должно быть очень больших масштабов и не состоять при этом из стандартных компонентов, которые хоть композиционно, хоть в ряд разложи все равно не тянут на приложение.

    И да, Вы описываете мне маленькое mvc из input, но Вы хоть согласитесь что делаете это основываясь на данности angular, а не на собственных умозаключениях, а иначе я и вправду подумаю что для Вас свойство это модель. Это же надо такую ерунду сказать - хранилище данных является моделью.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: нет у меня нет такой проблемы. Такая проблема есть у создателей ангуляра, которые при чтении и записи с input пишут в модель. А я то как раз и говорю что mvc это только для уровня приложения, а не для всего, как например советуют использовать mvp для gui, где презентер берет из модели... Но под моделью опять хранилище подразумевают, так как компоненты не могут отображать логику приложения. А вот в ангуляре это все есть и контроллеры и модели и даже какой-то сумашедший написал статью что ангуляр это паттер проектирования.

    Эта же проблема и у безумцев которые в офф документации написали что react это "всего-лишь представление", хотя это всего лишь библиотека (не могу даже сказать что это как было заявлено entit system, так как не углублялся, а словам давно не верю) построенная в виде бинарного дерева листья которого называются компонентами.
    Почему это называется представлением и почему узлы названы компонентами остается загадкой, так же как и не понятно кому пришла мысль оформлять узлы в виде xml синтаксиса.
    Вот например если я создам компонент hello world. который переводит первую букву в верх...
  • Как называется расширение для google chrome для ведения лога с flash приложений на странице (дебаг flash приложений)?

    copal
    @copal
    Игорь Самохин: я никогда не занимался отладкой средствами браузеров. Есть специальные консоли которые нужно добавлять в саму флеш, есть программы, которые могут считывать данные с флеш который был скомпилирован в дебаг версию. Но то о чем говорите Вы мне не знакомо и не понятно. Пусть разработчики напишут дебаг контейнер, который подпишет приложение на ошибки и будет посылать сообщения об этом туда, куда нужно (имеется ввиду сервер) и уже там пишите в логи.
  • Как называется расширение для google chrome для ведения лога с flash приложений на странице (дебаг flash приложений)?

    copal
    @copal
    А Вы лично пишите приложение и ставите в него trace? И что Вы подразумеваете под логами?
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Вот.. Вывод из всего написанного выше - люди не понимают разницы между бизнес моделью и данными-ассетами. И именно по этому появляются "парадигмы" в которых кнопка подписана в контроллере и input пишет данные в модель или берет из неё.

    Ну и я пока перестану говорить и подожду Вас. Ну и ещё раз подчеркну что 99% людей с которыми я обсуждал ту или иную реализацию mvc не понимают разницы между моделью и хранилищем. Так же на лицо проблема не понимание того что именно должно находится с модели и поэтому туда суют все подряд.

    Ну а дальше я вообще боюсь говорить так как сказав что UserModel это не модель, а всего лишь обычные данные, вызовет тысячу вопросов, легче на которые не отвечать, а сказать делайте как знаете. Но факт того что если я поменяю имя в профиле, или аватар, то приложение не изменится, а значит это данные не модели, а значит и делать им там нечего.
    И от сюда вытекает следующая проблема - люди хотят mvc, они его строят на данных.
    А это в свою очередь вызывает потребности слить представление и модель, как например mvvm. То есть mvvm это вообще что угодно но не реализация mvc.
    Да, можно сказать что это придумал какой-то известный тип со степенью ученого, но на мой взгляд он описал кучу говна как нечто утончонно-упорядоченное с почти незримой гранью. То есть опять - хотел - получил.

    И по этому ещё раз - Ваш аватар ничем не отличается от написанного мной текста. И то и другое является ассетами и обычными данными и как не натягивай на волка шкуру овцы, так он и будет всегда волком. Меню которое находится под аватаром, это обычный компонент, которое просто невозможно написать по mvc, точно так же как нельзя написать по mvc букву А.
    И при этом я хочу подчеркнуть что теоретически mvvm возможно но в очень сложных приложениях и при том условии, что это будет термином обозначающем общение моделей, а не отдельной веткой парадигмы.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Так же нужно обязательно добавить, что раз уж у представления нет модели, то и контроллер ему (представлению) не нужен, ведь у контроллера только одно предназначение - связывать представление и модель. Это так же говорит что представление это не только html, но и js обработчики событий и так же логика отображения, ведь нужно же текст введенный пользователем в том же input, допустим, форматировать или ещё чего. Так же стоит отдельно упомянуть что текст ничем не отличается от картинки или звука, видео, ведь это все обычные ассеты. А ассеты в свою очередь, это целиком и полностью в юрисдикции представления.

    ... продолжение следует
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: у меня вот какая мысль, отрывками я её много раз уже озвучивал, но теперь попробую донести её полностью, может Вы мне укажите на "неправильность".
    Начать нужно с обозначения того чем является mvc. Прежде всего это свод правил, которые не привязаны к какому-то конкретному языку. В этом своде всего три правила -
    1) модель - бизнес логика,
    2) представление - ??? (пока под вопросом),
    3) контроллер - который служит связывающим звеном представления и модели.

    Прежде всего в глаза должно бросится то, что все что не является бизнес логикой не является моделью. Чаще всего в этом тексте я упомянул слово модель, поэтому с неё и начну разбор.

    Что такое бизнес логика? Это то без чего не будет "чего-то". Если поменять бизнес логику приложения А, то оно уже не будет приложением А. Грубо говоря если у пулемета поменять рукоять, покрасить его и закрутить в рогалик дуло, то он все равно будет пулеметом. Но вот если убрать возможность стрелять пулями и добавить возможность извергать струю зажженной жидкости, то пулеметом он точно уже не будет.
    Это пример из мира "как должно быть", а в мире "как есть" вот как..

    Есть такое замечательное творение как mvp, mvc предназначенное для ui.
    По нему (если рассматривать в контексте thml + js + css и дальше я буду все сводить к ней) моя кнопка должна быть подписана в контроллере и по событию что-то делать с моделью и что-то передавать в те же gui.

    И вот если взять самый типичный пример , а именно input с которым непосредственно взаимодействует пользователь, то можно притянуть за уши подписку в контроллере, точнее призентере, но что будет в модели? Вот без чего nput не будут input'от?
    Ответ один - у input вообще нет модели, а точнее у него нет бизнес логики вообще.
    То место где будет хранится текст, это что угодно но не бизнес логика. Я могу написать "привет", а могу "пока" и ведь intup все равно будет input.

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

    Но это я уже говорил и Вы уже слышали. Продолжу позже.
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Сергей Протько: [тут я написал очень много текста, в котором приводил доводы что Вы не понимали что такое mvc только потому что не читали книги о паттернах, но в самом конце я понял что суть этого непонимания гораздо глобальней чем может показаться и кроется именно в деталях.] Возможно есть книги которые описывают то что я держу в голове, а так же я не исключаю что они опровергают мои мысли, но я таких не встречал.
    Сейчас нет времени, но как появится я продолжу :)
  • Есть ли учебный материал по паттернам на основе пошагового создания веб-приложения?

    copal
    @copal
    Можно простой вопрос - сколько лет Вы знаете слово SOLID, GRASP (мне приблизительно это известно, так как они совсем недавно появились в Вашем лексиконе) и сколько лет Вы знаете MVC? И да, паттерны были описаны для того, чтобы в первую очередь можно было понятно объяснять код, но так же они внушают уверенность неопытным программистам.
    И вот исходя из всего этого можно прийти к мыслям, что прям "бросайте паттерны" звучит не совсем верно.
    Автор, сделайте архитектуру своим хобби и читайте книги и статьи (обязательно SOLID, GRASP и прочие) до тех пор пока не станет все понятно. И ещё можете пользоваться uml редактором (например вот этим https://www.draw.io/) чтобы рисовать то что Вы читаете, ведь это будет полезнее чем просто смотреть код из книжки и даже полезнее чем его писать.