отличия работы кода локально и в сети

[misha_yu]

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

во первых относительные пути типа папка\\имяфайла - работают локально, но не работают в сети надо так: папка/имяфайла

потом если в коде расширение файла .jpg, то если на серваке расширение JPG, то тоже работать не будет (локально цепляет и те и те)

кстати, обнаружил некоторые отличия работы флэшки в internet Explorer и Opera.

Всвязи с этим вопрос как написать код в котором читались бы и .jpg и .JPG и JPEG ?
так как всвязи с этим возникает и проблема выполнения кода вообще, это когда действие зависит от факта загрузки.

[ladon]

Рекомендуется написать класс-обертку который такую неприятность будет исправлять.

if (Security.sandboxType == "remote") {
.....
} else {
.....
}

[BlooDHounD]

misha_yu, вообще никак не решить. дело не в том, локально оно или нет. дело в системе. в винде регистр не имеет значения, а в никсах имеет. тоже самое с слэшами: у винды они в другую строну по умолчанию, но понимает она по всякому.

[castaneda]

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

[misha_yu]

в принципе я решил задачу, только как то громоздковато:

backgroundPreviewURLPath="background/0.jpg"; // сначала пробуем грузить jpg с нижним регистром
var backgroundPreviewURLRequest:URLRequest = new URLRequest (backgroundPreviewURLPath);
 
if (Security.sandboxType == "remote") { // проверка на удаленую работу
 
backgroundPreviewLoader.load(backgroundPreviewURLRequest);
backgroundPreviewLoader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR , netIoErrorHandler1); // ловим ошибку загрузки
 
 
function netIoErrorHandler1(event:IOErrorEvent):void { // и если не получилось то пробуем грузить с верхним регистром
 
backgroundPreviewURLPath = "background/0.JPG";
var backgroundPreviewURLRequest:URLRequest = new URLRequest (backgroundPreviewURLPath);
backgroundPreviewLoader.contentLoaderInfo.removeEventListener(IOErrorEvent.IO_ERROR , netIoErrorHandler1);
backgroundPreviewLoader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR , netIoErrorHandler2);
backgroundPreviewLoader.load(backgroundPreviewURLRequest);
}
}

вот и так далее следуя можно пробовать и с расширениями jpeg с верхним и нижним регистрами.

В принципе дает большую стабильность при ручном наполнении контента.

Буду дальше описывать косячки которые обусловлены работой сандбокса или особенностей ОС сервера.

[BlooDHounD]

misha_yu, Вы кажется не поняли. сэндбокс тут не причём. просто у Вас локально винда, а на сервере никс. будь всё наоборот, то результат был бы наоборот.

[misha_yu]

да , я в общем начал догадываться, т.к. проверку сандбокса убрал из кода.
А выловку ошибок оставил и загрузки с различными интерпретациями расширения оставил, теперь локально работет и с jpg и с jpeg.

[BlooDHounD]

misha_yu, а проверку на регистр Вы как собираетесь реализовывать?

[misha_yu]

непосредственно выявить какой регистр я не знаю как. Но осуществление загрузки делается как в приведенном выше коде.
- Загрузка с нижним регистром jpg
- Елси ошибка - то пробуем с верхним JPG
- Елси ошибка - то пробуем jpeg
- Елси ошибка - то пробуем JPEG

В принципе это уже работет. Проблему jpg - JPEG для своего случая решил.

[AL.exe]

Что-то никогда не сталкивался такой проблемой - просто соблюдайте регистр и ставьте прямые слеши "/" - проблем быть не должно.