Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 09.08.2013, 01:38
Akopalipsis вне форума Посмотреть профиль Найти все сообщения от Akopalipsis
  № 51  
Ответить с цитированием
Akopalipsis
Banned
[+4 24.02.14]
[+4 07.11.13]
[+ 13.03.14]

Регистрация: Mar 2013
Сообщений: 1,864
Цитата:
Я бы склонялся наверное к реализации одного модуля загрузки в виде сервиса
Dukobpa3 Спасибо вам за такой развёрнутый ответ! Дело в том, что я тоже хочу сделать один большой загрузчик и мне тоже пришло в голову определить его как сервис. Так как онлайн приложения, такие как игры и прочие, с чистого листа вообще не потянуть, вот я и придумал сделать полноценный сайт на флеше. То есть - регистрация, интеграция с соцсетями, и все остальное. Лучше тренироваться не на чем. Соответственно все грузится из вне и постоянно все файлы проверяются на изменение ( обновление ). С самого начала создания этой темы я тоже хотел уделить не мало внимания xml, но благодаря Babylon я выяснил, что этому нужно уделить намного больше времени. В общем, пока я учу и в перерывы читаю ваши прения, которые помогают узнать больше чем даже планировал изначально. Спасибо Вам!

Старый 09.08.2013, 01:42
Dukobpa3 вне форума Посмотреть профиль Отправить личное сообщение для Dukobpa3 Найти все сообщения от Dukobpa3
  № 52  
Ответить с цитированием
Dukobpa3
 
Аватар для Dukobpa3

блогер
Регистрация: Oct 2010
Адрес: Киев
Сообщений: 1,678
Записей в блоге: 12
Отправить сообщение для Dukobpa3 с помощью Skype™
Для несложного сайта можно вообще не париться и использовать Loader и URLLoader - там где они нужны.
Потребность в отдельном сервисе возникнет там где нужна либо очередь, как писалось выше, либо какой-то кеш загруженых ассетов, чтоб второй раз не грузились.

Если вы только учитесь то я бы рекомендовал не усложнять а именно так и сделать. Без сервиса, модуля или прочей абстракции. Разобраться с ролями в системе, а потом уже что-то общее выносить отдельно.

Добавлено через 2 минуты
Т.е. логика в том что имеет смысл добавлять новую сущность только тогда когда в ней есть необходимость.
Когда необходимость возникнет - вы поймете. А пока не понимаете - она не нужна
А на роль такого вот сервиса дефолтные флешоаве лоадеры вполне подходят
__________________
Кто к нам с чем для чего - тот у нас того от того.

Старый 09.08.2013, 02:02
Akopalipsis вне форума Посмотреть профиль Найти все сообщения от Akopalipsis
  № 53  
Ответить с цитированием
Akopalipsis
Banned
[+4 24.02.14]
[+4 07.11.13]
[+ 13.03.14]

Регистрация: Mar 2013
Сообщений: 1,864
Dukobpa3 Спасибо! я и не тороплюсь, как бы мне этого не хотелось.
я пока учу как сериализировать\десериализировать и набить этим модель. Как пойму, что на бессознательном уровне смогу понять ход работы, вернусь сюда или в ГЛОБАЛЬНУЮ тему ( на пятидесяти страницах ) и спрошу про механизм наполнения модели. А то вдруг что не так понял) Спасибо!

Старый 09.08.2013, 03:05
Babylon вне форума Посмотреть профиль Отправить личное сообщение для Babylon Посетить домашнюю страницу Babylon Найти все сообщения от Babylon
  № 54  
Ответить с цитированием
Babylon
[+1 25.10.13]
[+4 18.03.14]
 
Аватар для Babylon

Регистрация: Jan 2006
Адрес: Москва, Зеленоград
Сообщений: 653
Отправить сообщение для Babylon с помощью ICQ
В интерфейсе между детьми я могу увидеть некоторый смысл, если дети и родитель выполняют общие функции для кого-то. Это очевидно. В случае же с МVC ядро самостоятельной роли не играет. Давайте еще придирки к моим словам.

Добавлено через 9 минут
Цитата:
Сообщение от Dukobpa3 Посмотреть сообщение
С ассетами всё более однозначно - загрузчик ассетов должен быть во вью.
Это не так. Если для вас важна последовательность загрузки, а последовательность зависит от логики, а логика определяется моделью, или точнее не определяется видами.
Так что процесс загрузки, тоже неоднозначен.


Последний раз редактировалось Babylon; 09.08.2013 в 03:29.
Старый 09.08.2013, 05:27
Котейка вне форума Посмотреть профиль Отправить личное сообщение для Котейка Найти все сообщения от Котейка
  № 55  
Ответить с цитированием
Котейка
 
Аватар для Котейка

Регистрация: Aug 2013
Сообщений: 56
Babylon, логика вида определяется видом. Если виду надо загрузить последовательно, то он сам это и должен сделать. MC не должны иметь абсолютно никаких зависимостей от V. Иначе сам шаблон MVC теряет свой смысл. А в случае, если ассеты будет грузить не вид, то это прямая от него зависимость.

Старый 09.08.2013, 08:15
Babylon вне форума Посмотреть профиль Отправить личное сообщение для Babylon Посетить домашнюю страницу Babylon Найти все сообщения от Babylon
  № 56  
Ответить с цитированием
Babylon
[+1 25.10.13]
[+4 18.03.14]
 
Аватар для Babylon

Регистрация: Jan 2006
Адрес: Москва, Зеленоград
Сообщений: 653
Отправить сообщение для Babylon с помощью ICQ
То есть по вашему логика работы модели не должна влиять на процесс загрузки ассетов? Несогласен.

Старый 09.08.2013, 10:52
Dukobpa3 вне форума Посмотреть профиль Отправить личное сообщение для Dukobpa3 Найти все сообщения от Dukobpa3
  № 57  
Ответить с цитированием
Dukobpa3
 
Аватар для Dukobpa3

блогер
Регистрация: Oct 2010
Адрес: Киев
Сообщений: 1,678
Записей в блоге: 12
Отправить сообщение для Dukobpa3 с помощью Skype™
Пусть влияет.
Но не грузит.
Этого можно добиться кучей методов. Например вью начнет грузить и отображать ассеты только по определенному месаджу из модели. Но модели абсолютно по барабану какие картинки будут нарисованы во вью, и как она их нарисует.
__________________
Кто к нам с чем для чего - тот у нас того от того.

Старый 09.08.2013, 11:05
carrotoff вне форума Посмотреть профиль Отправить личное сообщение для carrotoff Найти все сообщения от carrotoff
  № 58  
Ответить с цитированием
carrotoff
 
Аватар для carrotoff

Регистрация: May 2010
Сообщений: 543
Цитата:
Сообщение от Babylon
Интерфейсов нужно сторониться, но полностью без них обойтись не получится. Их использование -вынужденная мера.
Это чушь. Не оказывайте медвежью услугу вопрошающим, если сами имеете, мягко говоря, не совсем осмысленную позицию в этом вопросе.

У любого начинающего может сложиться такое же странное и в корне неправильное представление об архитектуре из-за вашей лженауки об интерфейсах, xml'ях и ядре.
__________________
Вы грабите бедных людей. Парень со свирелью накажет вас. Хонгильдон (с)

Старый 09.08.2013, 11:08
Dukobpa3 вне форума Посмотреть профиль Отправить личное сообщение для Dukobpa3 Найти все сообщения от Dukobpa3
  № 59  
Ответить с цитированием
Dukobpa3
 
Аватар для Dukobpa3

блогер
Регистрация: Oct 2010
Адрес: Киев
Сообщений: 1,678
Записей в блоге: 12
Отправить сообщение для Dukobpa3 с помощью Skype™
Код AS3:
Дело в том, что я тоже хочу сделать один большой загрузчик
LoaderMax
BulkLoader
И много других, достаточно загуглить. Не зачем велосипеды изобретать.

Добавлено через 10 минут
Цитата:
В интерфейсе между детьми я могу увидеть некоторый смысл
Пример рас:
Главное приложение оболочка грузит в себя пачку плагинов. Каждый плагин это отдельный проект. Наследоваться от какого-то базового класса плугина глупо и неэффективно, будет куча конфликтов. Интерфейс - ок. В итоге родителю абсолютно пофигу как там реализован плугин, он будет работать с его интерфейсом.

Пример два(не совсем родитель-дети, но без интерфейса плохо):
Паттерн "стратегия". Например какой-то поиск пути несколькими методами, либо какая-то квестовая система, где одна задача решается пачкой методов.
Для поиска пусти у нас есть интерфейс ИРасчетПути. В котором допустим есть метод getPath(cells:Array):Array - принимает массив ячеек карты, выдает массив ячеек по которым юнит может пройти. Далее мы реализовываем несколько методов расчета и встегиваем в нужный момент в нужное место в каком-то манагере.
Для квестовой системы так же. Есть какой-то IConditionChecker.
Например такой(из моего реального проекта):
Код AS3:
	[Event(name = "complete", type = "flash.events.Event")]
	[Event(name = "change", type = "flash.events.Event")]
	public interface IConditionChecker extends IEventDispatcher
	{
		//=====================================================================
		//	PUBLIC
		//=====================================================================
		function init(subtype:String, num:int, data:String, delta:Boolean):void;
		function update(status:int, data:BaseProtoData):void;
		function setCounter(counter:int):void;
		//=====================================================================
		//	ACCESSORS
		//=====================================================================
		function get commandId():int;
 
		function get complete():Boolean;
 
		function get count():int;
		function get needCount():int;
	}
В итоге мы реализуем подсчет условий квеста одинаково, но реализация подсчета отличается очень сильно. Считать нужно ВСЁ. От заработанного пользователем бабла, до кол-ва кликов, до выполненных каких-то иных игровых задач, типа построить дом такой-то.

Пример три, паттерн "команда". Интерфейс ICommand реализуется как вздумается. Можно обойтись базовой командой и ее наслоедовать, и часто это удобнее чем интерфейс, но абсолютно не всегда.
__________________
Кто к нам с чем для чего - тот у нас того от того.


Последний раз редактировалось Dukobpa3; 09.08.2013 в 12:05.
Старый 09.08.2013, 12:24
etc вне форума Посмотреть профиль Найти все сообщения от etc
  № 60  
Ответить с цитированием
etc
Et cetera
 
Аватар для etc

Регистрация: Sep 2002
Сообщений: 30,784
Ну хоть какая-то движуха пошла.

Создать новую тему Ответ Часовой пояс GMT +4, время: 14:10.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 14:10.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.