Хорошая статья для начинающих.
А вот с этим
>Его достаточно легко освоить
Я бы поспорил. :) Прототипы, миксины, передача аргументов by sharing… Он прост на первый взгляд. Я не первый год пишу на нем и до сих пор иногда случаются «озарения» :)
PS Недавняя новость про запуск линукса в js эмуляторе просто взорвала мозг. Что-то до сих пор на место не встало.
А вы говорите, легко освоить…
PPS Я бы перефразировал — с ним легко начинать. И если распробуешь его — несложно расти.
С другой стороны из минусов отказа github от локализации — невозможность полноценного ведения проекта с менеджерами и заказчиками прямо в нём. А доплачивать за basecamp или lighthouse и прочих совсем не хочется.
Отличная новость, так держать! Следющее чего очень жду это — доп. IP на сервер. Приятно хоститься в компании которая не перестаёт старается стать лучше.
Это возвращает нас к тому, с чего мы начали. При добавлении новых модулей придется добавлять новые проверки — усиливается связанность. Имхо, контроль данных в самих слушателях — более гибкое решение
По поводу разделения. Оно у нас есть, хотя и не в том смысле, как вы спрашиваете. Можно говорить о разных уровнях приложения где эта модель применяется. То, что я описал в примере можно считать «главным циклом» приложения — основная его логика и взаимодействие с пользователем. Кроме него есть еще «внутренние» слои приложения — например взаимодействие интерфейса (кнопки, контекстное меню) с командами. Что бы не «хардкодить» кнопки в самих командах, они у нас являются отдельными объектами и подписываются на событие «изменение» в командах.
Наверно в статье я допустил неточность — объектов, принимающих подписку может быть любое количество
У нас немного другая схема не так, как вы описали. Когда происходит клик по файлу (неважно где) вид поднимает событие клик, по которому ядро обращается к серверу. И собственно событие «open» им же и вызывается, когда получены корректные данные. Так, что ваш пример у нас просто невозможен.
Хотя в теории возможна ситуация зацикливания — в обработчике события вызываем другое событие, а в его обработчике снова первое событие. Наверно абсолютного способа избежать этого — нету. Это скорее вопрос конкретной реализации.
Наверно стоит отметить это, как еще один недостаток метода.
Для описаных задач уже существует достаточное кол-во модулей — смотрите в репозитории npm.
Еще рекомендую посмотреть на node-fiber и решениях на его основе — Sync/fiberlize
> имена файлов — это уникальные хэши
Это не минус — это плюс. Передача путей к файлам в чистом виде ведет к раскрытию информации о файловой системе сервера — пусть и небольшая, но дыра в безопасности
>авторизация
Это не плюс и не минус — это пятое колесо. ФМ не должен этим заниматься, это задача скрипта, который его запускает. Слишком много вариантов авторизации существует — универсальное решение под все не получиться.
Выделение с контролом не работает на маке — забыли event.metaKey
Вообще — очень даже неплохо! Но выделением текста при двойном клике очень портит впечатление. По себе знаю, что это довольно неприятная проблема — провел немало часов, чтобы подружить selectable/draggable и droppable :)
Успехов вам в развитии проекта! Больше файловых менеджеров, хороших и разных!
a === void(0)А вот с этим
>Его достаточно легко освоить
Я бы поспорил. :) Прототипы, миксины, передача аргументов by sharing… Он прост на первый взгляд. Я не первый год пишу на нем и до сих пор иногда случаются «озарения» :)
PS Недавняя новость про запуск линукса в js эмуляторе просто взорвала мозг. Что-то до сих пор на место не встало.
А вы говорите, легко освоить…
PPS Я бы перефразировал — с ним легко начинать. И если распробуешь его — несложно расти.
$ гит тяни$ гит фиксируй
$ гит толкай
С другой стороны из минусов отказа github от локализации — невозможность полноценного ведения проекта с менеджерами и заказчиками прямо в нём. А доплачивать за basecamp или lighthouse и прочих совсем не хочется.
Наверно в статье я допустил неточность — объектов, принимающих подписку может быть любое количество
Хотя в теории возможна ситуация зацикливания — в обработчике события вызываем другое событие, а в его обработчике снова первое событие. Наверно абсолютного способа избежать этого — нету. Это скорее вопрос конкретной реализации.
Наверно стоит отметить это, как еще один недостаток метода.
Еще рекомендую посмотреть на node-fiber и решениях на его основе — Sync/fiberlize
> имена файлов — это уникальные хэши
Это не минус — это плюс. Передача путей к файлам в чистом виде ведет к раскрытию информации о файловой системе сервера — пусть и небольшая, но дыра в безопасности
>авторизация
Это не плюс и не минус — это пятое колесо. ФМ не должен этим заниматься, это задача скрипта, который его запускает. Слишком много вариантов авторизации существует — универсальное решение под все не получиться.
Вообще — очень даже неплохо! Но выделением текста при двойном клике очень портит впечатление. По себе знаю, что это довольно неприятная проблема — провел немало часов, чтобы подружить selectable/draggable и droppable :)
Успехов вам в развитии проекта! Больше файловых менеджеров, хороших и разных!