![]() |
Удаление иконки или нарисованной шкалы?
Добавлено через 9 минут Мне вообще кажется, что какую-то линейку нельзя рядом с mvc ставить. В плане mvc можно рассматривать редактор для рисования, но не линейку. Вам нужно подумать, что общего у всех инструментов. Вот я вижу, что выбрав линейку я НАЖИМАЮ и не отпускаю кнопку мыши и передвигая инструмент РИСУЮ и затем ОТПУСТИВ прекращаю рисовать. Далее, взяв кисть я НАЖИМАЮ и не отпускаю кнопку и передвигая инструмент РИСУЮ, после чего ОТПУСТИВ кнопку перестаю рисовать. И мне кажется, что под этот алгоритм подходят все инструменты. И у них у всех общее, это СОСТОЯНИЯ. Добавлено через 13 минут И теперь нужно подумать, что именно здесь нужно модели... Я нарисовал, я стер, я поставил фигурку.. Тут все делает вид и мне сложно представить, куда втиснуть модель. Возможно модели можно поручить смену состояний у вида, но тут нужно подумать, является ли состояние ЛОГИКОЙ приложения. Добавлено через 15 минут Вот если взять широкую кисть и нарисовать ей смайл, то как это повлияет на логику работы приложения, относительно тонкой кисти? |
Gerbert
Я осознал свою ошибку, мне уже всё объяснили) |
И получается, что данные относящиеся к настройкам кисти не должны быть в модели, так как это не логика.
Добавлено через 1 минуту Я к тому, что модель не должна говорить виду, что нужно удалить то, что к логике не относится. |
Так модель виду ничего и не собирается говорить)
|
Цитата:
Цитата:
|
Ну в данном случае модель хранит все объекты добавленные на холст, вьюшка кнопки удаления свистит контроллеру холста, что пользователь хочет удалить объект, контроллер приказывает модели холста произвести удаление, модель берёт тек. выбранный объект и удаляет его из своей коллекции, ну и диспатчит какое-либо событие если надо для вьюшки холста.
|
А зачем модель хранит вью в себе? Потом ещё DO начнут удалятся child.parent.removeChild( this ) и после останется только головой с разбегу об стену ударится, чтобы забыть такое))
|
модель удалит объект вьюшки из своей коллекции и передаст вьюшке по обновлению displayObject для удаления. Модель хранит вьюшки для того, чтобы ими можно было управлять через контроллер холста из любого участка приложения.
|
Я могу только посоветовать прочесть эту и все другие статьи и темы на форуме.
|
Нет, согласен, что логично хранить все вьюшки инструментов во вьюшке холста, но тогда придется во вьюшку холста кидать ссылки на другие вьюшки, которые будут ей сообщать, что-то сделать с тек . инструментом. Например у меня есть инструмент "Полигон" его можно удалять, накладывать фильтры, резать, ломать, кусать с абсолютно разных меню и что мне во вьюшке холста хранить ссылки на вьюшки, которые будут сообщать о модификации тек. инструмента?
|
Нет! Логичней хранить инструменты в виде, который представляет программу.
Вам нужно забыть все, что вы напридумавали и на минутку закрыть глаза и расслабиться. И представить, что Вы разрабатываете графический редактор и чтобы Вам было легче, Вы решили сделать это при помощи mvc. Теперь вы должны вынести в отдельный угол своего сознания ЛОГИКУ, которая очень важна для работы приложения. Вы начинаете словно в бреду перечислять всё ранее Вами придумано и в первую очередь называет самые, как Вам кажется, "отпадные фишечки" Ваше редактора - полигон, линейка, ластик и конечно же, ну конечно же фильтры. И вот в предвкушения всех лавров которые на Вас снизойдут, спуститесь на землю и подумайте, если вдруг Ваш кот сотрет одну из этих инструментов, то будет ли работать Ваше приложение в целом? Вот если оно перестанет правильно функционировать, то это логика, а если нет, то это всего лишь "декор", который в модели не нужен вовсе. А задумка поместить отображение в модель, это вообще полная mvc-ересь. Добавлено через 11 минут И добавлю - Ваши инструменты, это всего лишь иконки и несколько строк кода для манипуляции с bitmapData, по на них не стоит зацикливаться. Графический редактор, а точнее отображение, должно быть реализовано через паттерн "состояния" где есть интерфейс IDraw ( я не умею писать так по английски ) с методами - draw() это для всех рисовалок и IFilter c методом apply. И должна быть коллекция реализующая эти интерфейсы. И об рисовании и применениях фильтров вообще нет смысла знать в модели. Я даже сомневаюсь, что данные для отката шагов нужно в модель записывать. Добавлено через 27 минут Сложно даже придумать, для чего нужна модель. Здесь состояние, коллекция, итератор, медиатор, представление, возможно еще что-то типа контроллера-презентер.. Хотя можно забить на все и сделать из mvc state machine, сделав из модели селектор.. Может более опытные направят, но я больше не знаю что сказать. Mvc тут только для переключения каких-то окошек-вкладок... |
Ого, а тема-то живёт, оказывается. Ну надо же :)
|
Цитата:
|
Gerbert,
То есть вы хотите сказать, что mvc не подходит для граф. редактора и необходимо всю структуру перепроектировать? У меня есть пдф-ка "Шаблон проектирования графического редактора" А.В. Шлиткин. так там такое определение: "графический редактор представляет собой модель и операции по изменению модели." Ещё: "В самом общем виде графический редактор имеет модель данных и графический интерфейс, а поэтому к нему применима модель MVC2. MVC2 модели соответствует Model. MVC2 контроллеру — Tool. MVC2 View — Visualizer и Canva". Блин, кому верить тогда? Я теперь запутался... etc Цитата:
|
Я хочу сказать, что мы говорим о разном, я об том, что представлению не место в модели,
а Вы о том, что правильно ли использовать mvc при создании рисовалки. Шлиткина я не знаю и не могу сказать, прав он или нет.. Вы не понимаете очевидностей, которые разбираются на микрокусочки в это теме и в темах на форуме и объяснять Вам что-то до полного их прочтения, бестолку, потому что придется заново писать уже написанное. По этому, прочтите их, а потом уже спрашивайте. |
Я прочитал данную тему раз 5, но никто не делал и не даст абсолютно правильного решения. Мой опыт mvc крайне мал и получен от данной темы, но я никогда не хранил представление в модели, а только лишь id-объектов представления. Я лишь защищал возможность модели крикнуть состояние "удаление" для представления, чтобы оно взяло тек. id у модели и удалило дочернее представление. Да, у нас модель как бы не обновляется, то есть все значения остаются прежними, она лишь сигнализирует о своём тек. состоянии своей вьюшке. Таким образом две независимые вьюшки смогли сработаться через контроллер и модель. Да, логика модели как бы нарушается, она не должна говорить вьюшке что ей делать, её вообще не должно касаться, что вьюшки будут делать с данными. Но как сделать по-другому, не нарушая логику mvc?
Я СОГЛАСЕН, что НАРУШАЮ MVC. Давайте оставим граф. редактор в покое и возьмём квадратики и кружочки, которые можно удалять и добавлять на сцену, как бы вы спроектировали mvc, поделитесь опытом, пожалуйста. |
Цитата:
Цитата:
Цитата:
то значит Вам нужно в шестой и седьмой раз прочитать. А то я не понимаю, как Вам объяснять если Вы вчера говорите о DO в модели и я целый вечер Вам объясняю, что это фигня, а сегодня Вы все отрицая, просите объяснить что-то другое. |
Я написал это не подумав, так делать нельзя, не сразу это понял. Но удаление представлений у меня идёт через тек. состояние модели, а вы также, на сколько я понял, такой способ не поддерживаете. Как же всё-таки поступать.
|
Посмотрите вот это и потом напишите здесь, является ли реализация из урока лучше Вашей или нет и потом уже можно будет продолжать.
|
Ну очевидно, что так удобнее использовать графические инструменты. Но не ясно, где хранить нарисованные объекты(любой объект можно перетаскивать на сцене), кто их будет хранить, удалять, добавлять, слушать их события и тд.
|
Мне кажется, что Вы угараете, от нечего делать. Вы говорите, что храните DO в модели, а на следующий день говорите, что так не делаете. Когда Вас цитируешь, то Вы говорите, что "написали не подумав" и "так делать нельзя" и ещё на следующий день опять спрашиваете, где хранить представления. Но зато, цитирую!
Цитата:
Добавлено через 8 минут Вам нужно наверное прямо сказать - вьюшки хранятся во вьюшках, контроллеры, в контроллерах, модели в моделях. И добавить - и только! Добавлено через 13 минут Цитата:
|
Цитата:
Я бы хранил вьюшки нарисованных объектов во вьюшке сцены, так как они к ней непосредственно относятся. Удалял, добавлял, слушал их вьюшкой сцены и тд. Но вы говорите, что данные операции к mvc не относятся. |
У Вас должна быть главная вью, она создает вью холста и вью слоев ( вью слоев, это блок-меню, который отображает миниатюры слоев ). И теперь смотрите... Вью холста и вью слоев, это к mvc не относится, это два завершенных модуля.
Модуль, в том смысли, в котором говорят о законченном продукте, который автономный, то есть может переходить из проекта в проект и с которым общаться можно, только посредством api. То есть, классы полностью инкопсулированы. Что будет в этих модулях, mvc не касается, там может быть полный бардак или же тоже на mvc все построено. Но я еще раз повторю, что не могу натинуть mvc на эту задачу. Если в модель засунуть цикл слоев, который будет менять местами слои и.. И это фигня, модель должна содержать логику, а не все подряд расчеты. Забудьте о моих словах тогда и делайте как хотите. Читайте статью, книги, форум и делайте. Я больше не буду отвечать, а то Вы на меня повесите все свои проблемы и скажите, что это меня слушали. Или если хотите, сделайте маленький пример - два квадрата, которые друг на друга заходят ровно на половину. По клику мышки, они меняют глубину местами, то один выше, то второй. И при каждом клики пользователь получает +10 очков. И по завершению 20 секунд, в trace нужно вывести сумму всех очков. Вот это тех задание для девочки с первого курса, которые банеры делает. Только Вам нужно сделать на mvc. Это не шутка и не предлог отделаться, это для дальнейшего объяснения. Если вы это не сможете сделать, то фотошоп уж точно рано. И сделайте так, как видите mvc. |
Цитата:
Пусть это будет упрощенная игра. Тогда у нас есть GameModel, GameView и GameController. Также есть класс-вьюшка RectangleView. Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
|
Тогда прошу прощения за отнятое время. Я хотел Вам продемонстрировать хирургию,
и попросил сделать вскрытие лягушки, а в ответ получил тарелку супа. Все тонкости ушли и я не хочу навязывать Вам флешевою модель mvc, так как в Вашем языке может и не быть реализованно того, что есть в as3 и я только наврежу. Во всех языках разное mvc/ По этому я диалог прекращаю. |
Ответьте на несколько вопросов и закончим с этим. Я опишу, что у меня уже готово. От вас прошу лишь только подсказать или подкорректировать логику архитектуры.
Пока с вами переписывался кое-что переосмыслил и написал отдельный модуль Node(узел), который любую фигуру построенную из линий(потом и для кривых сделаю) расширяет до отдельного узла на сцене, то есть нарисовали, предположим, ромб, то эту фигуру можно перетаскивать через внутренний модуль DragAndDrop в главном модуле Node. Также сделал слушатель событий мыши, удаление и добавление для фигур. Теперь я хочу сделать, как вы мне написали, вьюшку Layer, куда будут добавляться вьюшки нарисованных объектов. Главная вьюшка сцены будет хранить в себе список слоёв layers. Главная модель сцены будет хранить id тек. выбранного слоя из списка layers. То есть теперь из любого меню приходит команда удалить слой, контроллер меняет состояние главной модели deleteLayer = true, вьюшка сцены слушает изменение состояния модели, берёт тек. слой по id из модели, кричит всем чайлдам удалить все узлы, когда все узлы удалились слой передает сообщение вьюшке сцены и она его удаляет из своей коллекции. Как вам такая идея? |
<the свои слова обратно и предложу продолжить постижение самых-самых основ.
Делаю это не для того, чтобы у Вас исчерпались вопросы, а для того, чтобы Вы сами научились на них отвечать. Продолжим... Вот у Вас есть готовый код игры и заказчик просит Вас сделать ещё одну. Задание такое - на сцене пустота, а при клике мышки создается кружок в месте клика. При каждом клики пользователь получает +10 очков. И по завершению 20 секунд, в trace нужно вывести сумму всех очков. Сделайте, я Вам укажу на самую главную ошибку, а потом уже комментарии дам по последнему вопросу. |
Цитата:
|
Я немного погорячился и Ваш псевдокод вполне приемлем, так что меня не напрягет, если Вы его в том же ключе будете соблюдать. А вообще странно, что Вы не зная as3 обсуждаете тему здесь. Вы на каком языке пишите?
И да, в виде mvc. |
Сижу здесь потому что лучше и богаче темы о mvc не видел. К тому же иногда есть у кого-нибудь из форумчан уточнить детали. Программирую на java/c#/javascript, знаю as2, но язык не важен, главное окончательно разобраться в самом принципе mvc.
Цитата:
|
Делайте, а то ошибку не увидите.
|
Я догадываюсь в чём ошибка - неточное использование модели?
Код AS3:
|
Вы неправильно определяете логику приложения, то есть модель, а из этого вытекают и все последующие ошибки. Нужно научится отделять логику от представления и это уже mvc.
Прежде всего ответьте на вопрос - что в первом случаи логика и что логика во втором. И вот только эта логика и должна быть в модели. |
И в первом и во втором случае логика это подсчёт очков и наверное запуск таймера.
|
Цитата:
Логика, это то, без чего приложение не будет приложением. Можно подумать, что таймеру и во вью неплохо, но если заменить вью на другую, то таймера может и не быть и приложение сломается. Я бы прежде всего разобрался с BaseView и выяснил, что будет входить в её обязанности. Просто бывают моменты, когда удобней, чтобы Base или MainView выступала ещё и в роли Mediator'a. Медиатор нужен для того, чтобы CanvasView, различные MenuBoxView могли общаться между собой. Можно сделать отдельно медиатор, который будет связывать все представления событиями. И этот же медиатор будет прокси для контроллера. То есть, медиатор будет хранить немного логики, которая не должна находится в контроллере, а должна находится в представлении. Эта логика и будет решать, передать событие в какую-то вью или передать в контроллер. Далее, у Вас должен быть класс Слой, который реализует всевозможные интерфейсы - IDrag, IFilter и тд. Так же должна быть фабрика этих слоев. И когда Вы щелкаете по кнопке "создать новый слой", посылается событие, которое ловит медиатор. Что делать с этим событием? Если у Вас логика приложения гласит "в этом приложении нельзя создать более ста слоев", то медиатор должен послать сообщение для контроллера, который изменит модель. Ну а дальше медиатор или модель посылает событие, которое ловит другой медиатор ( медиатор создания слоев ) и он уже берет из фабрики новый экземпляр класса Слой и.. И дальше уже Ваша фантазия - Вы можете передать его сразу во все можули ( драг, филтры и ... ) либо же просто отдать в коллекцию слоев и в канвас для addChild. Объяснять можно бесконечно и вопросы у Вас никогда не закончатся, они есть у всех и решения их не дает заскучать. По этому делайте и у Вас все получится. Самое главное в начале понять принцип разделения ответственности. Писать код модульно и писать его не в контексте приложения, а в контексте теста. То есть, Вы создаете среду имитирующую работу приложения и создаете модуль-библиотеку. |
Спасибо, очень ценный ответ. Не зря потратил время. Теперь прояснились многие непонятные моменты с моделями и я почему-то недооценил роль медиаторов для взаимодействия с представлениями, пытаясь привязать представления строго к моделями из-за чего и получил неудачную и неясную структуру. Спасибо вам за потраченное время, всё здорово и понятно изложено. Вопросов больше нет.
П.С. я не пытаюсь написать фотошоп, но хочу сделать продуманный костяк, на котором можно будет написать любой графический редактор. |
| Часовой пояс GMT +4, время: 23:21. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.