Shitbox2, спасибо, за упоминание :)

)))

у меня вроде работает

поясни

могу предположить только проблемы с "ловлей" файлов. Хотя они решаются, но лениво :)

- общий прогресс у меня реализован, можешь посмотреть (на локальном сервере, removeAfterUpload = false)
- про ограничение кол-ва загружаемых файлов - теоретически, можно (а можно и в модуль валидаторов добавить)
- уменьшение изображений и валидация - я бы вынес в отдельные сервисы, т.к. работа с изображениями более узкая задача, чем загрузка файлов
- аборты было бы неплохо добавить ...
- не вижу смысла заострять внимание на старых браузерах. Пусть умиратют :)

Т.е. поменять настройку в любой момент в приложении. Если использовать изолированную область видимости, то после первой же загрузки через iframe клон инпута будет ссылаться на пустой объект с настройками (т.к. новая область видимости ничего о нем не знает). В моем способе модуль постоянно вотчит изменение настройки и конечно же запишет вместо них undefined.
Это да. С уменьшением тоже не просто. Пытался сделать через канвас, но мало чего толкового нашел... Плагин бы достать, одна часть которого уменьшает изображение, а другая (опционально) предоставляет интерфейс для обрезки.

Ну, с 8 ИЕ хотя бы с урезанным функционалом :-)

понял. Как вариант обходить массив и менять "руками". Для себя я пока не вижу особой необходимости, поэтому делать пока не буду )
Актуально только если элементы очереди не удаляются после загрузки и не загружаются автоматически

я писал умешение и обрезку в виде лайт плагина для жуквери. Если нужна последняя версия, стучи в личку (лучше его переписать в виде

$( 'img' ).toCanvas( '[crop|resize]', { width: 300, height: 68 }) ) ...;

т.е. сделать работу с ним более прозрачной)

ie must die:yes:

Ну тут можно и без Джиквери) А поменять формат на jpg/png можно будет?

Надергал так же ссылок по кропу и ресайзу. Что-то близко, но нужно ковырять. Записал для памяти, надеюсь, потом займусь)
http://deepliquid.com/content/Jcrop_Manual.html
http://evrone.github.io/evroneCrop/
https://github.com/evrone/evroneCrop
http://odyniec.net/projects/imgareaselect/
http://vredniy.ru/2010/08/uploadify-jcrop-php/
http://habrahabr.ru/post/133351/
https://github.com/odyniec/imgareaselect
http://habrahabr.ru/post/133362/
http://w3pro.ru/article/html-5-canva...chinayushchikh
http://remysharp.com/2007/03/19/a-fe...nd-pluck/#crop
https://developer.mozilla.org/ru/doc...BD%D0%BE%D0%BA

P.S. Часто замечал в твоем коде

this.scope.$$phase || this.scope.$apply();

Каким принципом руководствуешься, когда проверяешь фазу? Просто всегда проверяешь или в случаях, когда появлялись ошибки при тестировании или по другим соображениям?

P.P.S. Не очень понял как твой прогресс устроен. Т.е. просто берешь и делишь прогресс одного файла на количество файлов в очереди. Такая штука работает только если в один момент загружается один файл. На деле же при множественной загрузке загружаются сразу несколько файлов, поэтому прогресс каждого должен добавляться в общий

я просто пример показал :)

все просто - завист от кол-ва передаваемых параметров:
- 2 - ресайз
- >2 - кроп (насколько помню)

если код выполняется вне контекста фрейморка, фазу лучше проверять (по моим личным наблюдениям)

у меня может загружаться одновременно только один файл. Пока не вижу смысла загружать сразу несколько. Не вижу проблем добавлять прогресс каждого файла в общий. У меня так и есть применительно к одному файлу (при removeAfterUpload = false на локальном сервере).

А если в контексте, то apply, вообще, не нужен)). Я вот тоже четко не понимаю в каких ситуациях можно попасть в запущенный цикл. Как показывает практика такие ситуации очень редки... Но от чего они случаются — загадка.

О_о А как же многопоточность и все дела? Кстати, обновил плагин. Сделал общий индикатор. Правда, достаточно дубовым способом. Не будет работать, если задержка между уведомлениями прогресса окажется больше 2 с и браузер не будет слишком лажать. Надеюсь, это редкость.

ты хоть ссылки прикладывай, а то пока найдешь :) Я тоже свой обновил: добавил поддержку множественных зон сброса и инпутов с различными настройками (демо)

канал то не резиновый ) Впрочем, если создать несколько экземпляров загрузчика, вероятно, будет многопоточность :D Если ты аргументируешь, зачем в данном случае многопоточность, я тебя выслушаю )

Исправлюсь (гитхаб, демо, песочница) :-)

Ничего об этом не знаю. Перетащи в демке десяток файлов, увидишь, что штук 5 будут одновременно загружаться. Браузер по умолчанию параллелит процессы)

Ааааа! Зачем всё это? Разве бывают ситуации, когда нужно несколько инпутов для одной модели?)) Кстати, в моем варианте нет на это ограничений... Там инпут и модель соединяются в контроллере и сколько инпутов со сколькими моделями соединить — выбор пользователя. Хотя зачем нужно несколько инпутов...

P.S. А не планируешь добавить сжатие изображений на клиенте (законченную версию, с формированием blob и сохранением на сервере в формате картинки), а я бы у тебя утащил)))

P.P.S. Из руководства Разработчики считают, что ситуации, когда повторно запускается фаза выполнения говорят об ошибках в коде

не до конца уверен на этот счет. Допустим, ты перетащил 10 файлов и для каждого из них отправил post запрос. Итого 10 постов у тебя. Все равно быстрее от этого они заливаться не будут (пропускная способность канала), в связи с чем, на мой взгляд, загружать их по одному более естественно. К тому же в подобной реализации возможно прервать загрузки последующих файлов, после того как ряд уже был загружен.

Ну а как ты еще представляешь себе загрузку файлов по разным урлам в рамках одной очереди? https://github.com/nervgh/angular-file-upload/issues/1

в моей теперь тоже нет ограничений (писал выше). Можешь привести пример кода?

планирую, но немного позднее :) Насчет абортов ничего не выяснить не удалось?

интересная точка зрения. Случайно не видел, используется ли где-нибудь в angular.ui проверка фазы? :D

А может быть и быстрее, нужно исследовать. Впрочем, тут с тобой больше согласен. Так лучше, да и разница в скорости по-любому не будет существенной.

О_о Никогда бы не подумал что кому-нибудь будет нужно. Во-первых загрузка одного и того же файла по разным URL в пределах одного сервера — плохое решение. Нельзя такие поощрять. Тут нужно загрузить файл один раз и уже на сервере скопировать куда нужно.

Загрузка одного файла на разные сервера... ИМХО, очень специфичная задача. Может быть какая-то распространенная хитрая оптимизация?

Загрузка очереди по разным URL. Типа кидаешь 5 файлов в таблицу, и они записываются в каждую ячейку. Возможно, но мало кому надо.

Тут лучше смотреть песочницу. У меня каждой директиве

oi-file="options"

можно задать свой объект с настройками. В каждом таком объекте мы задаем колбек

change: function (file) {
  file.$upload(url + data.id, $scope.items[i], data.settings);
}

Из него мы получаем массив файлов и функцию загрузки. Можем теперь хоть каждый файл по отдельном URL загрузить

Пока только отрицательный опыт. Убить загрузку можно, вызвав xhr.abort(). xhr-объект можно записать в объект файла (в твоем случае в item). Поскольку этот объект можно загрузить в область видимости, то можно и аборт оттуда сделать и всё хорошо обрывается. Проблема в том, что при манипуляциях с моделью лезут ошибки именно из-за того, что в модели оказывается ссылка на xhr, а в xhr записана ссылка на модель (циклическая ссылка).

Вот тут как раз думаю сделать как у тебя (в одно время загружается один файл), тогда в xhr можно будет не загружать модель, т.к. и так будет ясно для какой модели загрузился файл.

Случайно нигде не видел, чтобы она использовалась))) Более того, в версии 1.2 и из своего кода смог эти проверки выкинуть. Стало и без них работать. (был баг, когда http-запросы копились и уходили не сразу, если цикл не запустить)

я и сам не подумал бы )

Пока не забыл, хочу тут мысль запостить по поводу отправки файлов через $rootScope. Сейчас у меня ситуация такая, директивы ловят файлы и отправляют их в корневой скоп (по твоему совету). Это правильно и удобно, но не позволит создать два экземпляра загрузчика (независимых). Выход - каналы передачи данных. На примере:

<html>
    <head>
        <script>
            app.run(function( $rootScope ) {
                
                $rootScope.$on( 'channel:name1', function() {
                    // some code
                });

                $rootScope.$on( 'channel:name2', function() {
                    // some code
                });
                
            });
        </script>
    </head>

    <div>
        <div ng-file-drop channel="channel:name1"></div>
    </div>
    
    <div>
        <div ng-file-drop channel="channel:name2"></div>
    </div>
</html>

америку я, конечно, не открыл, но вдруг кому пригодится :)

не соглашусь

теперь у меня тоже (предыдущий релиз) )

теперь понял откуда у меня ошибки лезли

тоже буду курить в этом направлении, когда время будет. Спасибо :)

Не взяли меня фронтендщиком в Яндекс. Ну и ладно, больше времени на открытые проекты останется)

Обновил загрузчик: https://github.com/tamtakoe/oi.file
Переделал загрузку, общий прогресс и проч. Теперь файлы загружаются по-очереди. Для этого пришлось запилить отдельную очередь для загружаемых файлов. Вынеся в эту же очередь ссылки на xhr, избавился от циклических ссылок, что позволило сделать отмену загрузки :-)

Не стал засорять область видимости, поэтому туда копируется только один объект — очередь. Которая содержит как список загружаемых фалов, так и значения общего прогресса, кол-во загруженных байт и т.п.

Теперь новая версия работает только в Ангуляре 1.2. Для старых версий сделал отдельню версию. Там совсем небольшие отличия.

Shitbox2, не грусти, все будет хорошо :)

немного спогодя спизжу позаимствую у тебя :)

все-таки очередь ) Кстати, https://github.com/nervgh/angular-file-upload/issues/5

а чем засорял до этого? О_о

https://github.com/tamtakoe/oi.file

Полями progressAll, loadedAll, например. Тут логика такая: В каждый элемент модели (связанный с файлом) мы добавляем кучу полей:

fileName
fileThumb
fileSize
fileLoaded
fileProgress
fileUploading

Это оправдано, т.к. половина из них могут и так содержаться и быть полезными в модели (fileName, fileThumb, fileSize). Остальные просто удаляются после окончания загрузки.

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

Да. Сравнивал скорость. По сути, одна и та же. Только с параллельной загрузкой больше гемора, когда нужно общий прогресс вычислять :) Еще, если оборвется соединение, то обломается загрузка всех загружающихся файлов. В очереди потеряется только один файл.

Не очень нравится как реализована у меня очередь... С deferred объектами... Думал, этот паттерн поддерживает поочередное выполнение процессов. Похоже, что нет...

вот мы и пришли к событиям :)

я бы все-таки добавлял загрузчик, внутри которого очередь и все остальное

file.name
file.thumb
file.size
...

Еще у меня есть мысль позаимствовать функции transformResponse для разбора ответа сервера. Что думаешь на этот счет?
Кажется, здесь лежат

$http.defaults.transformResponse

Совсем бы не хотелось. События, как мне кажется, это такая штука, которая должна быть связана только с бизнес-логикой, т.е. в основной программе возникают и там же ловятся. Если же каждый плагин будет плодить свои события, можно очень быстро замусорить глобальную область видимости. Если же события будут локальными... Ну и что это за события такие? :-)
----
ИМХО, события нужны для асинхронных вещей: пользователь нажал что-то, кто-то написал в чате и т.п. (мы не создаем запрос). Синхронные вещи — это удел обещаний: запрос к серверу, загрузка файлов (мы создали запрос и ожидаем ответ)

Типа твоего uploader? Когда дело до оптимизации дойдет, скорее всего придется общий код в прототип выносить и что-то такое делать... Но не понимаю, зачем, вообще, нужно выносить очередь? Сперва думал вынести в область видимости только информацию об общем прогрессе, а очередь вынес скорее из-за свойства queue.length :-). Ну и типа можно полностью перехватить управление и пересортировать ее, чтобы, например сначала загружались самые маленькие файлы или, вообще, компоновать все мелкие файлы и загружать их в одном запросе... Но это такая чушь, что без нее будет только лучше.

Эту, как понимаю

function(data) {
  if (isString(data)) {
    // strip json vulnerability protection prefix
    data = data.replace(PROTECTION_PREFIX, '');
    if (JSON_START.test(data) && JSON_END.test(data))
      data = fromJson(data);
    }
    return data;
  }
}

У меня подобным занимается функция-обертка над angular.fromJson

function _parseJSON (data) {
  if (typeof data !== 'object') {
    try {
      return angular.fromJson(data);
    } catch (e) {
      return false;
    }
  }
  return data;
  }
}

В принципе, идея здравая. Правда, не знаю, на сколько оправданы все их проверки. И в моем случае я парсю, только если этого не сделал $http, т.е. и так почти всегда использую дефолтный transformResponse.

не правильно тебе кажется )

многие жуквери плагины плодят события

1. как можно замусорить область видимости событиями? :)
2.

глобальный_скоп {
    scope {
        2. тут поймали и остановили (чтобы не дошло до глобального скопа)
        scope: {
             1. тут запулили событие вверх
        }
    }
}

функции. Их может быть много (согласно ангуляру). Опять-таки, зачем писать свою/свои, если можно воспользоваться тем, что есть (моя логика).

Думаешь, это идеалогически верный подход? Когда мы не контролируем имена событий, генерируемых плагином и можем случайно получить два события с одинаковым именем из разных источников? Обычно события в жиквери-плагинах имеют вид колбеков (как у меня сделано), либо ограничены только областью видимости плагина и не распространяются вверх $('#pluginTag').on(...)

Интересно как это делается? Кажется в Ангуляре нет средств для остановки событий, т.е. придется свой костыль писать.

Кто ж спорит?)) Пока не представляю как получить ссылку на встроенную функцию с гарантией, что ее никто не переопределит. Второй вопрос, нужны ли такие навороты для загрузки файлов? Там-то универсальная функция. Может быть для загрузки такая и не нужна.

зависит от обстоятельств

чего? Если мы их сами генерируем, то почему мы "их не контролируем"? :)

1. коллбек - это коллбек
2. событие - это событие
что мешает сделать пространство имен для событий? Мне, кстати, надо добавить :D

event.stopPropagation();

1. функции
2. зачем на одну, если можно на массив функций? (например)

Они генерируются в недрах плагина, так что кроме тебя их никто не контролирует :-)

Любое событие начинается колбеком и заканчивается колбеком)

Я невнимательный) Тем не менее, тут палка о двух концах. Вызов функции в $on вызывает цикл дайджест, и он будет вызываться даже для тех событий, которые нам не нужны (мы их просто ловим, чтобы остановить)

Можно тут подробнее, как бы ты это сделал?

чего? О_о

немного позднее отвечу

добавь себе https://github.com/nervgh/angular-fi...rollers.js#L11 пригодится )

Поиграл. Был не прав.

Да, вот как-то не получается красиво это к себе добавить) Будет ли пользоваться спросом? В RESTе это не нужно + у меня идеалогия загрузки такова, что загрузка всегда идет по имеющемуся айдишнику....

https://github.com/nervgh/angular-file-upload
Выглядит интересно.
Мне щас как раз пилить мини галерею картинок с возможность загрузки файлов.
Можно попробывать приспособить :)

добавил

а я что, я ничего :) Это все Shitbox2

Скромничаешь))

Shitbox2, что думаешь по этому поводу?