Pull to refresh

Comments 46

>> Отправить

1. Почему не сабмит?
2. ИМХО, даже в наш век тотального JS надо навешивать все обработчики уже после загрузки DOM, а наличие решетки в href'е — вообще ни в какие ворота (в идеале все должно работать без JS, т.е. элемент формы должен иметь нормальный работающий адрес скрипта).

>> Думаю, всем понятно, что данный скрипт должен лежать в закрытой админской части сайта чтобы к нему не имели доступа разные личности со стороны.

Проверку в самом скрипте все равно надо делать, никому нельзя верить.
Надеюсь, Вы понимаете, что в данной статье показаны всего лишь краткие примеры? (Это к вопросу о решетке и сабмите). А что касается проверки в самом скрипте, то об этом русским по белому написано и в статье. Надеюсь, Вы не ставите мне в вину тот факт, что я в примере не реализовал эту проверку, которая сама по себе достойна не одной статьи?
Я ставлю в вину даже отсутствие упоминания о подобного рода практике. Всяко лучше, чем спорное «Думаю, нет нужды подробнее останавливаться на необходимости подключения библиотеки jQuery».
«Кроме того, имя файла и сам файл должны проверяться на валидность» — это не упоминание о подобного рода практике?
Не всегда получается, обычно принятие решений о переезде на стороне клиента принимается неделю-две, а вот файл залить нужно прямо сейчас, вчера, позавчера, к нам звонят и спрашивают где годовой отчет.

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

Но если клиент настаивает и хостинг сохранить, и чтобы файлы закачивались — почему бы не сделать работу, и не выставить счет. Как говорится, все ваши желания вами и оплачиваются.
я бы тупо по ftp залил :)
jumpLoader обладает нужной вам функцией закачки по частям.
Вот пример загрузки больших файлов частями с проверкой контрольной суммы.
А тут более простой пример, для быстрого оценки фичи.
Ага… Это интересно, спасибо.
еще один plupload.
Поддерживает сразу несколько способов (flash, silverlight etc)
UFO just landed and posted this here
Ну, допустим, популярность явы здесь не столь критична: напоминаю, что речь идет об админке, причем даже не о серийном продукте — для одного единственного клиента. Лицензия напрягает больше.

Данная возможность точно поддерживается в FF 3.0. Насчет более старых — не знаю. IE, Опера, Хром — не поддерживают. А что касается стандартов, то более перспективной фичей представляется FileAPI. Его уже поддерживает FF 3.6, на подходе Хром. Опера, думаю, подтянется. Всю малину, конечно же, испортит IE.
Не стоит сильно переживать насчет лицензии, как сказано на сайте «You may use this software for free».

Покупать нужно для отключения лого, но я его там так и не нашел, этого лого (разве что в диалоге about, который никто не заставляет вас вызывать).
Или для получения исходников. Этот вариант я считаю вполне справедливым, т.к. работа автором проделана немаленькая и вполне достойна той платы, что он посит.
Ну, как уже ответил автор топика, для админки не так критично ява это или флэш.

А про закрытость лицензии не совсем верно. Пользовать вы его можете абсолютно бесплатно. За деньги вам предлагаются версии «без лого» и исходники.

Думаю для большинства будет достаточно бесплатной версии, тем более что функционал этой бесплатностью никак не ограничивается.
Хм…
а директивы в .htaccess
php_value upload_max_filesize
php_value post_max_size
хостер тоже не поддерживает????
Неужто Вас удивляет, что такое бывает?
Честно-говоря удивило несколько…
В свое время для самописного приложения делали что-то подобное через JSP…
Но пример интересный — спасибо!
Значит там CGI и вам надо бы править свой php.ini :)
Кстати, а что за хостер? )
Согласен с вами, товарищ!
Тоже в свое время попался на эту фишку — даже в саппорт писал.
А мне и говорят — это город Ленинград php.ini вам надо ковырять!
Кстати, хостер-то был и есть Логол…
Ведь намного удобнее положить php.ini к скрипту, для которого надо изменить параметры, чем ковыряться в .htaccess, который еще и перекроет параметры, настроенные до этого.
UFO just landed and posted this here
Если честно, то у меня та же мысль появлялась :)
Вообще, конечно, перед тем как регистрируется хостинг — надо открыть страницу опций и хорошо их изучить, на предмет совместимости с желаниями клиентов ;) У меня была такая же ситуация, после непродолжительной переписки с хостером, ограничение для моего аккаунта было расширено до 30 мб. Насколько я понял, подобные ограничения — для защиты от нелегального распространения контента. Когда я объяснил что на хостинге сайт музыкальной группы и загружают они только свое видео и музыку, хостер не стал препятствовать и/или просить денег за это. Всегда можно договорится (если обосновать) вы это пробовали?
В данном случае все решается банальной сменой тарифного плана. Остается малость: убедить в этом клиента. А вот с этим проблема. Задача ведь решена? Решена. А если нет разницы — зачем платить больше?
Тоже сталкивался с похожей задачей и уперся в пределы памяти.

Почему они не сделали простой произвольный доступ к содержимому файла, вместо единственно возможного чтения его целиком в память? Неудобно…

Интересно, из флеша это можно обойти?
Подскажите, насколько ресурсоемки подобные операции (подсчет размера файла, перебор по частям) в javascript? Скажем, потянет ли средний клиент обсчет файла размером 1-2 Гб (не берем в расчет загрузку, речь только о клиентской стороне)?
Нет, гигабайты — это уже явно за пределами.
Как вариант — через промежуточный хост с нормальными настройками ;) Который бы уже бил файл и сливал на основной по кусочкам.
Боюсь, этот вариант еще более экзотичен. Кто будет оплачивать этот промежуточный хост? Клиент? Зачем тогда весь этот апофеоз, если в этом случае можно просто захостить сайт на этом хосте? Может быть, наша компания? Но что тогда будет если клиент прекратит сотрудничество с нами? Наша разработка прекратит функционировать, что не очень красиво.
UFO just landed and posted this here
UFO just landed and posted this here
я сходу и прочитал как «Текарт». ЧЯДНТ?
>Теперь прочитаем — «Текарт».
>Какое слово мозг подставит первым? =)

Декарт
А вот как преобразуется серверная часть в случае, если передача ведется в асинхронном режиме:

$filename = "/dir/to/save/".$_POST['filename'];
fclose(fopen($filename, 'a')); // создадим файл
$f = fopen($filename,"r+");
fseek($fp, $_POST['offset']);
fputs($f,base64_decode($_POST['chunk']));
fclose($f);


А на клиенте, соответственно:

$.post('/upload.php',{
filename:filename,
chunk:data.substring(pos,pos+upload_chunk_size),
offset: pos
});
Только одно «но» — если все-таки у вас работает декодирование base64 от обрезанной строки, то надо offset тоже правильно посылать, а именно — умножать на 3/4 (см. base64 на википедии). Т.е. либо на клиенте, либо на сервере нужно написать:

offset: pos*3/4


Или

fseek($fp, $_POST['offset']*3/4);


Извините, не сразу понял, что в base64 данные приходят :).
fclose(fopen($filename, 'a'));


Шикарно. Есть такая функция, touch называется.
Угадайте, что она делает :). Так что я лично разницы не вижу.
Если для изготовления дырок в стене есть дрель, то какой смысл делать дырки забивая гвозди и потом вытаскивая их пассатижами?
Кстати… вместо отключения асинхронности лучше бы отправляли номер чанка и собирали при получении последнего
угу, серверная часть при этом не сложнее: открываем файл, перемещаемся на позицию X, пишем очередной чанк. Ну и можно заранее создавать нужный по размеру файл, забитый нулями.
Sign up to leave a comment.