Подскажите, кто должен обрабатывать поток gulp в mvc, контроллер или модель?
И немного разбавьте объяснениями.
Извиняюсь за НЕ разъяснение, когда в голове картинка происходящего стоит, кажется, что и другие её видеть должны.
Делаю свой плагин ( точнее, доделываю ) где поток гонит данные о файлах, я должен этот поток обработать и получившиеся данные сохранить в модели. То есть, поток, мне нужен в модели. Каждый файл обработанный в модели, модель диспатчит событие и вид считывает данный файл из файловой системы и если нужно записывает собранные данные в указанный файл. Если кому-то покажется, что не вида это дело, собирать данные, то тут я могу лишь сказать, что к любым данным, которые относятся только к виду, должен быть причастен только вид.
Почему вид относится к данным, это только по тому, что он их записывает после в файл, который отображается в редакторе.
Воот... Но у меня три проблемы с этим, первая из которых, чем является поток данных от gulp и вторая как эти данные должны попасть в модель.
поток gulp должен обрабатывать gulp или его планины. Причем тут MVC?
Я так понимаю что вы хотите организовать что-то типа asset менеджера, который компилит все асеты используя gulp. В этом случае наш asset manager - сервис. Дергать сервисы - задача контроллера (контроллеры бывают разные, тут речь идет о front-контроллере, точке входа). Можно реализовать дамп асетов отдельно от приложения, например при вармапе кеша.
В любом случае MVC тут не причем. Это не часть представления и не часть модели. Либо фронт-контроллер, занимающийся непосредственно обработкой запросов, либо какой-то механизм сборки. А еще лучше - просто собирать асеты галпом.
@vasIvas всеравно не понимаю причем тут MVC. Вы считаете что все вообще должно писаться с использованием MVC?
Поток gulp - это файловый стрим который вы обрабатываете. То есть по сути это запрос. Его хэндлить нужно в "контроллере". другое дело что у вас не должно быть особо модели и вью. Только контроллер и сервисы.
Я не думаю, что все должно делаться с использованием mvc, можно и в одном файле десяток тысяч строк написать без пробелов. Но мой мозг, когда видит много всего, он пытается разбить обязанности и от сюда получается mvc.
Как это вью не должно быть, а чем тогда является окно в редакторе кода?
И я вот сейчас думаю по поводу слов "запрос", а почему именно запрос, я же не в браузере работаю. И ведь если рассматривать файловую систему, как часть сервера-модели... мне хочется вот тут прерваться и спросить, а Вы слышали о ТТУК ?
@Fesor , я вот ещё что подумал. Если файловая система === сервер === модель, то тут и контроллера быть не должно. Получится, что весь плагин, это маленькая часть модели, которая считывает, обрабатывает и записывает обратно в файлы. Это так ведь получается?
@vasIvas мне кажется вы не понимаете что такое MVC, либо я не понимаю что вы хотите сделать. Для меня плагин для gulp - часть сервисного слоя. То есть это просто сервис. никакого MVC, не знаю почему вы помешались на подобном разделении. Просто классы-сервисы.
Причем тут "окно редактора кода"? Какое отношение это имеет к плагину для gulp?
@Fesor , нет, я понимаю, что такое mvc и для чего оно нужно.
Я его реализовать хотел только по тому, что изменение файла,
в голове, определил как view. А Вы можете рассказать, что такое сервис?
Смотрел в wiki и не понял о чем читал. Там написано - "Сервис это модуль", а переходишь на модуль и там написано "Модуль это сервис".
@vasIvas у вас нету view. У вас есть данные на выходе и на выходе. Никакого MVC. Только контроллер. Ни модели, ни представления. Контроллер принимает пользовательский ввод и должен дать овтет. Наличие модели/представления не обязательно. Хотя зависит от плагина.
@vasIvas но как по мне вы забили себя голову всеми этими MVC и слишком много паритесь по пустякам. Расскажите может что плагин делает хоть приблизительно. Я не могу придумать такой вариант при котором нужен еще и view.
А сервис - это любой класс, который используется контроллером для обработки данных. По сути в сервисе заключается бизнес логика. Модели - элементы на которых работает бизнес логика. Представление - как это не странно - слой представления. Он нужен только для конвертации из формата приложения (модель) в формат нужный на выходе.
@Fesor , да я все ещё для compass делаю автоимпорт. Я когда начал его делать, то поставил определенные требования. А когда Вы мне показали пример, то он не подошел, да и вообще, как оказалось, из всех плагинов, которые я видел, такое никто не умеет. Но о его способностях можно догадаться по названию "автоимпорт", но необычного в нем это "автоудалятор". Но это не столь сложно было сделать, сколько у меня заняли регулярные выражения и постижение прототипа. Это мое первое знакомство с js. Могу сказать, что со временем он мне нравится все больше и больше.
А что касается mvc, то я уже отказался от view. После Вашей критики у меня мозги на место встали и я понял, что все же это модель. Но у меня остался ещё один вопрос... MVC которое знаю я, допускает, точнее даже обязывает, чтобы модели общались между собой так, как этого хочет главная модель. Но у Вас я понимаю другая схема происходящего? У Вас я имею ввиду не Вас лично, а web разработчиков, я же это если и буду показывать в будущем, то именно web разработчика:) По этому мне нужно знать, как делать. Как у Вас модели между собой общаются?
Вот файловая система, как я понимаю, это все равно, что сервер. И получается, что я пишу часть-модуль для сервера-модели. Как эти части у Вас между собой общаются? Кто мне гонит поток и кто я?
ай гивап... вы не думали просто забить на MVC? Просто влепить контроллер (MVC появилось как развитие паттерна контроллер) и все. Если очень хочется - можно потом логику по компонентам/сервисам разносить, но ни вьюв ни модели там нет.
Попробуйте сделать сначала так а потом уже можно будет весть размышения на тему правильно это или нет.
Есть абстрактное понятие "модель" взятое из контекста MVC и трактующееся каждым по разному. А есть еще domain-model. Модель предметной области. Если опять же упрощать - просто класс. Он может быть связан с другими классами... но они ни с кем особо не общаются. Общение должен делать контроллер или (желательно) компонент, работающий с данной моделью. Никаких сложностей, просто классы которые должны делать только то, что должны. Есть класс/объект File, он ничего не знает по сути о файловой системе, он просто данные хранит. А уже сервис FileManager умеет что-то делать с файлами и переносить эту работу на файловую систему. Это делается для того что бы развязать систему, мол у вас может в какой-то момент файловая система смениться на какую-нибудь навароченную распределенную с другим API, или вообще файловой системы не будет а фаайлы храниться будут где-то и дергаться по scp или любому другому протоколу...
@Fesor , Спасибо Вам за объяснения! И можно я Вам ещё один вопрос задам?)
Делает кто-то проект и у него есть какое-то количество файлов scss.
И Вы беретесь сделать плагин автоимпорт, который будет делать следующее -
1) составить путь для импорта.
2) распарсить файл на наличие специальных комментов.
3) составить из данных полученых на предыдущем шаге новые комментарии.
4) записать их в главный файл .scss.
Как делаю я -
1) Проверяю путь в коллекции, если его нет, то добавляю его в коллекцию вместе с данными о времени изменения. Если путь в коллекции, то проверяю его время изменения и если изменилось, то выполняю следующие шаги. Если нет, то пропускаю.
2) Собираю специальные комментарии.
3) Записываю в главный файл.
А как бы поступили Вы? Сделали бы с коллекцией, чтобы оптимизировать работу во время считывания, распарсивания, записи данных или бы каждый раз все сначала начинали?
